linux-stable.git/drivers/gpu/drm/rockchip, branch linux-5.15.y Linux kernel stable tree drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed 2025-08-28T14:24:07+00:00 Andy Yan andy.yan@rock-chips.com 2025-05-09T03:15:59+00:00 d699e4e6d33b847875cd117fba65a4c1ad5e2d79 [ Upstream commit 099593a28138b48feea5be8ce700e5bc4565e31d ] In the function drm_gem_fb_init_with_funcs, the framebuffer (fb) and its corresponding object ID have already been registered. So we need to cleanup the drm framebuffer if the subsequent execution of drm_gem_fb_afbc_init fails. Directly call drm_framebuffer_put to ensure that all fb related resources are cleanup. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250509031607.2542187-1-andyshrk@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 099593a28138b48feea5be8ce700e5bc4565e31d ]

In the function drm_gem_fb_init_with_funcs, the framebuffer (fb)
and its corresponding object ID have already been registered.

So we need to cleanup the drm framebuffer if the subsequent
execution of drm_gem_fb_afbc_init fails.

Directly call drm_framebuffer_put to ensure that all fb related
resources are cleanup.

Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250509031607.2542187-1-andyshrk@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event() 2025-03-13T11:50:49+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-11-05T13:38:16+00:00 8c4b9b0c3950e99e7785eaac54485612c3e3ddac [ Upstream commit 666e1960464140cc4bc9203c203097e70b54c95a ] The code for detecting and updating the connector status in cdn_dp_pd_event_work() has a number of problems. - It does not aquire the locks to call the detect helper and update the connector status. These are struct drm_mode_config.connection_mutex and struct drm_mode_config.mutex. - It does not use drm_helper_probe_detect(), which helps with the details of locking and detection. - It uses the connector's status field to determine a change to the connector status. The epoch_counter field is the correct one. The field signals a change even if the connector status' value did not change. Replace the code with a call to drm_connector_helper_hpd_irq_event(), which fixes all these problems. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event") Cc: Chris Zhong <zyw@rock-chips.com> Cc: Guenter Roeck <groeck@chromium.org> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmermann@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 666e1960464140cc4bc9203c203097e70b54c95a ]

The code for detecting and updating the connector status in
cdn_dp_pd_event_work() has a number of problems.

- It does not aquire the locks to call the detect helper and update
the connector status. These are struct drm_mode_config.connection_mutex
and struct drm_mode_config.mutex.

- It does not use drm_helper_probe_detect(), which helps with the
details of locking and detection.

- It uses the connector's status field to determine a change to
the connector status. The epoch_counter field is the correct one. The
field signals a change even if the connector status' value did not
change.

Replace the code with a call to drm_connector_helper_hpd_irq_event(),
which fixes all these problems.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event")
Cc: Chris Zhong <zyw@rock-chips.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Sandy Huang <hjc@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241105133848.480407-1-tzimmermann@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: vop: Fix a dereferenced before check warning 2024-12-14T18:50:34+00:00 Andy Yan andy.yan@rock-chips.com 2024-10-21T07:28:06+00:00 4e47b99a7764b23a431bff6a3f91dfe77d294765 [ Upstream commit ab1c793f457f740ab7108cc0b1340a402dbf484d ] The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077) Fixes: 5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check and update") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241021072818.61621-1-andyshrk@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ab1c793f457f740ab7108cc0b1340a402dbf484d ]

The 'state' can't be NULL, we should check crtc_state.

Fix warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096
vop_plane_atomic_async_check() warn: variable dereferenced before check
'state' (see line 1077)

Fixes: 5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check and update")
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241021072818.61621-1-andyshrk@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: vop: clear DMA stop bit on RK3066 2024-10-17T13:11:46+00:00 Val Packett val@packett.cool 2024-06-24T20:40:48+00:00 e1b0752da800962a56bb7c25e9db77f28d2a02c1 [ Upstream commit 6b44aa559d6c7f4ea591ef9d2352a7250138d62a ] The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame and needs the driver to acknowledge that by clearing the bit. Unless we clear it "between" frames, the RGB output only shows noise instead of the picture. atomic_flush is the place for it that least affects other code (doing it on vblank would require converting all other usages of the reg_lock to spin_(un)lock_irq, which would affect performance for everyone). This seems to be a redundant synchronization mechanism that was removed in later iterations of the VOP hardware block. Fixes: f4a6de855eae ("drm: rockchip: vop: add rk3066 vop definitions") Cc: stable@vger.kernel.org Signed-off-by: Val Packett <val@packett.cool> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240624204054.5524-2-val@packett.cool Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6b44aa559d6c7f4ea591ef9d2352a7250138d62a ]

The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
and needs the driver to acknowledge that by clearing the bit.

Unless we clear it "between" frames, the RGB output only shows noise
instead of the picture. atomic_flush is the place for it that least
affects other code (doing it on vblank would require converting all
other usages of the reg_lock to spin_(un)lock_irq, which would affect
performance for everyone).

This seems to be a redundant synchronization mechanism that was removed
in later iterations of the VOP hardware block.

Fixes: f4a6de855eae ("drm: rockchip: vop: add rk3066 vop definitions")
Cc: stable@vger.kernel.org
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240624204054.5524-2-val@packett.cool
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: support gamma control on RK3399 2024-10-17T13:11:45+00:00 Hugh Cole-Baker sigmaris@gmail.com 2021-10-19T21:58:42+00:00 5e889e72de5833c88e0d4b5289f6c3b0ea9c07a0 [ Upstream commit 7ae7a6211fe7251543796d5af971acb8c9e2da9e ] The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its "big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP. Compared to the RK3288, it no longer requires disabling gamma while updating the LUT. On the RK3399, the LUT can be updated at any time as the hardware has two LUT buffers, one can be written while the other is in use. A swap of the buffers is triggered by writing 1 to the update_gamma_lut register. Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Tested-by: "Milan P. Stanić" <mps@arvanta.net> Tested-by: Linus Heckemann <git@sphalerite.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211019215843.42718-3-sigmaris@gmail.com Stable-dep-of: 6b44aa559d6c ("drm/rockchip: vop: clear DMA stop bit on RK3066") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7ae7a6211fe7251543796d5af971acb8c9e2da9e ]

The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its
"big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP.
Compared to the RK3288, it no longer requires disabling gamma while
updating the LUT. On the RK3399, the LUT can be updated at any time as
the hardware has two LUT buffers, one can be written while the other is
in use. A swap of the buffers is triggered by writing 1 to the
update_gamma_lut register.

Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
Tested-by: "Milan P. Stanić" <mps@arvanta.net>
Tested-by: Linus Heckemann <git@sphalerite.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019215843.42718-3-sigmaris@gmail.com
Stable-dep-of: 6b44aa559d6c ("drm/rockchip: vop: clear DMA stop bit on RK3066")
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: define gamma registers for RK3399 2024-10-17T13:11:45+00:00 Hugh Cole-Baker sigmaris@gmail.com 2021-10-19T21:58:41+00:00 a8ade6a33ba98172dc3fc4f50f8278a98b334f06 [ Upstream commit 3ba000d6ae999b99f29afd64814877a5c4406786 ] The VOP on RK3399 has a different approach from previous versions for setting a gamma lookup table, using an update_gamma_lut register. As this differs from RK3288, give RK3399 its own set of "common" register definitions. Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com> Tested-by: "Milan P. Stanić" <mps@arvanta.net> Tested-by: Linus Heckemann <git@sphalerite.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211019215843.42718-2-sigmaris@gmail.com Stable-dep-of: 6b44aa559d6c ("drm/rockchip: vop: clear DMA stop bit on RK3066") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3ba000d6ae999b99f29afd64814877a5c4406786 ]

The VOP on RK3399 has a different approach from previous versions for
setting a gamma lookup table, using an update_gamma_lut register. As
this differs from RK3288, give RK3399 its own set of "common" register
definitions.

Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
Tested-by: "Milan P. Stanić" <mps@arvanta.net>
Tested-by: Linus Heckemann <git@sphalerite.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019215843.42718-2-sigmaris@gmail.com
Stable-dep-of: 6b44aa559d6c ("drm/rockchip: vop: clear DMA stop bit on RK3066")
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode 2024-10-17T13:10:52+00:00 Jonas Karlman jonas@kwiboo.se 2024-06-15T17:03:55+00:00 4d871e3e8dfea0bdc8dca8780168b304ff5c756f [ Upstream commit a5d024541ec466f428e6c514577d511a40779c7b ] EDID cannot be read on RK3328 until after read_hpd has been called and correct io voltage has been configured based on connection status. When a forced mode is used, e.g. video=1920x1080@60e, the connector detect ops, that in turn normally calls the read_hpd, never gets called. This result in reading EDID to fail in connector get_modes ops. Call dw_hdmi_rk3328_read_hpd at end of dw_hdmi_rk3328_setup_hpd to correct io voltage and allow reading EDID after setup_hpd. Fixes: 1c53ba8f22a1 ("drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-5-jonas@kwiboo.se Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a5d024541ec466f428e6c514577d511a40779c7b ]

EDID cannot be read on RK3328 until after read_hpd has been called and
correct io voltage has been configured based on connection status.

When a forced mode is used, e.g. video=1920x1080@60e, the connector
detect ops, that in turn normally calls the read_hpd, never gets called.

This result in reading EDID to fail in connector get_modes ops.

Call dw_hdmi_rk3328_read_hpd at end of dw_hdmi_rk3328_setup_hpd to
correct io voltage and allow reading EDID after setup_hpd.

Fixes: 1c53ba8f22a1 ("drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-5-jonas@kwiboo.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: vop: Allow 4096px width scaling 2024-10-17T13:10:52+00:00 Alex Bee knaerzche@gmail.com 2024-06-15T17:03:54+00:00 b4cb296e6b89fc159a7b74c27d26ba5618d9c25b [ Upstream commit 0ef968d91a20b5da581839f093f98f7a03a804f7 ] There is no reason to limit VOP scaling to 3840px width, the limit of RK3288, when there are newer VOP versions that support 4096px width. Change to enforce a maximum of 4096px width plane scaling, the maximum supported output width of the VOP versions supported by this driver. Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale") Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-4-jonas@kwiboo.se Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0ef968d91a20b5da581839f093f98f7a03a804f7 ]

There is no reason to limit VOP scaling to 3840px width, the limit of
RK3288, when there are newer VOP versions that support 4096px width.

Change to enforce a maximum of 4096px width plane scaling, the maximum
supported output width of the VOP versions supported by this driver.

Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-4-jonas@kwiboo.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: lvds: do not print scary message when probing defer 2024-03-26T22:21:25+00:00 Quentin Schulz quentin.schulz@theobroma-systems.com 2023-11-20T12:29:49+00:00 1bb5fea94e62b2fd9aa077857479f66960177e14 [ Upstream commit 52d11c863ac92e36a0365249f7f6d27ac48c78bc ] This scary message can misled the user into thinking something bad has happened and needs to be fixed, however it could simply be part of a normal boot process where EPROBE_DEFER is taken into account. Therefore, let's use dev_err_probe so that this message doesn't get shown (by default) when the return code is EPROBE_DEFER. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: Quentin Schulz <foss+kernel@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-2-9c59a5779cf9@theobroma-systems.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 52d11c863ac92e36a0365249f7f6d27ac48c78bc ]

This scary message can misled the user into thinking something bad has
happened and needs to be fixed, however it could simply be part of a
normal boot process where EPROBE_DEFER is taken into account. Therefore,
let's use dev_err_probe so that this message doesn't get shown (by
default) when the return code is EPROBE_DEFER.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-2-9c59a5779cf9@theobroma-systems.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/rockchip: lvds: do not overwrite error code 2024-03-26T22:21:25+00:00 Quentin Schulz quentin.schulz@theobroma-systems.com 2023-11-20T12:29:48+00:00 f3afb5361819079025c1d55b975c922c94e6b554 [ Upstream commit 79b09453c4e369ca81cfb670d0136d089e3b92f0 ] ret variable stores the return value of drm_of_find_panel_or_bridge which can return error codes different from EPROBE_DEFER. Therefore, let's just return that error code instead of forcing it to EPROBE_DEFER. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: Quentin Schulz <foss+kernel@0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-1-9c59a5779cf9@theobroma-systems.com Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 79b09453c4e369ca81cfb670d0136d089e3b92f0 ]

ret variable stores the return value of drm_of_find_panel_or_bridge
which can return error codes different from EPROBE_DEFER. Therefore,
let's just return that error code instead of forcing it to EPROBE_DEFER.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-msg-v2-1-9c59a5779cf9@theobroma-systems.com
Signed-off-by: Sasha Levin <sashal@kernel.org>