Hi, Wangyan:
On Wed, 2019-03-06 at 18:13 +0800, CK Hu wrote:
> Hi, Wangyan:
>
> On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > From: chunhui dai
> >
> > We should not change the rate of parent for hdmi phy when
> > doing round_rate for this clock. The parent clock of hdmi
> > phy
On Wed, Mar 20, 2019 at 4:49 PM Nick Desaulniers
wrote:
>
> On Wed, Mar 20, 2019 at 2:37 AM Koenig, Christian
> wrote:
> >
> > Am 20.03.19 um 05:34 schrieb Nathan Chancellor:
> > > On Wed, Mar 20, 2019 at 01:31:27AM +, Pan, Xinhui wrote:
> > >> these two enumerated types are same for now.
Hi, Wangyan:
On Wed, 2019-03-06 at 18:07 +0800, CK Hu wrote:
> Hi, Wangyan:
>
> On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > From: chunhui dai
> >
> > Recalculate the rate of this clock, by querying hardware.
> >
> > Signed-off-by: chunhui dai
> > Signed-off-by: wangyan wang
>
On Tue, Mar 19, 2019 at 10:47 PM Cui, Flora wrote:
>
> 1. clear cmd buffer
> 2. make amdgpu_memcpy_dispatch_test static
> 3. tab/space fix
>
> Change-Id: Idf55f8881f66458b585092eccb55b6042520e4ad
> Signed-off-by: Flora Cui
Reviewed-by: Alex Deucher
and pushed.
Thanks!
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=110213
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Dave, Daniel,
Fixes for 5.1:
- Parially revert a bulk move clean up change to fix a ref count bug
- Fix invalid use of change_bit that caused a crash on PPC64 and ARM64
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
Hi, Hsin-yi:
On Thu, 2019-03-21 at 09:28 +0800, CK Hu wrote:
> Hi, Hsin-yi:
>
> On Wed, 2019-03-20 at 15:18 +0800, Hsin-Yi Wang wrote:
> > mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> > needs
> > ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop()
Hi, Frank:
On Wed, 2019-03-20 at 19:01 +0100, Frank Wunderlich wrote:
> Hi,
>
> i hoped this fixes my warning (maybe have similar cause) on bananapi-r2/mt7623
This patch fix the problem of dsi driver. Your case is hdmi output which
does not go through dsi hardware. So your problem is another
https://bugs.freedesktop.org/show_bug.cgi?id=110214
Bug ID: 110214
Summary: amdgpu: xterm scrollback buffer disappears while
paging up/down
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Hi, Hsin-yi:
On Wed, 2019-03-20 at 15:18 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is
Hi Chunming,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc1 next-20190320]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Dave and Daniel,
Here goes the first round of fixes for 5.1-rc cycle.
I will be out on vacation next week, so next week's pull request
might come from Jani. Although things looks calm right now.
only 3 patches on top of -rc1:
drm-intel-fixes-2019-03-20:
A protection on our mmap against
Hi all,
Friendly ping:
Who can take this?
Thanks
--
Gustavo
On 2/28/19 5:51 AM, Oleksandr Andrushchenko wrote:
> +Xen-devel list
>
> On 2/27/19 10:53 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall
Quoting Chris Wilson (2019-03-04 09:43:43)
> Quoting Andy Shevchenko (2019-03-04 09:29:07)
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
> >
> > Signed-off-by: Andy Shevchenko
> Reviewed-by:
Em Wed, 20 Mar 2019 17:36:50 +0100
Marco Felsch escreveu:
> Hi Mauro,
>
> On 19-03-20 11:18, Mauro Carvalho Chehab wrote:
> > Em Sat, 2 Feb 2019 13:10:04 +0100
> > Marco Felsch escreveu:
> >
> > > The tvp5150 accepts NTSC(M,J,4.43), PAL (B,D,G,H,I,M,N) and SECAM video
> > > data and is
From: Colin Ian King
There is a spelling mistake in pr_warn message; fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #72 from tempel.jul...@gmail.com ---
Well, I just accepted to lose 2Hz and use a custom edid with 73Hz instead of
75.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #71 from bmil...@gmail.com ---
(In reply to George Scorer from comment #70)
> Building on julien tempel's workaround, here's a somewhat more complex
> script to manage the memory p-state jumps. It switches between low and high
>
Paul Kocialkowski writes:
> The binner BO is a pre-requisite to GPU operations, so we must ensure
> that it is always allocated when the GPU is in use. Currently, we are
> allocating it at probe time and liberating/allocating it during runtime
> pm cycles.
>
> First, since the binner buffer is
Paul Kocialkowski writes:
> The firstopen DRM driver hook was initially used to perform hardware
> initialization, which is now considered legacy. Only a single user of
> firstopen remains at this point (savage).
>
> In some specific cases, non-legacy drivers may also need to implement
> these
https://bugs.freedesktop.org/show_bug.cgi?id=110213
Bug ID: 110213
Summary: Used pwm value is lesser than the requested value
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106571
--- Comment #3 from ukbeas...@protonmail.com ---
Created attachment 143742
--> https://bugs.freedesktop.org/attachment.cgi?id=143742=edit
Hardware list
Tested 5.1-rc1, Lenovo laptop will hang after waking from suspend.
--
You are receiving
On Wed, Mar 20, 2019 at 12:30:25PM -0400, Nicolas Dufresne wrote:
> Le mercredi 20 mars 2019 à 18:09 +0200, Ville Syrjälä a écrit :
> > On Wed, Mar 20, 2019 at 11:51:58AM -0400, Nicolas Dufresne wrote:
> > > Le mercredi 20 mars 2019 à 16:27 +0200, Ville Syrjälä a écrit :
> > > > On Tue, Mar 19,
https://bugs.freedesktop.org/show_bug.cgi?id=109526
--- Comment #4 from Johannes Hirte ---
Anything I can do help debugging this? It's still an issue with 5.1-rc1 and
really annoying.
--
You are receiving this mail because:
You are the assignee for the
On Wed, Mar 20, 2019 at 2:16 AM Benjamin Gaignard
wrote:
> Le mar. 19 mars 2019 à 23:36, John Stultz a écrit :
> > On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
> > > For at least some hw the importing driver needs to configure things
> > > differently for secure buffers :-/
> >
> > Does the
On Wed, Mar 20, 2019 at 11:51:58AM -0400, Nicolas Dufresne wrote:
> Le mercredi 20 mars 2019 à 16:27 +0200, Ville Syrjälä a écrit :
> > On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> > > Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> > > > V4L2 uses different
Op 20-03-2019 om 16:48 schreef Adam Jackson:
> On Tue, 2019-03-19 at 13:17 +0100, Maarten Lankhorst wrote:
>> There has unfortunately been a conflict with the following 3 commits:
>>
>> commit e9961ab95af81b8d29054361cd5f0c575102cf87
>> Author: Ayan Kumar Halder
>> Date: Fri Nov 9 17:21:12 2018
Le mer. 20 mars 2019 à 15:54, Andrew F. Davis a écrit :
>
> On 3/20/19 4:16 AM, Benjamin Gaignard wrote:
> > Le mar. 19 mars 2019 à 23:36, John Stultz a écrit :
> >>
> >> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
> >>>
> >>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
>
The firstopen DRM driver hook was initially used to perform hardware
initialization, which is now considered legacy. Only a single user of
firstopen remains at this point (savage).
In some specific cases, non-legacy drivers may also need to implement
these hooks. For instance on VC4, we need to
Changes since v1:
* Squashed the two final patches into one.
Paul Kocialkowski (2):
drm/file: Rehabilitate the firstopen hook for non-legacy drivers
drm/vc4: Allocated/liberate the binner BO at firstopen/lastclose
drivers/gpu/drm/drm_file.c| 3 +--
drivers/gpu/drm/vc4/vc4_drv.c | 26
On Tue, 2019-03-19 at 13:17 +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
>
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder
> Date: Fri Nov 9 17:21:12 2018 +
> drm: Added a new format
The binner BO is a pre-requisite to GPU operations, so we must ensure
that it is always allocated when the GPU is in use. Currently, we are
allocating it at probe time and liberating/allocating it during runtime
pm cycles.
First, since the binner buffer is only required for GPU rendering, it's
a
Add two utilities to a) write-protect and b) clean all ptes pointing into
a range of an address space
The utilities are intended to aid in tracking dirty pages (either
driver-allocated system memory or pci device memory).
The write-protect utility should be used in conjunction with
page_mkwrite()
Driver fault callbacks are allowed to drop the mmap_sem when expecting
long hardware waits to avoid blocking other mm users. Allow the mkwrite
callbacks to do the same by returning early on VM_FAULT_RETRY.
In particular we want to be able to drop the mmap_sem when waiting for
a reservation object
This is basically apply_to_page_range with added functionality:
Allocating missing parts of the page table becomes optional, which
means that the function can be guaranteed not to error if allocation
is disabled. Also passing of the closure struct and callback function
becomes different and more
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Hi,
This is an early RFC to make sure I don't go too
Hi,
Le samedi 16 mars 2019 à 11:58 -0700, Eric Anholt a écrit :
> Paul Kocialkowski writes:
>
> > The binner BO is a pre-requisite to GPU operations, so we must ensure
> > that it is always allocated when the GPU is in use.
> >
> > Because the buffer is allocated from the same pool as other
https://bugs.freedesktop.org/show_bug.cgi?id=102646
George Scorer changed:
What|Removed |Added
Priority|low |high
Severity|minor
https://bugs.freedesktop.org/show_bug.cgi?id=102646
George Scorer changed:
What|Removed |Added
Priority|high|low
Severity|major
On 3/20/19 4:16 AM, Benjamin Gaignard wrote:
> Le mar. 19 mars 2019 à 23:36, John Stultz a écrit :
>>
>> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
>>>
>>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> Le mer. 13 mars
On 3/20/19 7:23 AM, Vlastimil Babka wrote:
You should have CC'd the ION maintainers/lists per
./scripts/get_maintainer.pl - CCing now.
On 3/14/19 12:06 PM, Zhaoyang Huang wrote:
From: Zhaoyang Huang
Two action for this patch:
1. set a batch size for system heap's shrinker, which can have it
Hi,
Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> drm_get_format_info directly calls into drm_format_info, but takes directly
> a struct drm_mode_fb_cmd2 pointer, instead of the fourcc directly. It's
> shorter to not dereference it, and we can customise the behaviour at the
>
On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> > V4L2 uses different fourcc's than DRM, and has a different set of formats.
> > For now, let's add the v4l2 fourcc's for the already existing formats.
> >
> >
Hi,
Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> So far, the drm_format_plane_height/width functions were operating on the
> format's fourcc and was doing a lookup to retrieve the drm_format_info
> structure and return the cpp.
>
> However, this is inefficient since in most
Hi,
Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> So far, the drm_format_plane_cpp function was operating on the format's
> fourcc and was doing a lookup to retrieve the drm_format_info structure and
> return the cpp.
>
> However, this is inefficient since in most cases, we will
You should have CC'd the ION maintainers/lists per
./scripts/get_maintainer.pl - CCing now.
On 3/14/19 12:06 PM, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> Two action for this patch:
> 1. set a batch size for system heap's shrinker, which can have it buffer
> reasonable page blocks in
Em Sat, 2 Feb 2019 13:10:04 +0100
Marco Felsch escreveu:
> The tvp5150 accepts NTSC(M,J,4.43), PAL (B,D,G,H,I,M,N) and SECAM video
> data and is able to auto-detect the input signal.
Hmm... I'm afraid of this change. As far as I remember, I tested some
weird format variants like
Hi,
Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
> drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling
> are basically a lookup in the drm_format_info table plus an access to the
> hsub and vsub fields of the appropriate entry.
>
> Most drivers are using
Hi,
On Tue, 2019-03-19 at 22:57 +0100, Maxime Ripard wrote:
> drm_format_num_planes() is basically a lookup in the drm_format_info table
> plus an access to the num_planes field of the appropriate entry.
>
> Most drivers are using this function while having access to the entry
> already, which
]
kernel BUG at drivers/iommu/exynos-iommu.c:450!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-rc1-next-20190320-dirty #5628
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
PC is at exynos_sysmmu_irq+0x1c8/0x244
On Tue, 19 Mar 2019 22:57:11 +0100
Maxime Ripard wrote:
> Move the DRM formats API to turn this into a more generic image formats API
> to be able to leverage it into some other places of the kernel, such as
> v4l2 drivers.
>
> Signed-off-by: Maxime Ripard
> ---
>
On 20/03/2019 03:53, zhoucm1 wrote:
On 2019年03月19日 19:54, Lionel Landwerlin wrote:
On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free
independently.
v3: all existing points must be already signaled before cpu perform
signal operation,
On 3/20/19 4:12 AM, Mario Kleiner wrote:
> During VRR mode we can not allow vblank irq dis-/enable
> transitions, as an enable after a disable can happen at
> an arbitrary time during the video refresh cycle, e.g.,
> with a high likelyhood inside vblank front-porch. An
> enable during front-porch
GSCALER should be feed with clock at certain rates.
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 ++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 --
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git
YVU420 requires swapping addresses of U and V planes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 52 ++---
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
GSCALERs in Exynos5433 have local path to DECON and DECON_TV.
They can be used as extra planes with support for non-RGB formats and scaling.
To enable it on DECON update_plane and disable_plane callback should
be modified. Moreover DSD mux should be set accordingly, and finally
atomic_check
Display controllers in Exynos beside native planes/windows can use external
planes provided by other IPs - GSCALER, FIMD, VPP. To add support to them
we will need plane specific callbacks.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +++
1 file changed, 7
exynos_drm_crtc_init has all information necessary to discover primary
plane. Let's move logic for setting primary plane into this function.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 ---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 -
DECON should wait for previous update before starting new one. Otherwise
internal registers can be updated in non-atomic, error prone way.
This patch fixes occasional occurrences of vblank timeouts on tm2 platform:
[ 3167.968742] [CRTC:55:crtc-0] vblank wait timed out
[ 3167.987440] WARNING: CPU:
To support local paths both DECON and GSCALER should enable respective
Smart Deck clocks DSD and GSD.
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +-
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git
Since all Exynos CRTCs uses the first plane as primary plane and the last
one as cursor plane we can drop custom assignments per CRTC and replace it
with common code.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +--
It can be replaced by recently introduced to_vidi helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
The patch configures cursor plane in exynos_drm_crtc_init.
Since Exynos DRM does not support fast/async path for cursor update,
it must be disabled.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +-
2
Since crtc maps 1:1 to the device there is no point in allocating it
separately, another benefit is possibility of direct initialisation
of its fields which is more readable and allows further expansion.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 52
exynos_drm_plane_config must be present for every plane, and most fields
are redundant with exynos_drm_plane:
- pixel_formats, num_pixel_formats are stored in plane.base.format_*,
- type is stored in plane.base.type,
- zpos is always equal to plane.index.
The only non-redundant field capabilities
Since exynos_drm_crtc is a struct which maps 1:1 to underlying device it
is better to put it directly into device's context instead of allocating
it separately. Another benefit is possibility of initialisation of
its fields directly, without expanding exynos_drm_crtc_create which is
already
Id should be assigned based on OF alias.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index
Since exynos_drm_crtc is always embedded exynos_drm_crtc_create helper and
ctx field can be removed.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 35
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 5
GSCALERs in Exynos5433 have local path to DECON and DECON_TV.
They can be used as extra planes with support for non-RGB formats and scaling.
To enable it GSCALER must expose exynos_plane with associated plane callbacks
and bind it to DECONs CRTCs. Moreover device locking should be added to prevent
GSCALER does not support BGRX, instead it supports XBGR.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
This bit will indicate the plane is provided by GSCALER.
Tests shows that GSCALER does not like to convert from/to too small
buffers. Since exact constraints are not provided by documentation
rough estimate of 64 pixel has been applied.
Signed-off-by: Andrzej Hajda
---
Since crtc maps 1:1 to the device there is no point in allocating it
separately, another benefit is possibility of direct initialisation
of its fields which is more readable and allows further expansion.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 26
Since crtc maps 1:1 to the device there is no point in allocating it
separately, another benefit is possibility of direct initialisation
of its fields which is more readable and allows further expansion.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_mixer.c | 39
The header contains only declaration of one function, the rest of exynos
plane declaration is in exynos_drm_drv.h.
Let's merge it together.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 -
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 1 -
MAX_CRTC macro is not used at all.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6e38d0dc4457..1f6bb5516170 100644
---
Since crtc maps 1:1 to the device there is no point in allocating it
separately, another benefit is possibility of direct initialisation
of its fields which is more readable and allows further expansion.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 60
Hi Inki,
GSCALERs in Exynos SoCs support conversion between wide range of image formats,
plus scaling and rotation.
Driver already supports mem2mem mode - via ExynosDRM IPP framework.
This patchset adds support for mem to display mode - framebuffers can
be converted, scaled and send directly to
Since crtc maps 1:1 to the device there is no point in allocating it
separately, another benefit is possibility of direct initialisation
of its fields which is more readable and allows further expansion.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 50
On 20/03/2019 08:57, Tomi Valkeinen wrote:
> On 19/03/2019 20:18, Andrey Smirnov wrote:
>
>> TC358767 has two GPIO pins that can be used for HPD signal. I think
>> instead of hardcoding GPIO0 here it would be more flexible to expose
>> boths gpios as a gpiochip and use gpiolib API to query the
On 3/20/19 3:51 AM, Mario Kleiner wrote:
> Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
>
> On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas, Nicholas
> wrote:
>>
>> On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote:
>>> On 3/18/19 1:19 PM, Mario Kleiner wrote:
In VRR
On Wed, 20 Mar 2019, "Sharma, Swati2" wrote:
> On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
>> On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
>>> From: Swati Sharma
>>>
>>> Added state checker to validate gamma_lut values. This
>>> reads hardware state, and compares the originally requested
On 20/03/2019 03:53, zhoucm1 wrote:
On 2019年03月19日 19:54, Lionel Landwerlin wrote:
On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free
independently.
v3: all existing points must be already signaled before cpu perform
signal operation,
https://bugs.freedesktop.org/show_bug.cgi?id=110208
--- Comment #1 from famo ---
Link to documentation:
https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html#power-dpm-force-performance-level
Quote:
pp_od_clk_voltage
The amdgpu driver provides a sysfs API for adjusting the clocks and voltages
https://bugs.freedesktop.org/show_bug.cgi?id=110208
Bug ID: 110208
Summary: New GPU sysfs Power State Interface for custom
pp_od_clk_voltage
Product: DRI
Version: unspecified
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=101473
famo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Peter,
On Mon, 2019-03-18 at 19:38 +, Peter Griffin wrote:
> This is required to bring Mali450 gpu out of reset.
>
> Signed-off-by: Peter Griffin
> ---
> drivers/reset/hisilicon/hi6220_reset.c | 51
> +-
> 1 file changed, 50 insertions(+), 1 deletion(-)
On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
From: Swati Sharma
Added state checker to validate gamma_lut values. This
reads hardware state, and compares the originally requested
state to the state read from hardware.
This implementation can
Op 19-03-2019 om 17:18 schreef Ville Syrjälä:
> On Tue, Mar 19, 2019 at 05:06:36PM +0100, Maarten Lankhorst wrote:
>> Op 19-03-2019 om 14:02 schreef Ville Syrjälä:
>>> On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
There has unfortunately been a conflict with the following
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 18
Attach HDR metadata property to connector object.
v2: Rebase
v3: Updated the property name as per updated name
while creating hdr metadata property
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
v2:
From: Ville Syrjälä
This is to limit PORT C on GLK to drive only
HDMI. Not sure if this is mandatory, this is just
to test HDR on GLK HDMI.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
This patch implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is returned as blob in get
property call to userspace.
v2: Rebase and added Ville's POC changes
v3: No Change
v4: Addressed Shashank's
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe
Added the const version of infoframe for DRM metadata
for HDR.
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 63 ++--
include/linux/hdmi.h | 5 +
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/video/hdmi.c
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c | 15 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 4
2 files changed, 18 insertions(+), 1 deletion(-)
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 49
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
v2: Rebase and modified the metadata structure elements
as per Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments
v5: Rebase.
1 - 100 of 163 matches
Mail list logo
