kernel/linux.git/drivers/gpu/drm/rockchip, branch v6.1.44

drm/rockchip: vop: Leave vblank enabled in self-refresh

2023-07-23T11:49:39+00:00

commit 2bdba9d4a3baa758c2ca7f5b37b35c7b3391dc42 upstream. If we disable vblank when entering self-refresh, vblank APIs (like DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when we enter self-refresh, so this appears to be an API violation -- that DRM_IOCTL_WAIT_VBLANK fails with EINVAL whenever the display is idle and enters self-refresh. The downstream driver used by many of these systems never used to disable vblank for PSR, and in fact, even upstream, we didn't do that until radically redesigning the state machine in commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"). Thus, it seems like a reasonable API fix to simply restore that behavior, and leave vblank enabled. Note that this appears to potentially unbalance the drm_crtc_vblank_{off,on}() calls in some cases, but: (a) drm_crtc_vblank_on() documents this as OK and (b) if I do the naive balancing, I find state machine issues such that we're not in sync properly; so it's easier to take advantage of (a). This issue was exposed by IGT's kms_vblank tests, and reported by KernelCI. The bug has been around a while (longer than KernelCI noticed), but was only exposed once self-refresh was bugfixed more recently, and so KernelCI could properly test it. Some other notes in: https://lore.kernel.org/dri-devel/Y6OCg9BPnJvimQLT@google.com/ Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin == Backporting notes: == Marking as 'Fixes' commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), but it probably depends on commit bed030a49f3e ("drm/rockchip: Don't fully disable vop on self refresh") as well. We also need the previous patch ("drm/atomic: Allow vblank-enabled + self-refresh "disable""), of course. v3: * no update v2: * skip unnecessary lock/unlock Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR") Cc: Reported-by: "kernelci.org bot" Link: https://lore.kernel.org/dri-devel/Y5itf0+yNIQa6fU4@sirena.org.uk/ Signed-off-by: Brian Norris Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.2.Ic07cba4ab9a7bd3618a9e4258b8f92ea7d10ae5a@changeid Signed-off-by: Greg Kroah-Hartman

drm/rockchip: dw_hdmi: cleanup drm encoder during unbind

2023-05-24T16:32:35+00:00

[ Upstream commit b5af48eedcb53491c02ded55d5991e03d6da6dbf ] This fixes a use-after-free crash during rmmod. The DRM encoder is embedded inside the larger rockchip_hdmi, which is allocated with the component. The component memory gets freed before the main drm device is destroyed. Fix it by running encoder cleanup before tearing down its container. Signed-off-by: Toby Chen [moved encoder cleanup above clk_disable, similar to bind-error-path] Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20230317005126.496-1-tobyc@nvidia.com Signed-off-by: Sasha Levin

drm/rockchip: Drop unbalanced obj unref

2023-05-11T14:03:07+00:00

[ Upstream commit 8ee3b0e85f6ccd9e6c527bc50eaba774c3bb18d0 ] In the error path, rockchip_drm_gem_object_mmap() is dropping an obj reference that it doesn't own. Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers") Signed-off-by: Rob Clark Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com Signed-off-by: Sasha Levin

drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume

2023-04-26T12:28:40+00:00

commit b63a553e8f5aa6574eeb535a551817a93c426d8c upstream. afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume") uses regmap_reinit_cache() to fix the suspend/resume issue with the VOP2 driver. During discussion it came up that we should rather use regcache_sync() instead. As the original patch is already applied fix this up in this follow-up patch. Fixes: afa965a45e01 ("drm/rockchip: vop2: fix suspend/resume") Cc: stable@vger.kernel.org Signed-off-by: Sascha Hauer Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20230417123747.2179695-1-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

drm/rockchip: vop2: fix suspend/resume

2023-04-26T12:28:40+00:00

commit afa965a45e01e541cdbe5c8018226eff117610f0 upstream. During a suspend/resume cycle the VO power domain will be disabled and the VOP2 registers will reset to their default values. After that the cached register values will be out of sync and the read/modify/write operations we do on the window registers will result in bogus values written. Fix this by re-initializing the register cache each time we enable the VOP2. With this the VOP2 will show a picture after a suspend/resume cycle whereas without this the screen stays dark. Fixes: 604be85547ce4 ("drm/rockchip: Add VOP2 driver") Cc: stable@vger.kernel.org Signed-off-by: Sascha Hauer Tested-by: Chris Morgan Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20230413144347.3506023-1-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman

drm/rockchip: Use drm_mode_copy()

2022-12-31T12:33:01+00:00

[ Upstream commit 2bfaa28000d2830d3209161a4541cce0660e1b84 ] struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Signed-off-by: Ville Syrjälä Cc: Sandy Huang Cc: "Heiko Stübner" Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-7-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter Signed-off-by: Sasha Levin

drm/rockchip: use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()

2022-12-31T12:32:59+00:00

[ Upstream commit e3558747ebe15306e6d0b75bd6d211436be4a7d5 ] Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() to avoid device usage counter leak. Signed-off-by: Yuan Can Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220615062644.96837-1-yuancan@huawei.com Signed-off-by: Sasha Levin

drm/rockchip: lvds: fix PM usage counter unbalance in poweron

2022-12-31T12:32:06+00:00

[ Upstream commit 4dba27f1a14592ac4cf71c3bc1cc1fd05dea8015 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Fixes: cca1705c3d89 ("drm/rockchip: lvds: Add PX30 support") Signed-off-by: Zhang Qilong Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220922132107.105419-3-zhangqilong3@huawei.com Signed-off-by: Sasha Levin

drm/rockchip: vop2: disable planes when disabling the crtc

2022-10-29T12:41:29+00:00

The vop2 driver needs to explicitly disable the planes if the crtc is disabled. Unless the planes are explicitly disabled, the address of the last framebuffer is kept in the registers of the VOP2. When re-enabling the encoder after it has been disabled by the driver, the VOP2 will start and read the framebuffer that has been freed but is still pointed to by the register. The iommu will catch these read accesses and print errors. Explicitly disable the planes when the crtc is disabled to reset the registers. Signed-off-by: Michael Tretter Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20221028095206.2136601-3-m.tretter@pengutronix.de

drm/rockchip: vop2: fix null pointer in plane_atomic_disable

2022-10-29T12:41:28+00:00

If the vop2_plane_atomic_disable function is called with NULL as a state, accessing the old_pstate runs into a null pointer exception. However, the drm_atomic_helper_disable_planes_on_crtc function calls the atomic_disable callback with state NULL. Allow to disable a plane without passing a plane state by checking the old_pstate only if a state is passed. Signed-off-by: Michael Tretter Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20221028095206.2136601-2-m.tretter@pengutronix.de