[PATCH v3 RESEND 19/24] drm/exynos/gscaler: fix id assignement

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 f048d97fe9e2..8d5aa70c8ab

[PATCH v3 RESEND 08/24] drm/exynos/decon7: embed exynos_drm_crtc directly into context

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 +++

[PATCH v3 RESEND 16/24] drm/exynos: set cursor plane in exynos_drm_crtc_init

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

[PATCH v3 RESEND 01/24] arm64: dts: exynos: configure GSCALER related clocks

GSCALER should be feed with clock at certain rates. Signed-off-by: Andrzej Hajda --- Already merged !!! --- 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

[PATCH v3 RESEND 13/24] drm/exynos/vidi: remove encoder_to_vidi helper

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 index

[PATCH v3 RESEND 06/24] drm/exynos: add exynos_drm_crtc_init function

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 overloa

[PATCH v3 RESEND 05/24] drm/exynos: drop exynos_drm_plane_config structure

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 c

[PATCH v3 RESEND 24/24] drm/exynos/gscaler: fix handling YVU420 pixel format

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 b/drivers/gpu/drm/exynos/exynos_

[PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433

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 Di

[PATCH v3 RESEND 09/24] drm/exynos/fimd: embed exynos_drm_crtc directly into context

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 -

[PATCH v3 RESEND 21/24] drm/exynos/decon5433: add local path support

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 callbac

[PATCH v3 RESEND 04/24] drm/exynos: remove spare macro

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 --- a/drivers/

[PATCH v3 RESEND 15/24] drm/exynos: set primary plane in exynos_drm_crtc_init

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 - drivers/gpu/

[PATCH v3 RESEND 18/24] drm/exynos: add GSCALER plane capability

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 --- drivers/gpu/drm/exynos/exy

[PATCH v3 RESEND 03/24] drm/exynos: remove exynos_drm_plane.h header

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 - drivers/gpu/drm

[PATCH v3 RESEND 10/24] drm/exynos/mixer: embed exynos_drm_crtc directly into context

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 ++--

[PATCH v3 RESEND 23/24] drm/exynos/gscaler: change supported color format BGRX8888 to XBGR8888

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 i

[PATCH v3 RESEND 02/24] arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs

To support local paths both DECON and GSCALER should enable respective Smart Deck clocks DSD and GSD. Signed-off-by: Andrzej Hajda --- Already merged!!! --- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/arc

[PATCH v3 RESEND 20/24] drm/exynos/gscaler: add local path support

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

[PATCH v3 RESEND 11/24] drm/exynos/vidi: embed exynos_drm_crtc directly into context

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 +

[PATCH v3 RESEND 22/24] drm/exynos/decon5433: wait for finish previous update

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: 1

[PATCH v3 RESEND 14/24] drm/exynos: unify plane type assignment

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 +-- drivers/gpu/drm/exynos/exynos7_drm_d

[PATCH v3 RESEND 17/24] drm/exynos: add plane update/disable callbacks for planes

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 ins

[PATCH v3 RESEND 07/24] drm/exynos/decon5433: embed exynos_drm_crtc directly into context

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

[PATCH v3 RESEND 12/24] drm/exynos: remove standalone exynos_drm_crtc leftovers

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 drivers/gpu/drm/exynos/exynos_drm_drv.

Re: [PATCH v2 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433

Hi Inki, On 25.03.2019 04:12, Inki Dae wrote: > Hi Andrzej, > > Merge conflict. Could you rebase this patch series on top of exynos-drm-next? I have just sent rebased version. Please be just aware that first two DTS patches has been already applied to samsung-soc tree. Regards Andrzej

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 Bug ID: 110233 Summary: Cannot install the dirvier for vega 56 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severi

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 --- Comment #1 from lingke li --- Created attachment 143770 --> https://bugs.freedesktop.org/attachment.cgi?id=143770&action=edit basic conf -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 --- Comment #2 from lingke li --- Created attachment 143771 --> https://bugs.freedesktop.org/attachment.cgi?id=143771&action=edit dkms.status -- You are receiving this mail because: You are the assignee for the bug.__

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 --- Comment #3 from lingke li --- Created attachment 143772 --> https://bugs.freedesktop.org/attachment.cgi?id=143772&action=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 --- Comment #4 from lingke li --- Created attachment 143773 --> https://bugs.freedesktop.org/attachment.cgi?id=143773&action=edit lsmod amdgpu -- You are receiving this mail because: You are the assignee for the bug._

[Bug 110233] Cannot install the dirvier for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 --- Comment #5 from lingke li --- Created attachment 143774 --> https://bugs.freedesktop.org/attachment.cgi?id=143774&action=edit package -- You are receiving this mail because: You are the assignee for the bug.__

Re: [PATCH v3 RESEND 01/24] arm64: dts: exynos: configure GSCALER related clocks

On Mon, 25 Mar 2019 at 08:13, Andrzej Hajda wrote: > > GSCALER should be feed with clock at certain rates. > > Signed-off-by: Andrzej Hajda > --- > Already merged !!! Then you should skip it because someone might not notice it and apply second time. Best regards, Krzysztof _

[PATCH v2] dma-fence: Propagate errors to dma-fence-array container

When one of the array of fences is signaled, propagate its errors to the parent fence-array (keeping the first error to be raised). v2: Opencode cmpxchg_local to avoid compiler freakout. Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan --- drivers/dma-buf/dma-fence-array.c | 1

[PATCH] gpu: v3d: fix a missing check of pm_runtime_get_sync

pm_runtime_get_sync could fail and thus deserves a check. The patch adds such a check and return its error code upstream if it indeed failed. Signed-off-by: Kangjie Lu --- drivers/gpu/drm/v3d/v3d_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers

Re: [PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver

Dne ponedeljek, 25. marec 2019 ob 02:35:31 CET je Laurent Pinchart napisal(a): > Hi Jernej, > > Thank you for the patch. > > On Sun, Mar 24, 2019 at 10:21:42PM +0100, Jernej Skrabec wrote: > > DW HDMI controller on some Allwinner SoCs has support for CEC, but due > > to additional logic put betwe

[PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver

DW HDMI controller on some Allwinner SoCs has support for CEC, but due to additional logic put between CEC controller and pins, it doesn't work correctly, at least not with a lot of instrusive changes. Fortunately, it's still possible to bitbang protocol. For such cases, add a platform option to s

Re: [PATCH] gpu: v3d: fix a missing check of pm_runtime_get_sync

On 3/25/2019 4:46 AM, Kangjie Lu wrote: pm_runtime_get_sync could fail and thus deserves a check. The patch adds such a check and return its error code upstream if it indeed failed. Signed-off-by: Kangjie Lu Reviewed-by: Mukesh Ojha > Thanks. Mukesh --- d

[PATCH 0/2] drm/sun4i: dw-hdmi: Improve CEC support

It turns out that additional logic between HDMI CEC controller and pins on PHY on some Allwinner SoCs prevents proper communication. It might be possible to fix it, but it's much easier and less error prone to just directly drive pins using software implementation of CEC protocol. Let me know what

[PATCH] drm/sun4i: DW HDMI: Lower max. supported rate for H6

Currently resolutions with pixel clock higher than 340 MHz don't work with H6 HDMI controller. They just produce a blank screen. Limit maximum pixel clock rate to 340 MHz until scrambling is supported. Cc: sta...@vger.kernel.org # 5.0 Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI co

[PATCH 2/2] drm/sun4i: dw-hdmi: Bit bang CEC on some SoCs

All DW HDMI controllers used by Allwinner SoCs include CEC controller. However, due to additional logic put between CEC controller and pins, CEC communication doesn't work well on some of them. Based on observations, it seems that only outgoing messages are properly transmitted. It's possible that

[Bug 110233] Cannot install the driver for vega 56

https://bugs.freedesktop.org/show_bug.cgi?id=110233 Andre Klapper changed: What|Removed |Added Resolution|--- |INVALID Summary|Cannot insta

Re: [PATCH v3 RESEND 01/24] arm64: dts: exynos: configure GSCALER related clocks

On 25.03.2019 08:50, Krzysztof Kozlowski wrote: > On Mon, 25 Mar 2019 at 08:13, Andrzej Hajda wrote: >> GSCALER should be feed with clock at certain rates. >> >> Signed-off-by: Andrzej Hajda >> --- >> Already merged !!! > Then you should skip it because someone might not notice it and apply > sec

Re: [PATCH v2] drm: vkms: check status of alloc_ordered_workqueue

On Sat, Mar 23, 2019 at 04:42:16PM -0500, Kangjie Lu wrote: > alloc_ordered_workqueue may fail and return NULL. > The fix cleans up drm plans and returns ENOMEM when it fails to > avoid potential NULL pointer dereference. > > Signed-off-by: Kangjie Lu > --- > V2: clean up resources > --- > drive

[PATCH 1/9] dma-buf: add new dma_fence_chain container v7

From: Christian König Lockless container implementation similar to a dma_fence_array, but with only two elements per node and automatic garbage collection. v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno, drop prev reference during garbage collection if it's no

[PATCH 4/9] drm/syncobj: add timeline payload query ioctl v6

user mode can query timeline payload. v2: check return value of copy_to_user v3: handle querying entry by entry v4: rebase on new chain container, simplify interface v5: query last signaled timeline point, not last point. v6: add unorder point check Signed-off-by: Chunming Zhou Cc: Tobias Hector

[PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

From: Christian König Use the dma_fence_chain object to create a timeline of fence objects instead of just replacing the existing fence. v2: rebase and cleanup v3: fix garbage collection parameters v4: add unorder point check, print a warn calltrace Signed-off-by: Christian König Cc: Lionel La

[PATCH 5/9] drm/syncobj: use the timeline point in drm_syncobj_find_fence v4

From: Christian König Implement finding the right timeline point in drm_syncobj_find_fence. v2: return -EINVAL when the point is not submitted yet. v3: fix reference counting bug, add flags handling as well v4: add timeout for find fence Signed-off-by: Christian König Cc: Lionel Landwerlin --

Re: [PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver

Le 25/03/2019 02:35, Laurent Pinchart a écrit : > Hi Jernej, > > Thank you for the patch. > > On Sun, Mar 24, 2019 at 10:21:42PM +0100, Jernej Skrabec wrote: >> DW HDMI controller on some Allwinner SoCs has support for CEC, but due >> to additional logic put between CEC controller and pins, it

[PATCH 3/9] drm/syncobj: add support for timeline point wait v8

points array is one-to-one match with syncobjs array. v2: add seperate ioctl for timeline point wait, otherwise break uapi. v3: userspace can specify two kinds waits:: a. Wait for time point to be completed. b. and wait for time point to become available v4: rebase v5: add comment for xxx_WAIT_AVAI

[PATCH 6/9] drm/amdgpu: add timeline support in amdgpu CS v3

syncobj wait/signal operation is appending in command submission. v2: separate to two kinds in/out_deps functions v3: fix checking for timeline syncobj Signed-off-by: Chunming Zhou Cc: Tobias Hector Cc: Jason Ekstrand Cc: Dave Airlie Cc: Chris Wilson Cc: Lionel Landwerlin --- drivers/gpu/dr

[PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v5

v2: individually allocate chain array, since chain node is free independently. v3: all existing points must be already signaled before cpu perform signal operation, so add check condition for that. v4: remove v3 change and add checking to prevent out-of-order v5: unify binary and timeline Sig

[PATCH 9/9] drm/amdgpu: update version for timeline syncobj support in amdgpu

Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 8a0732088640..4d8db87048d3 100644 --- a/drivers/gpu/drm/amd/amdgp

[PATCH 7/9] drm/syncobj: add transition iotcls between binary and timeline v2

we need to import/export timeline point. v2: unify to one transfer ioctl Signed-off-by: Chunming Zhou Cc: Lionel Landwerlin --- drivers/gpu/drm/drm_internal.h | 2 + drivers/gpu/drm/drm_ioctl.c| 2 + drivers/gpu/drm/drm_syncobj.c | 74 ++ include/uapi/drm

Re: [PATCH] drm: vkms: check status of alloc_ordered_workqueue

On Fri, Mar 22, 2019 at 09:32:07PM -0500, Kangjie Lu wrote: > > > > On Mar 8, 2019, at 10:36 PM, Kangjie Lu wrote: > > > > alloc_ordered_workqueue may fail and return NULL. > > The fix returns ENOMEM when it fails to avoid potential NULL > > pointer dereference. > > > > Signed-off-by: Kangjie

Re: [PATCH v2 0/3] drm: Add panic handling

On Mon, Mar 18, 2019 at 12:06:13AM +0100, Ahmed S. Darwish wrote: > > => Now that the dust has settled, here's a summary of this huge >50-email thread (thanks Daniel, Noralf, John, everyone!). > > => Parts of this document are a direct rewording of Daniel's replies, >so I took the liberty

Re: [PATCH v3 RESEND 01/24] arm64: dts: exynos: configure GSCALER related clocks

On Mon, 25 Mar 2019 at 09:32, Andrzej Hajda wrote: > > On 25.03.2019 08:50, Krzysztof Kozlowski wrote: > > On Mon, 25 Mar 2019 at 08:13, Andrzej Hajda wrote: > >> GSCALER should be feed with clock at certain rates. > >> > >> Signed-off-by: Andrzej Hajda > >> --- > >> Already merged !!! > > Then

Re: [PATCH -next] drm/ttm: remove set but not used variable 'vgdev'

On Wed, Mar 20, 2019 at 02:03:08AM +, YueHaibing wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type': > drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning: > variable 'vgdev' set but not used [-Wunused-but-

Re: [Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers

On Fri, Mar 15, 2019 at 06:56:07AM -0500, Benoit Parrot wrote: > Daniel Vetter wrote on Fri [2019-Mar-15 11:50:57 +0100]: > > On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote: > > > During a suspend cycle the atomic state is saved to be used during the > > > restore cycle. > > > > >

Re: [PATCH] drm/i915: Fix an error code in i915_gem_context_open()

Quoting Dan Carpenter (2019-03-25 09:23:49) > If gem_context_register() fails then "ctx" is a valid pointer, not an > error pointer. We should just return "err". > > Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and > registration to userspace") > Signed-off-by: Dan Carpenter

[PATCH] drm/i915: Fix an error code in i915_gem_context_open()

If gem_context_register() fails then "ctx" is a valid pointer, not an error pointer. We should just return "err". Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace") Signed-off-by: Dan Carpenter --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- 1

[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration

https://bugs.freedesktop.org/show_bug.cgi?id=110217 Michel Dänzer changed: What|Removed |Added Attachment #143755|text/x-log |text/plain mime type|

[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.

https://bugs.freedesktop.org/show_bug.cgi?id=110229 Michel Dänzer changed: What|Removed |Added Component|Drivers/DRI/R100|Drivers/Gallium/r600 -- You are receiv

[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU

https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #3 from fin4...@hotmail.com --- You both have cheap low quality Sapphire cards with 2 year warranty here when Asus has 3 years. Custom bios in those cards are famous to cause problems with Linux. -- You are receiving this mail becau

[Bug 110229] The driver is not waiting the shader have finished to update the framebuffer before displaying it.

https://bugs.freedesktop.org/show_bug.cgi?id=110229 Michel Dänzer changed: What|Removed |Added Version|18.3|19.0 -- You are receiving this mail be

Re: [PATCH] drm/meson: fix TMDS clock filtering for DMT monitors

On 20/03/2019 09:11, Neil Armstrong wrote: > DMT monitors does not necessarely report a maximum TMDS clock > in a VSDB EDID extension. > > In this case, all modes are wrongly rejected, including > the DRM fallback EDID. > > This patch only rejects modes whith clock > max_tmds_clock if > the max_t

Re: [PATCH] drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups

Hi Andrzej, Laurent, Gentle ping, Did you have time to review this fix ? Thanks ! Neil On 15/03/2019 10:54, Neil Armstrong wrote: > This patch is an attempt to limit HDMI 2.0 SCDC setup when : > - the SoC embeds an HDMI 1.4 only controller > - the EDID supports SCDC but not scrambling > - the ED

Re: [PATCH libdrm] intel: sync i915_pciids.h with kernel

On Fri, 22 Mar 2019, "Souza, Jose" wrote: > On Fri, 2019-03-22 at 13:35 -0700, Anusha wrote: >> Straight copy from the kernel file. >> >> Add PCI IDs for CML, add additional PCI ID >> for ICL. >> >> Align with kernel commits: >> >> a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS") >> 9a751b999d17

Re: [PATCH 1/2] drm/meson: Fix invalid pointer in meson_drv_unbind()

On 22/03/2019 16:26, Jean-Philippe Brucker wrote: > meson_drv_bind() registers a meson_drm struct as the device's privdata, > but meson_drv_unbind() tries to retrieve a drm_device. This may cause a > segfault on shutdown: > > [ 5194.593429] Unable to handle kernel NULL pointer dereference at virtu

[Bug 110217] RX580: screen turns black or flickers until forced reconfiguration

https://bugs.freedesktop.org/show_bug.cgi?id=110217 Michel Dänzer changed: What|Removed |Added Attachment #143754|text/x-log |text/plain mime type|

Re: [PULL] drm-misc-next

On Thu, Mar 21, 2019 at 6:08 PM Sean Paul wrote: > > > Hi Da.*, > Here's the first 5.2 PR from -misc. There's a bit of everything in the PR, > enjoy! Pulled, thanks. -Daniel > drm-misc-next-2019-03-21: > drm-misc-next for 5.2: > > UAPI Changes: > - Add Colorspace connector property (Uma) > - fou

Re: [PATCH] gpu: radeon: fix a potential NULL-pointer dereference

Hi Kangjie, thanks for your patch. On 2019-03-23 3:29 a.m., Kangjie Lu wrote: > In case alloc_workqueue fails, the fix frees memory and > returns to avoid potential NULL pointer dereference. > > Signed-off-by: Kangjie Lu > --- > drivers/gpu/drm/radeon/radeon_display.c | 5 + > 1 file ch

[PULL] drm-misc-fixes

Hi Daniel, Dave, Here is a PR for drm-misc-fixes. Thanks! Maxime drm-misc-fixes-2019-03-25: - A bunch of fixes to cleanup path in meson - Fix the DMT TDMS clock filtering on meson - Fix an issue with NV12 buffers on rockchip when scaling is active - Fix a couple of use-after-free The following c

Re: [PATCH 1/2] dma-fence: Propagate errors to dma-fence-array container

Hi Chris, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.1-rc2 next-20190325] [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/linux

Re: [PATCH V2] drm/atomic-helper: Make atomic_enable/disable crtc callbacks optional

On 03/15, Daniel Vetter wrote: > On Thu, Mar 14, 2019 at 03:48:45PM -0300, Rodrigo Siqueira wrote: > > Allow atomic_enable and atomic_disable operations from > > drm_crtc_helper_funcs struct optional. With this, the target display > > drivers don't need to define a dummy function if they don't need

Re: [PATCH] drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups

On 15.03.2019 10:54, Neil Armstrong wrote: > This patch is an attempt to limit HDMI 2.0 SCDC setup when : > - the SoC embeds an HDMI 1.4 only controller > - the EDID supports SCDC but not scrambling > - the EDID supports SCDC scrambling but not for low TMDS bit rates, > while only supporting low

Re: INFO: task hung in process_measurement

On 23/03/2019 08:58, syzbot wrote: > syzbot has bisected this bug to: > > commit 8fe5616b20e5742bb5fee0e77dffe2fc76ac92a0 > Author: Jyri Sarha > Date:   Tue Jun 14 08:43:30 2016 + > >     drm/tilcdc: Restore old dpms state in pm_resume() > > bisection log:  https://syzkaller.appspot.com/x/b

Re: [PATCH] drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups

On 25/03/2019 12:37, Andrzej Hajda wrote: > On 15.03.2019 10:54, Neil Armstrong wrote: >> This patch is an attempt to limit HDMI 2.0 SCDC setup when : >> - the SoC embeds an HDMI 1.4 only controller >> - the EDID supports SCDC but not scrambling >> - the EDID supports SCDC scrambling but not for lo

[PULL] drm-intel-next

Hi Dave & Daniel, First batch of features for 5.2, tagged last week. Most notably there are a lot of Icelake fixes that finally lead to removal of alpha_support protection for it. We're also adding Cometlake PCI IDs (Gen9 ~= Coffeelake), so those platforms should be supported. Then we have HDCP

Re: [PATCH 5/7] drm/vc4: Disable V3D interactions if the v3d component didn't probe.

Hi, On Wed, 2019-02-20 at 13:03 -0800, Eric Anholt wrote: > One might want to use the VC4 display stack without using Mesa. > Similar to the debugfs fixes for not having all of the possible > display bits enabled, make sure you can't oops in vc4 if v3d isn't > enabled. See a comment below. > Sig

[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator

https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #11 from glencoesm...@hotmail.com --- Can you reproduce the bug on 18.3.5? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lis

[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator

https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #12 from e88z4 --- I usually build mesa master weekly since November 2018. This bug can be reproduced with latest Mesa from git master branch. Do you want me to try to build 18.3.5 and reproduce it? -- You are receiving this mail

[PATCH v4 1/3] dt-bindings: Add vendor prefix for ROCKTECH DISPLAYS LIMITED

Add ROCKTECH DISPLAYS LIMITED (https://rocktech.com.hk) LCD panel supplier. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree

[PATCH v4 3/3] drm/panel: Add Rocktech jh057n00900 panel driver

Support Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel. It is a MIPI DSI video mode panel. The panel seems to use a Sitronix ST7703 look alike (most of the commands look similar to the ST7703's data sheet but use a different number of parameters). The initial version of the DSI init sequence (in

Re: [PATCH v4 2/3] dt-bindings: Add Rocktech jh057n00900 panel bindings

On Mon, Mar 25, 2019 at 11:06 AM Guido Günther wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > @@ -0,0 +1,18 @@ > +Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel > + > +Required properties: > +- compatible: should be "rocktech,jh057n0090

[PATCH v7 3/3] phy: Add driver for mixel dphy found on imx8

This adds support for the Mixel DPHY as found on i.MX8 CPUs but since this is an IP core it will likely be found on others in the future. So instead of adding this to the nwl host driver make it a generic PHY driver. The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be added on

[PATCH v7 0/3] Mixel DPHY support for i.MX8

tl;dr: v7 fixes a build issued due to the lack of a HAS_IOMEM This adds initial support for the Mixel IP based mipi dphy as found on i.MX8 processors. It has support for the i.MX8MQ, support for other variants can be added - once the platform specific parts are in - via the provided devdata. The

[PATCH v7 2/3] dt-bindings: phy: Add documentation for mixel dphy

Add support for the MIXEL DPHY IP as found in the NXP's i.MX8MQ. Signed-off-by: Guido Günther Reviewed-by: Sam Ravnborg --- .../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/mixel,mi

[PATCH 03/11] drm/meson: Add G12A Support for VPP setup

Amlogic G12A needs a different VPP setup code, handle it here. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_vpp.c | 51 ++- 1 file changed, 29 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_vpp.c b/drivers/gpu/drm/meson/meso

[PATCH 05/11] drm/meson: Add G12A support for OSD1 Plane

Amlogic G12A SoC supports now up to 3 OSD planes (1 more than the previous SoCs) and a brand new OSD plane blender module. This patch uses the same OSD1 plane G12A, using the exact same scaler and OSD1 setup registers, except using the new blender register to disable the plane. Signed-off-by: Nei

[PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer

The Meson G12A SoCs uses the exact same CVBS encoder except a simple CVBS DAC register offset and settings delta. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_venc.c | 11 +-- drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++--- 2 files changed, 2

[PATCH 11/11] drm/meson: Add G12A support for the DW-HDMI Glue

The Amlogic G12A embeds the same Synopsys DW-HDMI Controller, but with : - a "backport" of the HDR signaling registers from more recent DW-HDMI controllers, this will need a tweak since it's not normally present on this version of the DW-HDMI controller - A direct mapping of TOP and DW-HDMI reg

[PATCH 09/11] drm/meson: Add G12A Video Clock setup

While switching to the Common Clock Framework is still Work In Progress, this patch adds the corresponding G12A HDMI PLL setup to be on-par with the other SoCs support. The G12A has only a single tweak about the high frequency setup, where the HDMI PLL needs a specific setup to handle correctly th

[PATCH 10/11] drm/meson: Add G12A compatible

Finally add the Amlogic G12A SoC compatible for the VPU driver. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c index 079d22299d78..faf1b1b0357c 100644 -

[PATCH v4 0/3] drm/panel: Support Rocktech jh057n00900 DSI panel

It's a 5.5" 720x1440 TFT LCD MIPI DSI panel with built in touchscreen and backlight as found in the Librem 5 devkit. These patches are against linux next as of 2019-03-22. v3 got acked by Sam Ravnborg: https://lists.freedesktop.org/archives/dri-devel/2019-March/209326.html Changes from v3 * Fo

[PATCH v4 2/3] dt-bindings: Add Rocktech jh057n00900 panel bindings

The Rocktec jh057n00900 is a 5.5" MIPI DSI video mode panel with a 720x1440 resolution and a built in backlight. Signed-off-by: Guido Günther --- .../display/panel/rocktech,jh057n00900.txt | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree

2019 X.Org Foundation Election Opening in 35 hours

To all X.Org Foundation Members: We've had some problems with the previous ballot (i.e. I didn't create it properly) that opened last Thursday. Apologies to the two people that already voted. We've re-created the ballot (v2). It will open on March 27 at 2am UTC and close on April 11 at 2am UTC

[Bug 203033] New: nouveau hung task

https://bugzilla.kernel.org/show_bug.cgi?id=203033 Bug ID: 203033 Summary: nouveau hung task Product: Drivers Version: 2.5 Kernel Version: 5.0.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NE

[PATCH v7 1/3] dt-bindings: Add vendor prefix for Mixel Inc

Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI PHY driver. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devic

[PATCH 02/11] drm/meson: Add registers for G12A SoC

This patch adds the new VPU registers added since the Amlogic GXM SoCs. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_registers.h | 247 1 file changed, 247 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson

  1   2   >