linux-stable.git/drivers/gpu, branch v6.6.53

drm: Expand max DRM device number to full MINORBITS

2024-09-30T14:25:13+00:00

[ Upstream commit 071d583e01c88272f6ff216d4f867f8f35e94d7d ]

Having a limit of 64 DRM devices is not good enough for modern world
where we have multi-GPU servers, SR-IOV virtual functions and virtual
devices used for testing.
Let's utilize full minor range for DRM devices.
To avoid regressing the existing userspace, we're still maintaining the
numbering scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.

Signed-off-by: Michał Winiarski 
Link: https://patchwork.freedesktop.org/patch/msgid/20240823163048.2676257-4-michal.winiarski@intel.com
Acked-by: James Zhu 
Acked-by: Christian König 
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

accel: Use XArray instead of IDR for minors

2024-09-30T14:25:13+00:00

[ Upstream commit 45c4d994b82b08f0ce5eb50f8da29379c92a391e ]

Accel minor management is based on DRM (and is also using struct
drm_minor internally), since DRM is using XArray for minors, it makes
sense to also convert accel.
As the two implementations are identical (only difference being the
underlying xarray), move the accel_minor_* functionality to DRM.

Signed-off-by: Michał Winiarski 
Acked-by: James Zhu 
Acked-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20240823163048.2676257-3-michal.winiarski@intel.com
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

drm: Use XArray instead of IDR for minors

2024-09-30T14:25:12+00:00

[ Upstream commit 5fbca8b48b3050ae7fb611a8b09af60012ed6de1 ]

IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.

Suggested-by: Matthew Wilcox 
Signed-off-by: Michał Winiarski 
Acked-by: James Zhu 
Acked-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20240823163048.2676257-2-michal.winiarski@intel.com
Signed-off-by: Christian König 
Signed-off-by: Sasha Levin

drm: komeda: Fix an issue related to normalized zpos

2024-09-30T14:25:11+00:00

[ Upstream commit 258905cb9a6414be5c9ca4aa20ef855f8dc894d4 ]

We use komeda_crtc_normalize_zpos to normalize zpos of affected planes
to their blending zorder in CU. If there's only one slave plane in
affected planes and its layer_split property is enabled, order++ for
its split layer, so that when calculating the normalized_zpos
of master planes, the split layer of the slave plane is included, but
the max_slave_zorder does not include the split layer and keep zero
because there's only one slave plane in affacted planes, although we
actually use two slave layers in this commit.

In most cases, this bug does not result in a commit failure, but assume
the following situation:
    slave_layer 0: zpos = 0, layer split enabled, normalized_zpos =
    0;(use slave_layer 2 as its split layer)
    master_layer 0: zpos = 2, layer_split enabled, normalized_zpos =
    2;(use master_layer 2 as its split layer)
    master_layer 1: zpos = 4, normalized_zpos = 4;
    master_layer 3: zpos = 5, normalized_zpos = 5;
    kcrtc_st->max_slave_zorder = 0;
When we use master_layer 3 as a input of CU in function
komeda_compiz_set_input and check it with function
komeda_component_check_input, the parameter idx is equal to
normailzed_zpos minus max_slave_zorder, the value of idx is 5
and is euqal to CU's max_active_inputs, so that
komeda_component_check_input returns a -EINVAL value.

To fix the bug described above, when calculating the max_slave_zorder
with the layer_split enabled, count the split layer in this calculation
directly.

Signed-off-by: hongchi.peng 
Acked-by: Liviu Dudau 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20240826024517.3739-1-hongchi.peng@siengine.com
Signed-off-by: Sasha Levin

drm/i915/guc: prevent a possible int overflow in wq offsets

2024-09-18T17:24:10+00:00

[ Upstream commit d3d37f74683e2f16f2635ee265884f7ca69350ae ]

It may be possible for the sum of the values derived from
i915_ggtt_offset() and __get_parent_scratch_offset()/
i915_ggtt_offset() to go over the u32 limit before being assigned
to wq offsets of u64 type.

Mitigate these issues by expanding one of the right operands
to u64 to avoid any overflow issues just in case.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: c2aa552ff09d ("drm/i915/guc: Add multi-lrc context registration")
Cc: Matthew Brost 
Cc: John Harrison 
Signed-off-by: Nikita Zhandarovich 
Link: https://patchwork.freedesktop.org/patch/msgid/20240725155925.14707-1-n.zhandarovich@fintech.ru
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 
(cherry picked from commit 1f1c1bd56620b80ae407c5790743e17caad69cec)
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Sasha Levin

drm/amd/amdgpu: apply command submission parser for JPEG v1

2024-09-18T17:24:10+00:00

commit 8409fb50ce48d66cf9dc5391f03f05c56c430605 upstream.

Similar to jpeg_v2_dec_ring_parse_cs() but it has different
register ranges and a few other registers access.

Acked-by: Alex Deucher 
Signed-off-by: David (Ming Qiang) Wu 
Signed-off-by: Alex Deucher 
(cherry picked from commit 3d5adbdf1d01708777f2eda375227cbf7a98b9fe)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/atomfirmware: Silence UBSAN warning

2024-09-18T17:24:10+00:00

commit 17ea4383649fdeaff3181ddcf1ff03350d42e591 upstream.

Per the comments, these are variable sized arrays.

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3613
Reviewed-by: Harry Wentland 
Signed-off-by: Alex Deucher 
(cherry picked from commit 81f7804ba84ee617ed594de934ed87bcc4f83531)
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/fb: restore init() for ramgp102

2024-09-18T17:24:10+00:00

commit 6db9df4f7055eb4ea339e7b83ca676edd9ec1277 upstream.

init() was removed from ramgp102 when reworking the memory detection, as
it was thought that the code was only necessary when the driver performs
mclk changes, which nouveau doesn't support on pascal.

However, it turns out that we still need to execute this on some GPUs to
restore settings after DEVINIT, so revert to the original behaviour.

v2: fix tags in commit message, cc stable

Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/319
Fixes: 2c0c15a22fa0 ("drm/nouveau/fb/gp102-ga100: switch to simpler vram size detection method")
Cc: stable@vger.kernel.org # 6.6+
Signed-off-by: Ben Skeggs 
Signed-off-by: Danilo Krummrich 
Link: https://patchwork.freedesktop.org/patch/msgid/20240904232418.8590-1-bskeggs@nvidia.com
Signed-off-by: Greg Kroah-Hartman

drm/syncobj: Fix syncobj leak in drm_syncobj_eventfd_ioctl

2024-09-18T17:24:09+00:00

commit 8c7c44be57672e1474bf15a451011c291e85fda4 upstream.

A syncobj reference is taken in drm_syncobj_find, but not released if
eventfd_ctx_fdget or kzalloc fails. Put the reference in these error
paths.

Reported-by: Xingyu Jin 
Fixes: c7a472297169 ("drm/syncobj: add IOCTL to register an eventfd")
Signed-off-by: T.J. Mercier 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by. Christian König 
CC: stable@vger.kernel.org # 6.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20240909205400.3498337-1-tjmercier@google.com
Signed-off-by: Christian König 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix FEC_READY write on DP LT

2024-09-18T17:24:07+00:00

[ Upstream commit a8baec4623aedf36d50767627f6eae5ebf07c6fb ]

[Why/How]
We can miss writing FEC_READY in some cases before LT start, which
violates DP spec. Remove the condition guarding the DPCD write so that
the write happens unconditionally.

Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: stable@vger.kernel.org
Reviewed-by: Wenjing Liu 
Acked-by: Wayne Lin 
Signed-off-by: Ilya Bakoulin 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin