kernel/linux.git/drivers/gpu, branch v5.10.53

drm/panel: nt35510: Do not fail if DSI read fails

2021-07-25T12:36:21+00:00

commit 1988e0d84161dabd99d1c27033fbd6ee439bf432 upstream. Failing to read the MTP over DSI should not bring down the system and make us bail out from using the display, it turns out that this happens when toggling the display off and on, and that write is often still working so the display output is just fine. Printing an error is enough. Tested by killing the Gnome session repeatedly on the Samsung Skomer. Fixes: 899f24ed8d3a ("drm/panel: Add driver for Novatek NT35510-based panels") Cc: Stephan Gerhold Reported-by: newbyte@disroot.org Acked-by: Stefan Hansson Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210603231830.3200040-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: fix sysfs kobj leak

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

[ Upstream commit dcdb4d904b4bd3078fe8d4d24b1658560d6078ef ] 3 cases of kobj leak, which causes memory leak: kobj_type must have release() method to free memory from release callback. Don't need NULL default_attrs to init kobj. sysfs files created under kobj_status should be removed with kobj_status as parent kobject. Remove queue sysfs files when releasing queue from process MMU notifier release callback. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/gma500: Add the missed drm_gem_object_put() in psb_user_framebuffer_create()

2021-07-20T14:05:48+00:00

[ Upstream commit cd8f318fbd266b127ffc93cc4c1eaf9a5196fafb ] psb_user_framebuffer_create() misses to call drm_gem_object_put() in an error path. Add the missed function call to fix it. Signed-off-by: Jing Xiangfeng Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210629115956.15160-1-jingxiangfeng@huawei.com Signed-off-by: Sasha Levin

Revert "drm/ast: Remove reference to struct drm_device.pdev"

2021-07-20T14:05:37+00:00

This reverts commit fcb041ca5c7787b096aafc899e45f93583e66cbd which is commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream. Turns out this was incomplete, as it is missing a dependancy, so drop it from the tree. Link: https://lore.kernel.org/r/CAJn8CcHHKSo7GF29Z1ufXJJpMUzn6+fdvwiqe9=JvgpcfvnbHQ@mail.gmail.com Reported-by: Xiaotian Feng Cc: Thomas Zimmermann Cc: Michael J. Ruhl Cc: KuoHsiang Chou Cc: kernel test robot Cc: Thomas Zimmermann Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman

drm/ingenic: Switch IPU plane to type OVERLAY

2021-07-20T14:05:37+00:00

commit 68b433fe6937cfa3f8975d18643d5956254edd6a upstream. It should have been an OVERLAY from the beginning. The documentation stipulates that there should be an unique PRIMARY plane per CRTC. Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Cc: # 5.8+ Signed-off-by: Paul Cercueil Acked-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20210329175046.214629-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

drm/ingenic: Fix non-OSD mode

2021-07-20T14:05:37+00:00

commit 7b4957684e5d813fcbdc98144e3cc5c4467b3e2e upstream. Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode") Cc: # v5.8+ Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Tested-by: H. Nikolaus Schaller Link: https://patchwork.freedesktop.org/patch/msgid/20210124085552.29146-5-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

2021-07-20T14:05:37+00:00

commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream. Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") Cc: Wayne Lin Cc: Lyude Paul Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: José Roberto de Souza Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210616194415.36926-1-jose.souza@intel.com Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: Avoid to mess up payload table by ports in stale topology

2021-07-20T14:05:37+00:00

commit 3769e4c0af5b82c8ea21d037013cb9564dfaa51f upstream. [Why] After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi() to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology. E.g. We have allocated VCPI 1 in current payload table and we call drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id() tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available by drm_dp_mst_assign_payload_id(). However, ID 1 is being used [How] Check target sink is relating to current topology or not before doing any payload table update. Searching upward to find the target sink's relevant root branch device. If the found root branch device is not the same root of current topology, don't update payload table. Changes since v1: * Change debug macro to use drm_dbg_kms() instead * Amend the commit message to add Cc tag. Signed-off-by: Wayne Lin Cc: stable@vger.kernel.org Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-3-Wayne.Lin@amd.com Reviewed-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: Do not set proposed vcpi directly

2021-07-20T14:05:37+00:00

commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream. [Why] When we receive CSN message to notify one port is disconnected, we will implicitly set its corresponding num_slots to 0. Later on, we will eventually call drm_dp_update_payload_part1() to arrange down streams. In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[] to do the update. Not specific to a target sink only. For example, if we light up 2 monitors, Monitor_A and Monitor_B, and then we unplug Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try to update payload for Monitor_A, we'll also implicitly clean payload for Monitor_B at the same time. And finally, when we try to call drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do nothing at this time since payload for Monitor_B has been cleaned up previously. For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail and this polling will last for 3 seconds. Therefore, guess the best way is we don't set the proposed_vcpi[] diretly. Let user of these herlper functions to set the proposed_vcpi directly. [How] 1. Revert commit 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid") 2. Tackle the issue in previous commit by skipping those trasient proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by user later on. Changes since v1: * Change debug macro to use drm_dbg_kms() instead * Amend the commit message to add Fixed & Cc tags Signed-off-by: Wayne Lin Fixes: 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid") Cc: Lyude Paul Cc: Wayne Lin Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: # v5.5+ Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-2-Wayne.Lin@amd.com Reviewed-by: Lyude Paul Signed-off-by: Greg Kroah-Hartman

drm/i915/gt: Fix -EDEADLK handling regression

2021-07-20T14:05:36+00:00

commit 2feeb52859fc1ab94cd35b61ada3a6ac4ff24243 upstream. The conversion to ww mutexes failed to address the fence code which already returns -EDEADLK when we run out of fences. Ww mutexes on the other hand treat -EDEADLK as an internal errno value indicating a need to restart the operation due to a deadlock. So now when the fence code returns -EDEADLK the higher level code erroneously restarts everything instead of returning the error to userspace as is expected. To remedy this let's switch the fence code to use a different errno value for this. -ENOBUFS seems like a semi-reasonable unique choice. Apart from igt the only user of this I could find is sna, and even there all we do is dump the current fence registers from debugfs into the X server log. So no user visible functionality is affected. If we really cared about preserving this we could of course convert back to -EDEADLK higher up, but doesn't seem like that's worth the hassle here. Not quite sure which commit specifically broke this, but I'll just attribute it to the general gem ww mutex work. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst Cc: Thomas Hellström Testcase: igt/gem_pread/exhaustion Testcase: igt/gem_pwrite/basic-exhaustion Testcase: igt/gem_fenced_exec_thrash/too-many-fences Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20210630164413.25481-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst (cherry picked from commit 78d2ad7eb4e1f0e9cd5d79788446b6092c21d3e0) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman