kernel/linux.git/drivers/gpu/drm/rockchip, branch v4.19.265

drm/rockchip: Fix return type of cdn_dp_connector_mode_valid

2022-09-28T09:02:58+00:00

[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ] The mode_valid field in drm_connector_helper_funcs is expected to be of type: enum drm_mode_status (* mode_valid) (struct drm_connector *connector, struct drm_display_mode *mode); The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition. The return type of cdn_dp_connector_mode_valid should be changed from int to enum drm_mode_status. Reported-by: Dan Carpenter Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Cc: llvm@lists.linux.dev Signed-off-by: Nathan Huckleberry Reviewed-by: Nathan Chancellor Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220913205555.155149-1-nhuck@google.com Signed-off-by: Sasha Levin

drm/rockchip: vop: Don't crash for invalid duplicate_state()

2022-08-25T09:15:05+00:00

[ Upstream commit 1449110b0dade8b638d2c17ab7c5b0ff696bfccb ] It's possible for users to try to duplicate the CRTC state even when the state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other users of __drm_atomic_helper_crtc_duplicate_state()) already guard this with a WARN_ON() instead of crashing, so let's do that here too. Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by: Brian Norris Reviewed-by: Sean Paul Reviewed-by: Douglas Anderson Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220617172623.1.I62db228170b1559ada60b8d3e1637e1688424926@changeid Signed-off-by: Sasha Levin

drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()

2022-06-14T14:59:21+00:00

[ Upstream commit f8c242908ad15bbd604d3bcb54961b7d454c43f8 ] It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver") Signed-off-by: Yang Yingliang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422032854.2995175-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin

drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write()

2021-07-20T14:15:49+00:00

[ Upstream commit ae41d925c75b53798f289c69ee8d9f7d36432f6d ] After calling clk_prepare_enable(), clk_disable_unprepare() need be called when calling regmap_write() failed. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20210519134928.2696617-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin

drm/rockchip: Suspend DP late

2019-08-29T06:28:40+00:00

[ Upstream commit f7ccbed656f78212593ca965d9a8f34bf24e0aab ] In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved resume to be early but left suspend at its normal time. This seems like it could be OK, but casues problems if a suspend gets interrupted partway through. The OS only balances matching suspend/resume levels. ...so if suspend was called then resume will be called. If suspend late was called then resume early will be called. ...but if suspend was called resume early might not get called. This leads to an unbalance in the clock enables / disables. Lets take the simple fix and just move suspend to be late to match. This makes the PM core take proper care in keeping things balanced. Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early") Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190802184616.44822-1-dianders@chromium.org Signed-off-by: Sasha Levin

drm/rockchip: Properly adjust to a true clock in adjusted_mode

2019-07-31T05:27:00+00:00

[ Upstream commit 99b9683f2142b20bad78e61f7f829e8714e45685 ] When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul Reviewed-by: Yakir Yang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org Signed-off-by: Sasha Levin

drm/rockchip: shutdown drm subsystem on shutdown

2019-06-09T07:17:23+00:00

commit b8f9d7f37b6af829c34c49d1a4f73ce6ed58e403 upstream. As explained by Robin Murphy: > the IOMMU shutdown disables paging, so if the VOP is still > scanning out then that will result in whatever IOVAs it was using now going > straight out onto the bus as physical addresses. We had a more radical approach before in commit 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") but that resulted in new warnings and oopses on shutdown on rk3399 chromeos devices. So second try is resurrecting Vicentes shutdown change which should achieve the same result but in a less drastic way. Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"") Cc: Jeffy Chen Cc: Robin Murphy Cc: Marc Zyngier Cc: Brian Norris Cc: Doug Anderson Cc: stable@vger.kernel.org Suggested-by: JeffyChen Suggested-by: Robin Murphy Signed-off-by: Vicente Bergas [adapted commit message to explain the history] Signed-off-by: Heiko Stuebner Tested-by: Brian Norris Tested-by: Douglas Anderson Acked-by: Marc Zyngier Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman

drm/rockchip: fix for mailbox read validation.

2019-05-02T07:58:52+00:00

[ Upstream commit e4056bbb6719fe713bfc4030ac78e8e97ddf7574 ] This is basically the same fix as in commit fa68d4f8476b ("drm/rockchip: fix for mailbox read size") but for cdn_dp_mailbox_validate_receive function. See patchwork.kernel.org/patch/10671981/ for details. Signed-off-by: Damian Kos Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/1542640463-18332-1-git-send-email-dkos@cadence.com Signed-off-by: Sasha Levin

drm/rockchip: vop: reset scale mode when win is disabled

2019-04-03T04:26:24+00:00

commit e9abc611a941d4051cde1d94b2ab7473fdb50102 upstream. NV12 framebuffers produced by the VPU shows distorted on RK3288 after win has been disabled when scaling is active. This issue can be reproduced using a 1080p modeset by: - Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0 - Disable win0 - Display a 1920x1080 NV12 framebuffer without scaling on win0 - Output will now show the framebuffer distorted And by: - Scale a 1280x720 NV12 framebuffer to 1920x1080 - Change to a 720p modeset (win gets disabled and scaling reset to none) - Output will now show the framebuffer distorted Fix this by setting scale mode to none when win is disabled. Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale") Cc: stable@vger.kernel.org Signed-off-by: Jonas Karlman Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/AM3PR03MB0966DE3E19BACE07328CD637AC7D0@AM3PR03MB0966.eurprd03.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

drm/rockchip: fix for mailbox read size

2019-02-12T18:47:00+00:00

[ Upstream commit fa68d4f8476bea4cdf441062b614b41bb85ef1da ] Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block) allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is used by them, can read only up to 255 bytes at once. Normally, it's not a big issue as DPCD or EDID reads won't (hopefully) exceed that value. The real issue here is the revocation list read during the HDCP authentication process. (problematic use case: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152) The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv + 4 bytes of an additional info). In other words - CTSes with HDCP Repeater won't pass without this fix. Oh, and the driver will most likely stop working (best case scenario). Signed-off-by: Damian Kos Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-dkos@cadence.com Signed-off-by: Sasha Levin