linux.git/drivers/gpu/drm/rockchip, branch v4.18

drm/rockchip: Disable blending for win0

2018-05-01T19:56:21+00:00

Blending win0 with the background color doesn't seem to work
correctly. We only get the background color, no matter the contents of
the win0 framebuffer.  However, blending pre-multiplied color with the
default opaque black default background color is a no-op, so we can
just disable blending to get the correct result.

Signed-off-by: Kristian H. Kristensen 
Cc: Sandy Huang 
Cc: Sean Paul 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20180418173152.93246-1-hoegsberg@chromium.org

drm/rockchip: psr: Remove flush by CRTC

2018-04-24T06:34:54+00:00

It is not used anymore after last changes and it was not even correct to
begin with as it assumed a 1:1 relation between a CRTC and encoder,
while in fact a CRTC can be attached to multiple encoders.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-28-enric.balletbo@collabora.com

drm/rockchip: Disallow PSR for the whole atomic commit

2018-04-24T06:34:53+00:00

Currently PSR flush is triggered from CRTC's .atomic_begin() callback,
which is executed after modeset disables and enables and before plane
updates are committed. Since PSR flush and re-enable can be triggered
asynchronously by external sources (input event, delayed work), it can
race with hardware programming done in the aforementioned stages.

This patch blocks the PSR completely before hardware programming part
begins and unblock after it ends. This relies on reference counted PSR
disable introduced with previous patch.

Cc: Kristian H. Kristensen 
Signed-off-by: Tomasz Figa 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-27-enric.balletbo@collabora.com

drm/rockchip: psr: Sanitize semantics of allow/inhibit API

2018-04-24T06:34:52+00:00

Currently both rockchip_drm_psr_activate() and _deactivate() only set the
boolean "active" flag without actually making sure that hardware state
complies with it.

Since we are going to extend the usage of this API to properly lock PSR
for the duration of atomic commits, we change the semantics in following
way:
 - a counter is used to track the number of inhibit requests,
 - PSR is actually disabled in hardware on first inhibit request,
 - PSR enable work is scheduled on last allow request.

The above allows using the API as a way to deterministically synchronize
PSR state changes with other DRM events, i.e. atomic commits and cursor
updates. As a nice side effect, the naming is sorted out and we have
"inhibit" for stopping the software logic and "enable" for hardware
state.

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-26-enric.balletbo@collabora.com

drm/rockchip: psr: Avoid redundant calls to .set() callback

2018-04-24T06:34:51+00:00

The first time after we call rockchip_drm_do_flush() after
rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The
difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a
delayed work pending - PSR is off in either state.  However
psr_set_state() only catches the transition from PSR_FLUSH to
PSR_DISABLE (which never happens), while going from PSR_DISABLE to
PSR_FLUSH triggers a call to psr->set() to disable PSR while it's
already disabled. This triggers the eDP PHY power-on sequence without
being shut down first and this seems to occasionally leave the encoder
unable to later enable PSR. Let's just simplify the state machine and
simply consider PSR_DISABLE and PSR_FLUSH the same state.

Signed-off-by: Tomasz Figa 
Signed-off-by: Kristian H. Kristensen 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-25-enric.balletbo@collabora.com

drm/rockchip: analogix_dp: Do not call Analogix code before bind

2018-04-24T06:34:50+00:00

Driver callbacks, such as system suspend or resume can be called any
time, specifically they can be called before the component bind
callback. Let's use dp->adp pointer as a safeguard and skip calling
Analogix entry points if it is an ERR_PTR().

Signed-off-by: Tomasz Figa 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-24-enric.balletbo@collabora.com

drm/bridge: analogix_dp: Split the platform-specific poweron in two parts

2018-04-24T06:34:49+00:00

Some of the platform-specific stuff in rockchip_dp_poweron() needs to
happen before the generic code.  Some needs to happen after.  Let's
split the callback in two.

Specifically we can't start doing PSR work until _after_ the whole
controller is up, so don't set the enable until the end.

