linux-stable.git/drivers/gpu/drm, branch v5.4.259

drm: panel-orientation-quirks: Add quirk for One Mix 2S

2023-10-25T09:53:23+00:00

[ Upstream commit cbb7eb2dbd9472816e42a1b0fdb51af49abbf812 ]

The One Mix 2S is a mini laptop with a 1200x1920 portrait screen
mounted in a landscape oriented clamshell case. Because of the too
generic DMI strings this entry is also doing bios-date matching.

Signed-off-by: Kai Uwe Broulik 
Reviewed-by: Hans de Goede 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20231001114710.336172-1-foss-linux@broulik.de
Signed-off-by: Sasha Levin

drm/vmwgfx: fix typo of sizeof argument

2023-10-25T09:53:18+00:00

[ Upstream commit 39465cac283702a7d4a507a558db81898029c6d3 ]

Since size of 'header' pointer and '*header' structure is equal on 64-bit
machines issue probably didn't cause any wrong behavior. But anyway,
fixing typo is required.

Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.")
Co-developed-by: Ivanov Mikhail 
Signed-off-by: Konstantin Meskhidze 
Reviewed-by: Zack Rusin 
Signed-off-by: Zack Rusin 
Link: https://patchwork.freedesktop.org/patch/msgid/20230905100203.1716731-1-konstantin.meskhidze@huawei.com
Signed-off-by: Sasha Levin

drm/msm/dsi: skip the wait for video mode done if not applicable

2023-10-25T09:53:18+00:00

[ Upstream commit ab483e3adcc178254eb1ce0fbdfbea65f86f1006 ]

dsi_wait4video_done() API waits for the DSI video mode engine to
become idle so that we can transmit the DCS commands in the
beginning of BLLP. However, with the current sequence, the MDP
timing engine is turned on after the panel's pre_enable() callback
which can send out the DCS commands needed to power up the panel.

During those cases, this API will always timeout and print out the
error spam leading to long bootup times and log flooding.

Fix this by checking if the DSI video engine was actually busy before
waiting for it to become idle otherwise this is a redundant wait.

changes in v2:
	- move the reg read below the video mode check
	- minor fixes in commit text

Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/34
Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Signed-off-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/557853/
Link: https://lore.kernel.org/r/20230915204426.19011-1-quic_abhinavk@quicinc.com
Signed-off-by: Sasha Levin

drm: etvnaviv: fix bad backport leading to warning

2023-10-25T09:53:18+00:00

When updating from 5.4.219 -> 5.4.256 I started getting a runtime warning:

[   58.229857] ------------[ cut here ]------------
[   58.234599] WARNING: CPU: 1 PID: 565 at drivers/gpu/drm/drm_gem.c:1020 drm_gem_object_put+0x90/0x98
[   58.249935] Modules linked in: qmi_wwan cdc_wdm option usb_wwan smsc95xx rsi_usb rsi_91x btrsi ci_hdrc_imx ci_hdrc
[   58.260499] ueventd: modprobe usb:v2F8Fp7FFFd0200dc00dsc00dp00icFEisc01ip02in00 done
[   58.288877] CPU: 1 PID: 565 Comm: android.display Not tainted 5.4.256pkn-5.4-bsp-snapshot-svn-7423 #2195
[   58.288883] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   58.288888] Backtrace:
[   58.288912] [] (dump_backtrace) from [] (show_stack+0x20/0x24)
[   58.288920]  r7:00000000 r6:60010013 r5:00000000 r4:c14cd224
[   58.328337] [] (show_stack) from [] (dump_stack+0xe8/0x120)
[   58.335661] [] (dump_stack) from [] (__warn+0xd4/0xe8)
[   58.342542]  r10:eda54000 r9:c06ca53c r8:000003fc r7:00000009 r6:c111ed54 r5:00000000
[   58.350374]  r4:00000000 r3:76cf564a
[   58.353957] [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xc0)
[   58.361445]  r9:00000009 r8:c06ca53c r7:000003fc r6:c111ed54 r5:c1406048 r4:00000000
[   58.369198] [] (warn_slowpath_fmt) from [] (drm_gem_object_put+0x90/0x98)
[   58.377728]  r9:edda7e40 r8:edd39360 r7:ad16e000 r6:edda7eb0 r5:00000000 r4:edaa3200
[   58.385524] [] (drm_gem_object_put) from [] (etnaviv_gem_prime_mmap_obj+0x34/0x3c [etnaviv])
[   58.395704]  r5:00000000 r4:edaa3200
[   58.399334] [] (etnaviv_gem_prime_mmap_obj [etnaviv]) from [] (etnaviv_gem_mmap+0x3c/0x60 [etnaviv])
[   58.410205]  r5:edd39360 r4:00000000
[   58.413816] [] (etnaviv_gem_mmap [etnaviv]) from [] (mmap_region+0x37c/0x67c)
[   58.422689]  r5:ad16d000 r4:edda7eb8
[   58.426272] [] (mmap_region) from [] (do_mmap+0x420/0x544)
[   58.433500]  r10:000000fb r9:000fffff r8:ffffffff r7:00000001 r6:00000003 r5:00000001
[   58.441330]  r4:00001000
[   58.443876] [] (do_mmap) from [] (vm_mmap_pgoff+0xd0/0x100)
[   58.451190]  r10:eda54040 r9:00001000 r8:00000000 r7:00000000 r6:00000003 r5:c1406048
[   58.459020]  r4:edb8ff24
[   58.461561] [] (vm_mmap_pgoff) from [] (ksys_mmap_pgoff+0xdc/0x10c)
[   58.469570]  r10:000000c0 r9:edb8e000 r8:ed650b40 r7:00000003 r6:00001000 r5:00000000
[   58.477400]  r4:00000001
[   58.479941] [] (ksys_mmap_pgoff) from [] (sys_mmap_pgoff+0x2c/0x34)
[   58.487949]  r8:c0101224 r7:000000c0 r6:951ece38 r5:00010001 r4:00000065
[   58.494658] [] (sys_mmap_pgoff) from [] (ret_fast_syscall+0x0/0x28)

It looks like this was a backporting error for the upstream patch
963b2e8c428f "drm/etnaviv: fix reference leak when mmaping imported buffer"

In the 5.4 kernel there are 2 variants of the object put function:
	drm_gem_object_put() [which requires lock to be held]
	drm_gem_object_put_unlocked() [which requires lock to be NOT held]

In later kernels [5.14+] this has gone and there just drm_gem_object_put()
which requires lock to be NOT held.

So the memory leak pach, which added a call to drm_gem_object_put() was correct
on newer kernels but wrong on 5.4 and earlier ones.

So switch back to using the _unlocked variant for old kernels.
This should only be applied to the 5.4, 4.19 and 4.14 longterm branches;
mainline and more recent longterms already have the correct fix.

Signed-off-by: Martin Fuzzey 
Fixes: 0c6df5364798 "drm/etnaviv: fix reference leak when mmaping imported buffer" [5.4.y]
Fixes: 0838cb217a52 "drm/etnaviv: fix reference leak when mmaping imported buffer" [4.19.y]
Fixes: 1c9544fbc979 "drm/etnaviv: fix reference leak when mmaping imported buffer" [4.14.y]
Reviewed-by: Lucas Stach 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: prevent potential division by zero errors

2023-10-10T19:46:38+00:00

[ Upstream commit 07e388aab042774f284a2ad75a70a194517cdad4 ]

There are two places in apply_below_the_range() where it's possible for
a divide by zero error to occur. So, to fix this make sure the divisor
is non-zero before attempting the computation in both cases.

Cc: stable@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637
Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math")
Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization")
Reviewed-by: Aurabindo Pillai 
Signed-off-by: Hamza Mahfooz 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Fix LFC multiplier changing erratically

2023-10-10T19:46:38+00:00

[ Upstream commit 575da8db31572d1d8de572d0b6ffb113624c2f8f ]

[Why]
1. There is a calculation that is using frame_time_in_us instead of
last_render_time_in_us to calculate whether choosing an LFC multiplier
would cause the inserted frame duration to be outside of range.

2. We do not handle unsigned integer subtraction correctly and it underflows
to a really large value, which causes some logic errors.

[How]
1. Fix logic to calculate 'within range' using last_render_time_in_us
2. Split out delta_from_mid_point_delta_in_us calculation to ensure
we don't underflow and wrap around

Signed-off-by: Anthony Koo 
Reviewed-by: Aric Cyr 
Acked-by: Qingqing Zhuo 
Signed-off-by: Alex Deucher 
Stable-dep-of: 07e388aab042 ("drm/amd/display: prevent potential division by zero errors")
Signed-off-by: Sasha Levin

drm/amd/display: Reinstate LFC optimization

2023-10-10T19:46:38+00:00

[ Upstream commit ded6119e825aaf0bfc7f2a578b549d610da852a7 ]

[why]
We want to streamline the calculations made when entering LFC.
Previously, the optimizations led to screen tearing and were backed out
to unblock development.

[how]
Integrate other calculations parameters, as well as screen tearing,
fixes with the original LFC calculation optimizations.

Signed-off-by: Amanda Liu 
Reviewed-by: Aric Cyr 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Stable-dep-of: 07e388aab042 ("drm/amd/display: prevent potential division by zero errors")
Signed-off-by: Sasha Levin

drm/amdgpu: fix amdgpu_cs_p1_user_fence

2023-09-23T09:00:07+00:00

commit 35588314e963938dfdcdb792c9170108399377d6 upstream.

The offset is just 32bits here so this can potentially overflow if
somebody specifies a large value. Instead reduce the size to calculate
the last possible offset.

The error handling path incorrectly drops the reference to the user
fence BO resulting in potential reference count underflow.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()

2023-09-23T09:00:04+00:00

[ Upstream commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c ]

The variable crtc->state->event is often protected by the lock
crtc->dev->event_lock when is accessed. However, it is accessed as a
condition of an if statement in exynos_drm_crtc_atomic_disable() without
holding the lock:

  if (crtc->state->event && !crtc->state->active)

However, if crtc->state->event is changed to NULL by another thread right
after the conditions of the if statement is checked to be true, a
null-pointer dereference can occur in drm_crtc_send_vblank_event():

  e->pipe = pipe;

To fix this possible null-pointer dereference caused by data race, the
spin lock coverage is extended to protect the if statement as well as the
function call to drm_crtc_send_vblank_event().

Reported-by: BassCheck 
Link: https://sites.google.com/view/basscheck/home
Signed-off-by: Tuo Li 
Reviewed-by: Krzysztof Kozlowski 
Added relevant link.
Signed-off-by: Inki Dae 
Signed-off-by: Sasha Levin

drm/amd/display: Fix a bug when searching for insert_above_mpcc

2023-09-23T09:00:02+00:00

commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream.

[WHY]
Currently, when insert_plane is called with insert_above_mpcc
parameter that is equal to tree->opp_list, the function returns NULL.

[HOW]
Instead, the function should insert the plane at the top of the tree.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: stable@vger.kernel.org
Reviewed-by: Jun Lei 
Acked-by: Tom Chung 
Signed-off-by: Wesley Chalmers 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman