<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v5.18.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.18.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.18.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-06-06T06:48:54+00:00</updated>
<entry>
<title>drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()</title>
<updated>2022-06-06T06:48:54+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavoars@kernel.org</email>
</author>
<published>2022-04-27T22:47:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01d3876bdbd058d8620d5fe8f02aa05fd7276351'/>
<id>urn:sha1:01d3876bdbd058d8620d5fe8f02aa05fd7276351</id>
<content type='text'>
commit 336feb502a715909a8136eb6a62a83d7268a353b upstream.

Fix the following -Wstringop-overflow warnings when building with GCC-11:

drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’ accessing 16 bytes in a region of size 10 [-Wstringop-overflow=]
 3106 |         intel_read_wm_latency(dev_priv, dev_priv-&gt;wm.pri_latency);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type ‘u16 *’ {aka ‘short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function ‘intel_read_wm_latency’
 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
      |             ^~~~~~~~~~~~~~~~~~~~~

by removing the over-specified array size from the argument declarations.

It seems that this code is actually safe because the size of the
array depends on the hardware generation, and the function checks
for that.

Notice that wm can be an array of 5 elements:
drivers/gpu/drm/i915/intel_pm.c:3109:   intel_read_wm_latency(dev_priv, dev_priv-&gt;wm.pri_latency);

or an array of 8 elements:
drivers/gpu/drm/i915/intel_pm.c:3131:   intel_read_wm_latency(dev_priv, dev_priv-&gt;wm.skl_latency);

and the compiler legitimately complains about that.

This helps with the ongoing efforts to globally enable
-Wstringop-overflow.

Link: https://github.com/KSPP/linux/issues/181
Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-intel-fixes-2022-05-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes</title>
<updated>2022-05-20T20:01:57+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2022-05-20T20:00:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=64eea6805ecf7092a113bdb4cb73860430d39de6'/>
<id>urn:sha1:64eea6805ecf7092a113bdb4cb73860430d39de6</id>
<content type='text'>
- fix for #5806: GPU hangs and display artifacts on 5.18-rc3 on Intel GM45
- reject DMC with out-of-spec MMIO (Cc: stable)
- correctly mark guilty contexts on GuC reset.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
From: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/YocqqvG6PbYx3QgJ@jlahtine-mobl.ger.corp.intel.com
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2022-05-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes</title>
<updated>2022-05-20T20:00:34+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2022-05-20T19:58:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e4a61cd39685476f7ea74e75fb66666d541050b'/>
<id>urn:sha1:6e4a61cd39685476f7ea74e75fb66666d541050b</id>
<content type='text'>
Fix for a memory leak in dp_mst, a (userspace) build fix for
DMA_BUF_SET_NAME defines and a directory name generation fix for dmabuf
stats

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220520072408.cpjzy2taugagvrh7@houat
</content>
</entry>
<entry>
<title>drm/i915: Use i915_gem_object_ggtt_pin_ww for reloc_iomap</title>
<updated>2022-05-19T09:49:49+00:00</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@linux.intel.com</email>
</author>
<published>2022-05-11T11:52:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b1d6924f27ba24b9e47abb9bd53d0bbc430a835'/>
<id>urn:sha1:7b1d6924f27ba24b9e47abb9bd53d0bbc430a835</id>
<content type='text'>
When removing short term pins, I've changed the the batch buffer
pinning for relocation to use __i915_vma_pin, because
i915_gem_object_ggtt_pin_ww was destroying the old vma. This
caused regressions, because the functions are not identical.

Fix the regressions by calling i915_gem_object_ggtt_pin_ww() again
on ggtt-only platforms, but only if the batch can be pinned without
being moved.

Fixes: b5cfe6f7a6e1 ("drm/i915: Remove short-term pins from execbuf, v6.")
Cc: Matthew Auld &lt;matthew.auld@intel.com&gt;
Reported-by: Mateusz Jończyk &lt;mat.jonczyk@o2.pl&gt;
Tested-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Acked-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5806
Link: https://patchwork.freedesktop.org/patch/msgid/20220511115219.46507-1-maarten.lankhorst@linux.intel.com
(cherry picked from commit 451374eef622fca6f00eeeda89aaccb45a30a149)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/amd: Don't reset dGPUs if the system is going to s2idle</title>
<updated>2022-05-18T19:24:35+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2022-05-17T17:00:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7123d39dc24dcd21ff23d75f46f926b15269b9da'/>
<id>urn:sha1:7123d39dc24dcd21ff23d75f46f926b15269b9da</id>
<content type='text'>
An A+A configuration on ASUS ROG Strix G513QY proves that the ASIC
reset for handling aborted suspend can't work with s2idle.

This functionality was introduced in commit daf8de0874ab5b ("drm/amdgpu:
always reset the asic in suspend (v2)").  A few other commits have
gone on top of the ASIC reset, but this still doesn't work on the A+A
configuration in s2idle.

Avoid doing the reset on dGPUs specifically when using s2idle.

Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)")
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2008
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>drm/dp/mst: fix a possible memory leak in fetch_monitor_name()</title>
<updated>2022-05-17T19:56:18+00:00</updated>
<author>
<name>Hangyu Hua</name>
<email>hbh25y@gmail.com</email>
</author>
<published>2022-05-16T03:20:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e03b13cc7d9427c2c77feed1549191015615202'/>
<id>urn:sha1:6e03b13cc7d9427c2c77feed1549191015615202</id>
<content type='text'>
drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be
freed after use.

Signed-off-by: Hangyu Hua &lt;hbh25y@gmail.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220516032042.13166-1-hbh25y@gmail.com
</content>
</entry>
<entry>
<title>i915/guc/reset: Make __guc_reset_context aware of guilty engines</title>
<updated>2022-05-16T07:13:39+00:00</updated>
<author>
<name>Umesh Nerlige Ramappa</name>
<email>umesh.nerlige.ramappa@intel.com</email>
</author>
<published>2022-04-26T00:30:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=89e96d822bd51f7afe2d3e95a34099480b5c3d55'/>
<id>urn:sha1:89e96d822bd51f7afe2d3e95a34099480b5c3d55</id>
<content type='text'>
There are 2 ways an engine can get reset in i915 and the method of reset
affects how KMD labels a context as guilty/innocent.

(1) GuC initiated engine-reset: GuC resets a hung engine and notifies
KMD. The context that hung on the engine is marked guilty and all other
contexts are innocent. The innocent contexts are resubmitted.

(2) GT based reset: When an engine heartbeat fails to tick, KMD
initiates a gt/chip reset. All active contexts are marked as guilty and
discarded.

In order to correctly mark the contexts as guilty/innocent, pass a mask
of engines that were reset to __guc_reset_context.

Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Umesh Nerlige Ramappa &lt;umesh.nerlige.ramappa@intel.com&gt;
Reviewed-by: Alan Previn &lt;alan.previn.teres.alexis@intel.com&gt;
Signed-off-by: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220426003045.3929439-1-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 303760aa914b7f5ac9602dbb4b471a2ad52eeb3e)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/dmc: Add MMIO range restrictions</title>
<updated>2022-05-16T07:13:39+00:00</updated>
<author>
<name>Anusha Srivatsa</name>
<email>anusha.srivatsa@intel.com</email>
</author>
<published>2022-05-11T00:08:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54395a33718af1c04b5098203335b25382291a16'/>
<id>urn:sha1:54395a33718af1c04b5098203335b25382291a16</id>
<content type='text'>
Bspec has added some steps that check forDMC MMIO range before
programming them

v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean up sanity check logic.(Lucas)
- Add MMIO range for RKL as well.(Anusha)
v5: Use DISPLAY_VER instead of per platform check (Lucas)

BSpec: 49193

Cc: stable@vger.kernel.org
Cc: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Anusha Srivatsa &lt;anusha.srivatsa@intel.com&gt;
Reviewed-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Signed-off-by: Lucas De Marchi &lt;lucas.demarchi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220511000847.1068302-1-anusha.srivatsa@intel.com
(cherry picked from commit 21c47196aec3a93f913a7515e1e7b30e6c54d6c6)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'drm-misc-fixes-2022-05-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes</title>
<updated>2022-05-13T22:34:07+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2022-05-13T22:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eb7bac3973d209e5227d1783676362ee5a8a7127'/>
<id>urn:sha1:eb7bac3973d209e5227d1783676362ee5a8a7127</id>
<content type='text'>
Multiple fixes to fbdev to address a regression at unregistration, an
iommu detection improvement for nouveau, a memory leak fix for nouveau,
pointer dereference fix for dma_buf_file_release(), and a build breakage
fix for vc4

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;

From: Maxime Ripard &lt;maxime@cerno.tech&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220513073044.ymayac7x7bzatrt7@houat
</content>
</entry>
<entry>
<title>drm/vmwgfx: Disable command buffers on svga3 without gbobjects</title>
<updated>2022-05-13T14:29:36+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-03-18T17:43:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=21d1d192890ced87f2f04f8f4dea92406e0b162a'/>
<id>urn:sha1:21d1d192890ced87f2f04f8f4dea92406e0b162a</id>
<content type='text'>
With very limited vram on svga3 it's difficult to handle all the surface
migrations. Without gbobjects, i.e. the ability to store surfaces in
guest mobs, there's no reason to support intermediate svga2 features,
especially because we can fall back to fb traces and svga3 will never
support those in-between features.

On svga3 we wither want to use fb traces or screen targets
(i.e. gbobjects), nothing in between. This fixes presentation on a lot
of fusion/esxi tech previews where the exposed svga3 caps haven't been
finalized yet.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Cc: &lt;stable@vger.kernel.org&gt; # v5.14+
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-5-zack@kde.org
</content>
</entry>
</feed>
