<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/i915, branch v5.19</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-07-25T14:57:54+00:00</updated>
<entry>
<title>drm/i915/reset: Add additional steps for Wa_22011802037 for execlist backend</title>
<updated>2022-07-25T14:57:54+00:00</updated>
<author>
<name>Umesh Nerlige Ramappa</name>
<email>umesh.nerlige.ramappa@intel.com</email>
</author>
<published>2022-06-21T19:21:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a7a47a5dfa9a9692a41764ee9ab4054f12924a42'/>
<id>urn:sha1:a7a47a5dfa9a9692a41764ee9ab4054f12924a42</id>
<content type='text'>
For execlists backend, current implementation of Wa_22011802037 is to
stop the CS before doing a reset of the engine. This WA was further
extended to wait for any pending MI FORCE WAKEUPs before issuing a
reset. Add the extended steps in the execlist path of reset.

In addition, extend the WA to gen11.

v2: (Tvrtko)
- Clarify comments, commit message, fix typos
- Use IS_GRAPHICS_VER for gen 11/12 checks

v3: (Daneile)
- Drop changes to intel_ring_submission since WA does not apply to it
- Log an error if MSG IDLE is not defined for an engine

Signed-off-by: Umesh Nerlige Ramappa &lt;umesh.nerlige.ramappa@intel.com&gt;
Fixes: f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force cs halt")
Acked-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Reviewed-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Signed-off-by: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220621192105.2100585-1-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 0667429ce68e0b08f9f1fec8fd0b1f57228f605e)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/guc: support v69 in parallel to v70</title>
<updated>2022-07-20T01:25:03+00:00</updated>
<author>
<name>Daniele Ceraolo Spurio</name>
<email>daniele.ceraolospurio@intel.com</email>
</author>
<published>2022-07-18T23:07:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=443148858f26ee0fea6ad1b292d49d884dce92d1'/>
<id>urn:sha1:443148858f26ee0fea6ad1b292d49d884dce92d1</id>
<content type='text'>
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk and only for platforms that
are out of force_probe and require the GuC by default. All v69 specific
code has been labeled as such for easy identification, and the same was
done for all v70 functions for which there is a separate v69 version,
to avoid accidentally calling the wrong version via the unlabeled name.

When the fallback mode kicks in, a drm_notice message is printed in
dmesg to inform the user of the required update. The existing
logging of the fetch function has also been updated so that we no
longer complain immediately if we can't find a fw and we only throw an
error if the fetch of both the base and fallback blobs fails.

The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.

v2: reduce the fallback to platform that require it, switch to
firmware_request_nowarn(), improve logs.

Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Cc: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Cc: Dave Airlie &lt;airlied@gmail.com&gt;
Cc: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Acked-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Reviewed-by: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220718230732.1409641-1-daniele.ceraolospurio@intel.com
(cherry picked from commit 774ce1510e6ccb9c0752d4aa7a9ff3624b3db3f3)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/guc: Support programming the EU priority in the GuC descriptor</title>
<updated>2022-07-20T01:24:48+00:00</updated>
<author>
<name>Matthew Brost</name>
<email>matthew.brost@intel.com</email>
</author>
<published>2022-05-04T23:46:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7999fa14f19254ee6a8b52e2711de1f6bef2a1c'/>
<id>urn:sha1:e7999fa14f19254ee6a8b52e2711de1f6bef2a1c</id>
<content type='text'>
In GuC submission mode the EU priority must be updated by the GuC rather
than the driver as the GuC owns the programming of the context descriptor.

Given that the GuC code uses the GuC priorities, we can't use a generic
function using i915 priorities for both execlists and GuC submission.
The existing function has therefore been pushed to the execlists
back-end while a new one has been added for GuC.

v2: correctly use the GuC prio.

Cc: John Harrison &lt;john.c.harrison@intel.com&gt;
Cc: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Aravind Iddamsetty &lt;aravind.iddamsetty@intel.com&gt;
Signed-off-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Reviewed-by: John Harrison &lt;John.C.Harrison@Intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220504234636.2119794-1-daniele.ceraolospurio@intel.com
(cherry picked from commit a5c89f7c43c12c592a882a0ec2a15e9df0011e80)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/ttm: fix 32b build</title>
<updated>2022-07-17T18:53:47+00:00</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2022-07-12T17:40:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ced7866db39fc5c59ee05e154d4abc0977a17f6b'/>
<id>urn:sha1:ced7866db39fc5c59ee05e154d4abc0977a17f6b</id>
<content type='text'>
Since segment_pages is no longer a compile time constant, it looks the
DIV_ROUND_UP(node-&gt;size, segment_pages) breaks the 32b build. Simplest
is just to use the ULL variant, but really we should need not need more
than u32 for the page alignment (also we are limited by that due to the
sg-&gt;length type), so also make it all u32.

Reported-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Fixes: aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Nirmoy Das &lt;nirmoy.das@linux.intel.com&gt;
Reviewed-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220712174050.592550-1-matthew.auld@intel.com
(cherry picked from commit 9306b2b2dfce6931241ef804783692cee526599c)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/selftests: fix subtraction overflow bug</title>
<updated>2022-07-12T22:21:58+00:00</updated>
<author>
<name>Andrzej Hajda</name>
<email>andrzej.hajda@intel.com</email>
</author>
<published>2022-06-24T11:35:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=333991c4e66b3d4b5613315f18016da80344f659'/>
<id>urn:sha1:333991c4e66b3d4b5613315f18016da80344f659</id>
<content type='text'>
On some machines hole_end can be small enough to cause subtraction
overflow. On the other side (addr + 2 * min_alignment) can overflow
in case of mock tests. This patch should handle both cases.

Fixes: e1c5f754067b59 ("drm/i915: Avoid overflow in computing pot_hole loop termination")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3674
Signed-off-by: Andrzej Hajda &lt;andrzej.hajda@intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Signed-off-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220624113528.2159210-1-andrzej.hajda@intel.com
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gem: Look for waitboosting across the whole object prior to individual waits</title>
<updated>2022-07-12T22:21:55+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2022-07-08T14:20:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad765fae792e16ce3c1d0b69ce939e3f7dba40ab'/>
<id>urn:sha1:ad765fae792e16ce3c1d0b69ce939e3f7dba40ab</id>
<content type='text'>
We employ a "waitboost" heuristic to detect when userspace is stalled
waiting for results from earlier execution. Under latency sensitive work
mixed between the gpu/cpu, the GPU is typically under-utilised and so
RPS sees that low utilisation as a reason to downclock the frequency,
causing longer stalls and lower throughput. The user left waiting for
the results is not impressed.