Cc: Kristian H. Kristensen 
Signed-off-by: Douglas Anderson 
[seanpaul added exynos change]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-23-enric.balletbo@collabora.com

drm/rockchip: pre dither down when output bpc is 8bit

2018-04-24T06:34:47+00:00

Some encoder have a crc verification check, crc check fail if
input and output data is not equal.

That means encoder input and output need use same color depth,
vop can output 10bit data to encoder, but some panel only support
8bit depth, that would make crc check die.

So pre dither down vop data to 8bit if panel's bpc is 8.

Signed-off-by: Mark Yao 
[seanpaul resolved conflict in rockchip_drm_vop.c]
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Archit Taneja 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-22-enric.balletbo@collabora.com

drm/rockchip: Restore psr->state when enable/disable psr failed

2018-04-24T06:34:40+00:00

If we failed disable psr, it would hang the display until next psr
cycle coming. So we should restore psr->state when it failed.

Cc: Tomasz Figa 
Signed-off-by: zain wang 
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Signed-off-by: Enric Balletbo i Serra 
Tested-by: Marek Szyprowski 
Reviewed-by: Heiko Stuebner 
Reviewed-by: Archit Taneja 
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20180423105003.9004-14-enric.balletbo@collabora.com

drm/rockchip: fix VOP vblank race

2018-04-17T01:18:16+00:00

We have seen a case of a bad reference count for vblanks with the
Rockchip VOP:

	------------[ cut here ]------------
	WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 drm_vblank_put+0x40/0xcc
	Modules linked in: brcmfmac brcmutil
	CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1
	Hardware name: Rockchip (Device Tree)
	Workqueue: events_unbound flip_worker
	Backtrace:
	[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
	 r7:c0b1b13c r6:600b0013 r5:00000000 r4:c0b1b13c
	[] (show_stack) from [] (dump_stack+0x78/0x94)
	[] (dump_stack) from [] (__warn+0xe4/0x104)
	 r7:00000009 r6:c03cf26c r5:00000000 r4:00000000
	[] (__warn) from [] (warn_slowpath_null+0x28/0x30)
	 r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200
	[] (warn_slowpath_null) from [] (drm_vblank_put+0x40/0xcc)
	[] (drm_vblank_put) from [] (drm_crtc_vblank_put+0x18/0x1c)
	 r5:edb47f00 r4:ee3c8a80
	[] (drm_crtc_vblank_put) from [] (vop_fb_unref_worker+0x18/0x24)
	[] (vop_fb_unref_worker) from [] (flip_worker+0x98/0xb4)
	 r5:edb47f00 r4:eeb443a8
	[] (flip_worker) from [] (process_one_work+0x1a8/0x2fc)
	 r9:00000000 r8:ee807d00 r7:00000000 r6:ee809c00 r5:eeb443a8 r4:edfe5f80
	[] (process_one_work) from [] (worker_thread+0x2ac/0x458)
	 r10:00000088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 r5:ee809c00
	 r4:edfe5f80
	[] (worker_thread) from [] (kthread+0xfc/0x10c)
	 r10:00000000 r9:00000000 r8:c0135640 r7:edfe5f80 r6:00000000 r5:edf0e240
	 r4:ee8a4000 r3:ed194e00
	[] (kthread) from [] (ret_from_fork+0x14/0x3c)
	 r8:00000000 r7:00000000 r6:00000000 r5:c0139fc0 r4:edf0e240
	---[ end trace 0000000000000002 ]---

It seems that this is caused by unfortunate timing between
vop_crtc_atomic_flush() and vop_handle_vblank() given the following
ordering:

	atomic_flush		handle_vblank
	------------		-------------

	drm_flip_work_queue
	set_bit
	     			if (test_and_clear_bit(...))
	     				drm_flip_work_commit
	drm_vblank_get

This results in vop_fb_unref_worker (called as flip work) decrementing
the vblank refcount before it has been incremented.

Signed-off-by: John Keeping 
Reviewed-by: Sandy huang 
Signed-off-by: Sandy Huang 
Link: https://patchwork.freedesktop.org/patch/msgid/20180328160351.23763-1-john@metanate.com