[PATCH v2] drm: Provide a driver hook for drm_dev_release()

Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e. the current pattern of the driver tearing d

[PATCH v3] drm: Provide a driver hook for drm_dev_release()

Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e. the current pattern of the driver tearing d

Re: [PATCH v3] drm: Provide a driver hook for drm_dev_release()

Den 21.01.2017 11:58, skrev Chris Wilson: Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e

Re: [PATCH v3] drm: Provide a driver hook for drm_dev_release()

On Sat, Jan 21, 2017 at 12:02:03PM +0100, Noralf Trønnes wrote: > > Den 21.01.2017 11:58, skrev Chris Wilson: > >Some state is coupled into the device lifetime outside of the > >load/unload timeframe and requires teardown during final unreference > >from drm_dev_release(). For example, dmabufs hol

Re: [Intel-gfx] [PATCH 0/4] Add automation support for DP Compliance (Rev 6)

On Sat, 21 Jan 2017, Manasi Navare wrote: > This patch series addresses all the review comments from the previous series: > https://patchwork.freedesktop.org/series/18256/ It does not, and it frustrates me. BR, Jani. > > On top of that it also adds a fix for CRC mismatches seen during > 18bpp

[PATCH v2 00/26] drm/rockchip: MIPI fixes & improvements

This is a re-roll of a series originally posted back in September [1]. It's mostly unchanged but in response to Chris and Mark's feedback I have dropped the first two patches and replaces them with the new patches 3 and 4; it's a slightly different approach from Mark's suggestion because it turns o

[PATCH v2 20/26] drm/rockchip: dw-mipi-dsi: use specific poll helper

As the documentation for readx_poll_timeout says, we want to use the specialized macro for readl rather than using the generic version directly. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletion

[PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the commit function (or even the enable function, but switching from commit to enable is left for a future patch). Signed-off-by: John Keeping --- v2: - also move dw

[PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

As a side-effect of this, encode the endianness explicitly rather than casting a u16. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/

[PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

This is not needed since we can access the mode via the CRTC from the enable hook. Also remove the "mode" field that is no longer used. Signed-off-by: John Keeping --- New in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff

[PATCH v2 05/26] drm/rockchip: dw-mipi-dsi: fix command header writes

In a couple of places here we use "val" for the value that is about to be written to a register but then reuse the same variable for the value of a status register before we get around to writing it. Rename the value to be written to so that we write the value we intend to and not what we have jus

[PATCH v2 19/26] drm/rockchip: dw-mipi-dsi: improve PLL configuration

The multiplication ratio for the PLL is required to be even due to the use of a "by 2 pre-scaler". Currently we are likely to end up with an odd multiplier even though there is an equivalent set of parameters with an even multiplier. For example, using the 324MHz bit rate with a reference clock o

[PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

These values are specified as constant time periods but the PHY configuration is in terms of the current lane byte clock so using constant values guarantees that the timings will be outside the specification with some display configurations. Derive the necessary configuration from the byte clock i

[PATCH v2 22/26] drm/rockchip: vop: test for P{H,V}SYNC

When connected to the MIPI DSI output, we need to use N{H,V}SYNC for the internal connection but these flags are meaningless for DSI panels. Switch the test so that we do not set the P{H,V}SYNC bits unless the mode requires it. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/

[PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

As an aid to debugging. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index 2e6ad4591ebf..92dbc3e566

[PATCH v2 10/26] drm/rockchip: dw-mipi-dsi: only request HS clock when required

Requesting the HS clock from the PHY before we initialize it causes an invalid signal to be sent out since the input clock is not yet configured. The PHY databook suggests only asserting this signal when performing HS transfers, so let's do that. Signed-off-by: John Keeping --- Unchanged in v2 -

[PATCH v2 14/26] drm/rockchip: dw-mipi-dsi: fix escape clock rate

Use the same calculation as the vendor kernel to derive the escape clock speed. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/

[PATCH v2 23/26] drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded

This ensures that the output resolution is known before fbcon loads. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/dr

[PATCH v2 17/26] drm/rockchip: dw-mipi-dsi: don't enable PHY PLL until it's configured

Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index ce1e6f9a2041..cfe7e4ba305c 100644 --- a/drivers/gpu

[PATCH v2 13/26] drm/rockchip: dw-mipi-dsi: allow commands in panel_disable

Panel drivers may want to sent commands during the disable function, for example MIPI_DCS_SET_DISPLAY_OFF before the video signal ends. In order to send commands we need to write to registers, so pclk must be enabled. While changing this, remove the unnecessary code after the panel unprepare call

[PATCH v2 25/26] drm/rockchip: dw-mipi-dsi: add reset control

In order to fully reset the state of the MIPI controller we must assert this reset. This is slightly more complicated than it could be in order to maintain compatibility with device trees that do not specify the reset property. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm

[PATCH v2 12/26] drm/rockchip: dw-mipi-dsi: prepare panel after phy init

Some panels need to be configured with commands sent over the MIPI link, which they will do in the prepare hook. Call this after the PHY has been initialized so that we are able to send commands to the panel. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-d

[PATCH v2 21/26] drm/rockchip: dw-mipi-dsi: use positive check for N{H, V}SYNC

This matches other drivers. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index 3e19693ae59b..e448

[PATCH v2 11/26] drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned

By dereferencing the MIPI command buffer as a u32* we rely on it being correctly aligned on ARM, but this may not be the case. Copy it into a stack variable that will be correctly aligned. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 12 +++---

[PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

This shows that we only use the mode from the enable function and prepares us to remove the "mode" field and the mode_set hook in the next commit. Signed-off-by: John Keeping --- New in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 41 ++ 1 file changed, 22 inse

[PATCH v2 02/26] drm/rockchip: dw-mipi-dsi: rename commit hook to enable

Rockchip DRM is fully atomic and commit is deprecated for atomic drivers. No changed are needed beyond renaming the function. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/driver

[PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

Instead of always sending commands in LP mode, respect the MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also request acks if MIPI_DSI_MSG_REQ_ACK is set. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +++- 1 file cha

[PATCH v2 24/26] drm/rockchip: dw-mipi-dsi: support non-burst modes

Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index 2dafb17e31d2..881bb0c62ca5 100644

[PATCH v2 16/26] drm/rockchip: dw-mipi-dsi: configure bias and bandgap before enable

We should configure these functions before enabling them. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-

[PATCH v2 15/26] drm/rockchip: dw-mipi-dsi: ensure PHY is reset

Also don't power up the DSI host at this point since this is not necessary in order to configure the PHY and we do so later when selecting video or command mode. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 - 1 file changed, 4 insertions(+),

[PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

I haven't found any method for getting the length of a response, so this just uses the requested rx_len Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++ 1 file changed, 54 insertions(+) diff --git a/drivers/gpu/d

[PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits are set so we can't just check "val & mask" because that will be true if either bit is set. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 5 +++-- 1 file changed, 3 insertions(+),

Warning at drivers/gpu/drm/drm_atomic_helper.c

Hi, Stopping kmscube application on mx6q through CTRL + C sometimes leads to the following kernel warning: ^C[ 3939.785516] [ cut here ] [ 3939.790313] WARNING: CPU: 1 PID: 67 at drivers/gpu/drm/drm_atomic_helper.c:1032 drm_atomic_helper_wait_for_fences+0xe4/0x104 [ 3939.8

[Bug 193081] New: amdgpu-related kernel output delays booting/suspending/resuming

https://bugzilla.kernel.org/show_bug.cgi?id=193081 Bug ID: 193081 Summary: amdgpu-related kernel output delays booting/suspending/resuming Product: Drivers Version: 2.5 Kernel Version: 4.9.x, 4.10-rcX Hardware: All

[Bug 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly

https://bugs.freedesktop.org/show_bug.cgi?id=99484 Bug ID: 99484 Summary: Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly Product: Mesa Version: git Hardware: x86-64 (AMD64)

[Bug 98520] System randomly crashes / freezes while playing certain games

https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #32 from Ali Hakkı Demiral --- i test on windows 10 with Uniengine Heaven directx 11 it crash again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

Re: [PATCH libdrm v3 2/5] xf86drm: Add USB support

Am 19.01.2017 11:20, schrieb Thierry Reding: > Adding back dri-devel@lists.freedesktop.org > > On Wed, Jan 18, 2017 at 12:21:23PM +0100, walter harms wrote: >> >> >> Am 18.01.2017 10:02, schrieb Thierry Reding: >>> Allow DRM/KMS devices hosted on USB to be detected by the drmDevice >>> infrastru

[PATCH] drm: Update drm_cache.c to pull in the new drm_cache.h

The prototypes were moved to a new header, but the function definitions were not updated to pull in the declarations. drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for ‘drm_clflush_pages’ [-Wmissing-prototypes] drivers/gpu/drm/drm_cache.c:120:1: warning: no previous prototype f

[Bug 99486] AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2

https://bugs.freedesktop.org/show_bug.cgi?id=99486 Bug ID: 99486 Summary: AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

[Bug 99486] AMDGPU/Iceland Kernel 4.9.5 lock-up while playing ETS2

https://bugs.freedesktop.org/show_bug.cgi?id=99486 --- Comment #1 from Armin K --- Created attachment 129088 --> https://bugs.freedesktop.org/attachment.cgi?id=129088&action=edit dmesg output of the currently running system xf86-video-amdgpu 1.2.0 mesa 13.0.3 xorg-server 1.19.1 linux 4.9.5 GN

Re: [PATCH] drm: Update drm_cache.c to pull in the new drm_cache.h

Chris Wilson writes: > The prototypes were moved to a new header, but the function definitions > were not updated to pull in the declarations. > > drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for > ‘drm_clflush_pages’ [-Wmissing-prototypes] > drivers/gpu/drm/drm_cache.c:120:1

[Bug 99419] Crash(Segmentation fault) si_shader_select in Master Of Orion

https://bugs.freedesktop.org/show_bug.cgi?id=99419 Andreas Schultes changed: What|Removed |Added See Also||https://bugs.freedesktop.or

Re: [PATCH v3] drm: Provide a driver hook for drm_dev_release()

Hi Chris, Thank you for the patch. On Saturday 21 Jan 2017 10:58:25 Chris Wilson wrote: > Some state is coupled into the device lifetime outside of the > load/unload timeframe and requires teardown during final unreference > from drm_dev_release(). For example, dmabufs hold both a device and > mo

Re: [PATCH v2 18/26] drm/rockchip: dw-mipi-dsi: properly configure PHY timing

On 01/22/2017 12:31 AM, John Keeping wrote: These values are specified as constant time periods but the PHY configuration is in terms of the current lane byte clock so using constant values guarantees that the timings will be outside the specification with some display configurations. Derive t

Re: [PATCH v2 26/26] drm/rockchip: dw-mipi-dsi: support read commands

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: I haven't found any method for getting the length of a response, so this just uses the requested rx_len Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 54 ++ 1 f

[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted

https://bugs.freedesktop.org/show_bug.cgi?id=99444 --- Comment #6 from Shmerl --- (In reply to Grazvydas Ignotas from comment #5) > > They range from GL_COMBINER0_NV (0x8550) to 0x857f, so probably the trace > was recorded on something supporting more texture units than radeonsi? Was > the trace

Re: [PATCH v2 01/26] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

Hi John On 01/22/2017 12:31 AM, John Keeping wrote: With atomic modesetting the hardware will be powered off when the mode_set function is called. We should configure the hardware in the commit function (or even the enable function, but switching from commit to enable is left for a future patc

Re: [PATCH v2 03/26] drm/rockchip: dw-mipi-dsi: pass mode in where needed

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This shows that we only use the mode from the enable function and prepares us to remove the "mode" field and the mode_set hook in the next commit. Signed-off-by: John Keeping --- New in v2 --- drivers/gpu/drm/rock

Re: [PATCH v2 04/26] drm/rockchip: dw-mipi-dsi: remove mode_set hook

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: This is not needed since we can access the mode via the CRTC from the enable hook. Also remove the "mode" field that is no longer used. Signed-off-by: John Keeping --- New in v2 --- drivers/gpu/drm/rockchip/dw-m

[RFC PATCH v2 0/5] Add vblank hooks to struct drm_crtc_funcs

From: Shawn Guo The vblank is mostly CRTC specific and implemented as part of CRTC driver. The first patch adds 3 vblank core-driver hooks into struct drm_crtc_funcs, and wraps around core vblank handling code to use the new hooks for modern MODESET drivers and the ones in struct drm_driver as f

[RFC PATCH v2 2/5] drm: hdlcd: use vblank hooks in struct drm_crtc_funcs

From: Shawn Guo The vblank hooks in struct drm_driver are deprecated and only meant for legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks in struct drm_crtc_funcs should be used instead. Signed-off-by: Shawn Guo Cc: Liviu Dudau --- drivers/gpu/drm/arm/hdlcd_crtc.c | 20 +

[RFC PATCH v2 1/5] drm: add vblank hooks to struct drm_crtc_funcs

From: Shawn Guo The vblank is mostly CRTC specific and implemented as part of CRTC driver. Let's keep the vblank hooks struct drm_driver for legacy drivers, and add corresponding hooks in struct drm_crtc_funcs. These hooks take struct drm_crtc pointer as argument, and will be called by core vbl

[RFC PATCH v2 5/5] drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs

From: Shawn Guo With the vblank hooks in struct drm_crtc_funcs, we do not need to maintain the CRTC specific vblank callbacks with struct imx_drm_crtc_helper_funcs any more. By moving the stuff that we currently do in imx_drm_add_crtc(), like of_node setting and drm_crtc_helper_add()/drm_crtc_in

[RFC PATCH v2 3/5] drm: zte: zx_vou_enable[disable]_vblank can be static

From: Shawn Guo With the vblank hooks in struct drm_crtc_funcs, we can directly use the drm_crtc pointer passed in as parameter and make the functions static. The functions are moved around to save forward delarations. Signed-off-by: Shawn Guo --- drivers/gpu/drm/zte/zx_drm_drv.c | 2 -- dri

[RFC PATCH v2 4/5] drm: rockchip: remove struct rockchip_crtc_funcs

From: Shawn Guo With the vblank hooks in struct drm_crtc_funcs, we do not need to maintain struct rockchip_crtc_funcs and the related registration functions. Remove them. Signed-off-by: Shawn Guo Cc: Mark Yao --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 51 -

Re: [PATCH v2 06/26] drm/rockchip: dw-mipi-dsi: fix generic packet status check

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: We want to check that both the GEN_CMD_EMPTY and GEN_PLD_W_EMPTY bits are set so we can't just check "val & mask" because that will be true if either bit is set. According to DW mipi dsi controller databook, you are r

Re: [PATCH v2 07/26] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As a side-effect of this, encode the endianness explicitly rather than casting a u16. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++-- 1 file changed, 7 in

Re: [PATCH v2 08/26] drm/rockchip: dw-mipi-dsi: include bad value in error message

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: As an aid to debugging. Signed-off-by: John Keeping --- Unchanged in v2 --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/d

[Bug 96488] [r600g]OpenCL driver causes segfault in ImageMagick's Histogram kernel

https://bugs.freedesktop.org/show_bug.cgi?id=96488 nixscrip...@gmail.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [PATCH v2 09/26] drm/rockchip: dw-mipi-dsi: respect message flags

Hi John Reviewed-by: Chris Zhong On 01/22/2017 12:31 AM, John Keeping wrote: Instead of always sending commands in LP mode, respect the MIPI_DSI_MSG_USE_LPM flag to decide how to send each message. Also request acks if MIPI_DSI_MSG_REQ_ACK is set. Signed-off-by: John Keeping --- Unchanged i

[Bug 99488] [r600g]OpenCL driver causes process to hang in ImageMagick's Gaussian Blur kernel

https://bugs.freedesktop.org/show_bug.cgi?id=99488 Bug ID: 99488 Summary: [r600g]OpenCL driver causes process to hang in ImageMagick's Gaussian Blur kernel Product: Mesa Version: git Hardware: x86-64 (AMD64)