On applying commit 047a1b877ed4 ("dma-buf &amp; drm/amdgpu: remove dma_resv
workaround") it was observed that deinterlacing h264 on Haswell
performance dropped by 2-5x. The reason being that the natural workload
was not intense enough to trigger RPS (using HW evaluation intervals) to
upclock, and so it was depending on waitboosting for the throughput.

Commit 047a1b877ed4 ("dma-buf &amp; drm/amdgpu: remove dma_resv workaround")
changes the composition of dma-resv from keeping a single write fence +
multiple read fences, to a single array of multiple write and read
fences (a maximum of one pair of write/read fences per context). The
iteration order was also changed implicitly from all-read fences then
the single write fence, to a mix of write fences followed by read
fences. It is that ordering change that belied the fragility of
waitboosting.

Currently, a waitboost is inspected at the point of waiting on an
outstanding fence. If the GPU is backlogged such that we haven't yet
stated the request we need to wait on, we force the GPU to upclock until
the completion of that request. By changing the order in which we waited
upon requests, we ended up waiting on those requests in sequence and as
such we saw that each request was already started and so not a suitable
candidate for waitboosting.

Instead of asking whether to boost each fence in turn, we can look at
whether boosting is required for the dma-resv ensemble prior to waiting
on any fence, making the heuristic more robust to the order in which
fences are stored in the dma-resv.

Reported-by: Thomas Voegtle &lt;tv@lio96.de&gt;
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6284
Fixes: 047a1b877ed4 ("dma-buf &amp; drm/amdgpu: remove dma_resv workaround")
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Signed-off-by: Karolina Drobnik &lt;karolina.drobnik@intel.com&gt;
Tested-by: Thomas Voegtle &lt;tv@lio96.de&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Acked-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/07e05518d9f6620d20cc1101ec1849203fe973f9.1657289332.git.karolina.drobnik@intel.com
(cherry picked from commit 394e2b57a989113de494c52d4683444bcb02d4e1)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gt: Serialize TLB invalidates with GT resets</title>
<updated>2022-07-12T22:21:52+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris.p.wilson@intel.com</email>
</author>
<published>2022-07-12T15:21:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1c5a7bf79c1faa5633b918b5c0666545e84c4d1'/>
<id>urn:sha1:a1c5a7bf79c1faa5633b918b5c0666545e84c4d1</id>
<content type='text'>
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore-&gt;lock as well to serialise
the mmio access, thereby serialising with the GDRST.

Tested on a NUC5i7RYB, BIOS RYBDWi35.86A.0380.2019.0517.1530 with
i915 selftest/hangcheck.

Cc: stable@vger.kernel.org  # v4.4 and upper
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Reported-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Tested-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Reviewed-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Chris Wilson &lt;chris.p.wilson@intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@linux.intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Acked-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1e59a7c45dd919a530256b9ac721ac6ea86c0677.1657639152.git.mchehab@kernel.org
(cherry picked from commit 33da97894758737895e90c909f16786052680ef4)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gt: Serialize GRDOM access between multiple engine resets</title>
<updated>2022-07-12T22:21:48+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2022-07-12T15:21:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b24dcf1dc507f69ed3b5c66c2b6a0209ae80d4d4'/>
<id>urn:sha1:b24dcf1dc507f69ed3b5c66c2b6a0209ae80d4d4</id>
<content type='text'>
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore-&gt;lock, which will also ensure
that no other GT state changes at the same time as the actual reset.

Cc: stable@vger.kernel.org # v4.4 and upper
Reported-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Acked-by: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@intel.com&gt;
Reviewed-by: Andrzej Hajda &lt;andrzej.hajda@intel.com&gt;
Acked-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/e0a2d894e77aed7c2e36b0d1abdc7dbac3011729.1657639152.git.mchehab@kernel.org
(cherry picked from commit 336561a914fc0c6f1218228718f633b31b7af1c3)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/ttm: fix sg_table construction</title>
<updated>2022-07-12T22:21:45+00:00</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2022-07-11T08:58:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aff1e0b09b54b64944b7fe32997229552737b9e9'/>
<id>urn:sha1:aff1e0b09b54b64944b7fe32997229552737b9e9</id>
<content type='text'>
If we encounter some monster sized local-memory page that exceeds the
maximum sg length (UINT32_MAX), ensure that don't end up with some
misaligned address in the entry that follows, leading to fireworks
later. Also ensure we have some coverage of this in the selftests.

v2(Chris):
  - Use round_down consistently to avoid udiv errors
v3(Nirmoy):
  - Also update the max_segment in the selftest

Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Cc: Nirmoy Das &lt;nirmoy.das@linux.intel.com&gt;
Reviewed-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220711085859.24198-1-matthew.auld@intel.com
(cherry picked from commit bc99f1209f19fefa3ee11e77464ccfae541f4291)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/selftests: fix a couple IS_ERR() vs NULL tests</title>
<updated>2022-07-12T22:21:41+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2022-07-08T09:41:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=896dcabd1f8f613c533d948df17408c41f8929f5'/>
<id>urn:sha1:896dcabd1f8f613c533d948df17408c41f8929f5</id>
<content type='text'>
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.

Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the default context state")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220708094104.GL2316@kadam
(cherry picked from commit d50f5a109cf4ed50c5b575c1bb5fc3bd17b23308)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
</feed>
