<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v6.1.87</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.87'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-04-17T09:18:29+00:00</updated>
<entry>
<title>drm/amd/display: fix disable otg wa logic in DCN316</title>
<updated>2024-04-17T09:18:29+00:00</updated>
<author>
<name>Fudongwang</name>
<email>fudong.wang@amd.com</email>
</author>
<published>2024-03-26T08:03:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=724fbc7c0cb88729ec914a3d778f466e5ea3dbb7'/>
<id>urn:sha1:724fbc7c0cb88729ec914a3d778f466e5ea3dbb7</id>
<content type='text'>
commit cf79814cb0bf5749b9f0db53ca231aa540c02768 upstream.

[Why]
Wrong logic cause screen corruption.

[How]
Port logic from DCN35/314.

Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Kazlauskas &lt;nicholas.kazlauskas@amd.com&gt;
Acked-by: Hamza Mahfooz &lt;hamza.mahfooz@amd.com&gt;
Signed-off-by: Fudongwang &lt;fudong.wang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: always force full reset for SOC21</title>
<updated>2024-04-17T09:18:29+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2024-03-24T00:46:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=90819b1830bc26dfacedae28fce72e1f21133b38'/>
<id>urn:sha1:90819b1830bc26dfacedae28fce72e1f21133b38</id>
<content type='text'>
commit 65ff8092e4802f96d87d3d7cde146961f5228265 upstream.

There are cases where soft reset seems to succeed, but
does not, so always use mode1/2 for now.

Reviewed-by: Harish Kasiviswanathan &lt;Harish.Kasiviswanathan@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Reset dGPU if suspend got aborted</title>
<updated>2024-04-17T09:18:29+00:00</updated>
<author>
<name>Lijo Lazar</name>
<email>lijo.lazar@amd.com</email>
</author>
<published>2024-02-14T12:25:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cc89dbcb8eabd01ae264dc76a5939ea96c63c90'/>
<id>urn:sha1:7cc89dbcb8eabd01ae264dc76a5939ea96c63c90</id>
<content type='text'>
commit 8b2be55f4d6c1099d7f629b0ed7535a5be788c83 upstream.

For SOC21 ASICs, there is an issue in re-enabling PM features if a
suspend got aborted. In such cases, reset the device during resume
phase. This is a workaround till a proper solution is finalized.

Signed-off-by: Lijo Lazar &lt;lijo.lazar@amd.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Reviewed-by: Yang Wang &lt;kevinyang.wang@amd.com&gt;
Reviewed-by: Hawking Zhang &lt;Hawking.Zhang@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: Disable port sync when bigjoiner is used</title>
<updated>2024-04-17T09:18:29+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2024-04-04T21:34:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29bd4d05f2c5b9e84935874d1c0c2c97a8d91a12'/>
<id>urn:sha1:29bd4d05f2c5b9e84935874d1c0c2c97a8d91a12</id>
<content type='text'>
commit 0653d501409eeb9f1deb7e4c12e4d0d2c9f1cba1 upstream.

The current modeset sequence can't handle port sync and bigjoiner
at the same time. Refuse port sync when bigjoiner is needed,
at least until we fix the modeset sequence.

v2: Add a FIXME (Vandite)

Cc: stable@vger.kernel.org
Tested-by: Vidya Srinivas &lt;vidya.srinivas@intel.com&gt;
Reviewed-by: Vandita Kulkarni &lt;vandita.kulkarni@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-4-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
(cherry picked from commit b37e1347b991459c38c56ec2476087854a4f720b)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/cdclk: Fix CDCLK programming order when pipes are active</title>
<updated>2024-04-17T09:18:29+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2024-04-02T15:50:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2bc1796f8eeba648c06d68ece1ea86974363f6d0'/>
<id>urn:sha1:2bc1796f8eeba648c06d68ece1ea86974363f6d0</id>
<content type='text'>
commit 7b1f6b5aaec0f849e19c3e99d4eea75876853cdd upstream.

Currently we always reprogram CDCLK from the
intel_set_cdclk_pre_plane_update() when using squash/crawl.
The code only works correctly for the cd2x update or full
modeset cases, and it was simply never updated to deal with
squash/crawl.

If the CDCLK frequency is increasing we must reprogram it
before we do anything else that might depend on the new
higher frequency, and conversely we must not decrease
the frequency until everything that might still depend
on the old higher frequency has been dealt with.

Since cdclk_state-&gt;pipe is only relevant when doing a cd2x
update we can't use it to determine the correct sequence
during squash/crawl. To that end introduce cdclk_state-&gt;disable_pipes
which simply indicates that we must perform the update
while the pipes are disable (ie. during
intel_set_cdclk_pre_plane_update()). Otherwise we use the
same old vs. new CDCLK frequency comparsiong as for cd2x
updates.

The only remaining problem case is when the voltage_level
needs to increase due to a DDI port, but the CDCLK frequency
is decreasing (and not all pipes are being disabled). The
current approach will not bump the voltage level up until
after the port has already been enabled, which is too late.
But we'll take care of that case separately.

v2: Don't break the "must disable pipes case"
v3: Keep the on stack 'pipe' for future use

Cc: stable@vger.kernel.org
Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL")
Reviewed-by: Uma Shankar &lt;uma.shankar@intel.com&gt;
Reviewed-by: Gustavo Sousa &lt;gustavo.sousa@intel.com&gt;
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-2-ville.syrjala@linux.intel.com
(cherry picked from commit 3aecee90ac12a351905f12dda7643d5b0676d6ca)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/client: Fully protect modes[] with dev-&gt;mode_config.mutex</title>
<updated>2024-04-17T09:18:27+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2024-04-04T20:33:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=18c8cc6680ce938d0458859b6a08b4d34f7d8055'/>
<id>urn:sha1:18c8cc6680ce938d0458859b6a08b4d34f7d8055</id>
<content type='text'>
commit 3eadd887dbac1df8f25f701e5d404d1b90fd0fea upstream.

The modes[] array contains pointers to modes on the connectors'
mode lists, which are protected by dev-&gt;mode_config.mutex.
Thus we need to extend modes[] the same protection or by the
time we use it the elements may already be pointing to
freed/reused memory.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240404203336.10454-2-ville.syrjala@linux.intel.com
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/ast: Fix soft lockup</title>
<updated>2024-04-17T09:18:27+00:00</updated>
<author>
<name>Jammy Huang</name>
<email>jammy_huang@aspeedtech.com</email>
</author>
<published>2024-04-03T09:02:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a6fea3fcb577a543ef67683ca7105bde49a38fb'/>
<id>urn:sha1:8a6fea3fcb577a543ef67683ca7105bde49a38fb</id>
<content type='text'>
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.

There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.

These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.

DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.

Signed-off-by: Jammy Huang &lt;jammy_huang@aspeedtech.com&gt;
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory Display-Port")
Reviewed-by: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Reviewed-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: KuoHsiang Chou &lt;kuohsiang_chou@aspeedtech.com&gt;
Cc: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Jocelyn Falempe &lt;jfalempe@redhat.com&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: &lt;stable@vger.kernel.org&gt; # v5.19+
Link: https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_huang@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amdkfd: Reset GPU on queue preemption failure</title>
<updated>2024-04-17T09:18:27+00:00</updated>
<author>
<name>Harish Kasiviswanathan</name>
<email>Harish.Kasiviswanathan@amd.com</email>
</author>
<published>2024-03-26T19:32:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d29b50a32c274ae660d5e55eda747220a34217ef'/>
<id>urn:sha1:d29b50a32c274ae660d5e55eda747220a34217ef</id>
<content type='text'>
commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.

Currently, with F32 HWS GPU reset is only when unmap queue fails.

However, if compute queue doesn't repond to preemption request in time
unmap will return without any error. In this case, only preemption error
is logged and Reset is not triggered. Call GPU reset in this case also.

Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Harish Kasiviswanathan &lt;Harish.Kasiviswanathan@amd.com&gt;
Reviewed-by: Mukul Joshi &lt;mukul.joshi@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/vrr: Disable VRR when using bigjoiner</title>
<updated>2024-04-17T09:18:27+00:00</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2024-04-04T21:34:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b53d7d620c45c60501fb81c00fd2eb07aeb142f'/>
<id>urn:sha1:4b53d7d620c45c60501fb81c00fd2eb07aeb142f</id>
<content type='text'>
commit dcd8992e47f13afb5c11a61e8d9c141c35e23751 upstream.

All joined pipes share the same transcoder/timing generator.
Currently we just do the commits per-pipe, which doesn't really
work if we need to change switch between non-VRR and VRR timings
generators on the fly, or even when sending the push to the
transcoder. For now just disable VRR when bigjoiner is needed.

Cc: stable@vger.kernel.org
Tested-by: Vidya Srinivas &lt;vidya.srinivas@intel.com&gt;
Reviewed-by: Vandita Kulkarni &lt;vandita.kulkarni@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-6-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
(cherry picked from commit f9d5e51db65652dbd8a2102fd7619440e3599fd2)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nouveau: fix function cast warning</title>
<updated>2024-04-17T09:18:23+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-04T16:02:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7dc2e6b8798518ee69b1bcf67f0f8374af91dd2'/>
<id>urn:sha1:b7dc2e6b8798518ee69b1bcf67f0f8374af91dd2</id>
<content type='text'>
[ Upstream commit 185fdb4697cc9684a02f2fab0530ecdd0c2f15d4 ]

Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:

drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from 'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
   73 |         .fini = (void(*)(void *))kfree,

Avoid this with a trivial wrapper.

Fixes: c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Danilo Krummrich &lt;dakr@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240404160234.2923554-1-arnd@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
