<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/gpu/drm/i915, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/i915?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/gpu/drm/i915?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-07T13:13:09Z</updated>
<entry>
<title>drm/i915/userptr: restore probe_range behaviour</title>
<updated>2022-11-07T13:13:09Z</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2022-10-28T13:06:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=178e31ce82d0308a9e5f2f15bfb4493160136729'/>
<id>urn:sha1:178e31ce82d0308a9e5f2f15bfb4493160136729</id>
<content type='text'>
The conversion looks harmless, however the addr value is updated inside
the loop with the previous vm_end, which then incorrectly leads to
for_each_vma_range() iterating over stuff outside the range we care
about. Fix this by storing the end value separately. Also fix the case
where the range doesn't intersect with any vma, or if the vma itself
doesn't extend the entire range, which must mean we have hole at the
end. Both should result in an error, as per the previous behaviour.

v2: Fix the cases where the range is empty, or if there's a hole at
the end of the range

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7247
Testcase: igt@gem_userptr_blits@probe
Fixes: f683b9d61319 ("i915: use the VMA iterator")
Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@linux.intel.com&gt;
Cc: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Cc: Liam R. Howlett &lt;Liam.Howlett@Oracle.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Yu Zhao &lt;yuzhao@google.com&gt;
Reviewed-by: Liam R. Howlett &lt;Liam.Howlett@oracle.com&gt;
Reviewed-by: Andrzej Hajda &lt;andrzej.hajda@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221028130635.465839-1-matthew.auld@intel.com
(cherry picked from commit 6f7de35b50860c345babf8ed0aa0d75f9315eee4)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Do not set cache_dirty for DGFX</title>
<updated>2022-11-07T13:13:04Z</updated>
<author>
<name>Niranjana Vishwanathapura</name>
<email>niranjana.vishwanathapura@intel.com</email>
</author>
<published>2022-11-02T05:14:16Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=19b168136395150a4a6e011f944eb30d3d85094b'/>
<id>urn:sha1:19b168136395150a4a6e011f944eb30d3d85094b</id>
<content type='text'>
Currently on DG1, which does not have LLC, we hit the below
warning while rebinding an userptr invalidated object.

WARNING: CPU: 4 PID: 13008 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 __i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
...
Call Trace:
 &lt;TASK&gt;
 i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
 ____i915_gem_object_get_pages+0x32/0xb0 [i915]
 i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
 eb_lookup_vmas+0x2ff/0xcf0 [i915]
 ? __intel_wakeref_get_first+0x55/0xb0 [i915]
 i915_gem_do_execbuffer+0x785/0x21d0 [i915]
 i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]

We shouldn't be setting the obj-&gt;cache_dirty for DGFX,
fix it.

Fixes: d70af57944a1 ("drm/i915/shmem: ensure flush during swap-in on non-LLC")
Suggested-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Reported-by: Niranjana Vishwanathapura &lt;niranjana.vishwanathapura@intel.com&gt;
Signed-off-by: Niranjana Vishwanathapura &lt;niranjana.vishwanathapura@intel.com&gt;
Acked-by: Nirmoy Das &lt;nirmoy.das@intel.com&gt;
Reviewed-by: Matthew Auld &lt;matthew.auld@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/20221102051416.27327-1-niranjana.vishwanathapura@intel.com
(cherry picked from commit 0aeec60c76ca2631696b4228f3fc99fe3a80013d)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/psr: Send update also on invalidate</title>
<updated>2022-11-07T13:13:00Z</updated>
<author>
<name>Jouni Högander</name>
<email>jouni.hogander@intel.com</email>
</author>
<published>2022-10-24T05:46:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=4ff4ebac3f1378f4ba6e11fe5ad4a4ac590bb8a4'/>
<id>urn:sha1:4ff4ebac3f1378f4ba6e11fe5ad4a4ac590bb8a4</id>
<content type='text'>
Currently we are observing mouse cursor stuttering when using
xrandr --scaling=1.2x1.2. X scaling/transformation seems to be
doing fronbuffer rendering. When moving mouse cursor X seems to
perform several invalidates and only one DirtyFB. I.e. it seems
to be assuming updates are sent to panel while drawing is done.

Earlier we were disabling PSR in frontbuffer invalidate call back
(when drawing in X started). PSR was re-enabled in frontbuffer
flush callback (dirtyfb ioctl). This was working fine with X
scaling/transformation. Now we are just enabling continuous full
frame (cff) in PSR invalidate callback. Enabling cff doesn't
trigger any updates. It just configures PSR to send full frame
when updates are sent. I.e. there are no updates on screen before
PSR flush callback is made. X seems to be doing several updates
in frontbuffer before doing dirtyfb ioctl.

Fix this by sending single update on every invalidate callback.

Cc: José Roberto de Souza &lt;jose.souza@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Mika Kahola &lt;mika.kahola@intel.com&gt;

Fixes: 805f04d42a6b ("drm/i915/display/psr: Use continuos full frame to handle frontbuffer invalidations")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6679
Signed-off-by: Jouni Högander &lt;jouni.hogander@intel.com&gt;
Reported-by: Brian J. Tarricone &lt;brian@tarricone.org&gt;
Tested-by: Brian J. Tarricone &lt;brian@tarricone.org&gt;
Reviewed-by: Mika Kahola &lt;mika.kahola@intel.com&gt;
Reviewed-by: José Roberto de Souza &lt;jose.souza@intel.com&gt;
Signed-off-by: José Roberto de Souza &lt;jose.souza@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221024054649.31299-1-jouni.hogander@intel.com
(cherry picked from commit d755f89220a2b49bc90b7b520bb6edeb4adb5f01)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/dmabuf: fix sg_table handling in map_dma_buf</title>
<updated>2022-11-07T13:12:57Z</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2022-10-28T15:50:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f90daa975911961b65070ec72bd7dd8d448f9ef7'/>
<id>urn:sha1:f90daa975911961b65070ec72bd7dd8d448f9ef7</id>
<content type='text'>
We need to iterate over the original entries here for the sg_table,
pulling out the struct page for each one, to be remapped. However
currently this incorrectly iterates over the final dma mapped entries,
which is likely just one gigantic sg entry if the iommu is enabled,
leading to us only mapping the first struct page (and any physically
contiguous pages following it), even if there is potentially lots more
data to follow.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
Fixes: 1286ff739773 ("i915: add dmabuf/prime buffer sharing support.")
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Lionel Landwerlin &lt;lionel.g.landwerlin@intel.com&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@linux.intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v3.5+
Reviewed-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221028155029.494736-1-matthew.auld@intel.com
(cherry picked from commit 28d52f99bbca7227008cf580c9194c9b3516968e)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs</title>
<updated>2022-10-31T14:09:15Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2022-10-26T10:11:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=12caf46cf4fc92b1c3884cb363ace2e12732fd2f'/>
<id>urn:sha1:12caf46cf4fc92b1c3884cb363ace2e12732fd2f</id>
<content type='text'>
drm_mode_probed_add() is unhappy about being called w/o
mode_config.mutex. Grab it during LVDS fixed mode setup
to silence the WARNs.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit a3cd4f447281c56377de2ee109327400eb00668d)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes()</title>
<updated>2022-10-31T14:08:30Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2022-09-27T18:06:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d372ec94a018c3a19dad71e2ee3478126394d9fc'/>
<id>urn:sha1:d372ec94a018c3a19dad71e2ee3478126394d9fc</id>
<content type='text'>
Since commit a5810f551d0a ("drm/i915: Allow more varied alternate
fixed modes for panels") intel_panel_add_edid_alt_fixed_modes()
no longer considers vrr vs. drrs separately. So no reason to
pass them as separate parameters either.

Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit eb89e83c152b122a94e79527d63cb7c79823c37e)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/sdvo: Setup DDC fully before output init</title>
<updated>2022-10-31T12:32:10Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2022-10-26T10:11:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=e79762512120f11c51317570519a1553c70805d8'/>
<id>urn:sha1:e79762512120f11c51317570519a1553c70805d8</id>
<content type='text'>
Call intel_sdvo_select_ddc_bus() before initializing any
of the outputs. And before that is functional (assuming no VBT)
we have to set up the controlled_outputs thing. Otherwise DDC
won't be functional during the output init but LVDS really
needs it for the fixed mode setup.

Note that the whole multi output support still looks very
bogus, and more work will be needed to make it correct.
But for now this should at least fix the LVDS EDID fixed mode
setup.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit 64b7b557dc8a96d9cfed6aedbf81de2df80c025d)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/sdvo: Filter out invalid outputs more sensibly</title>
<updated>2022-10-31T12:32:07Z</updated>
<author>
<name>Ville Syrjälä</name>
<email>ville.syrjala@linux.intel.com</email>
</author>
<published>2022-10-26T10:11:27Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3e206b6aa6df7eed4297577e0cf8403169b800a2'/>
<id>urn:sha1:3e206b6aa6df7eed4297577e0cf8403169b800a2</id>
<content type='text'>
We try to filter out the corresponding xxx1 output
if the xxx0 output is not present. But the way that is
being done is pretty awkward. Make it less so.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit cc1e66394daaa7e9f005e2487a84e34a39f9308b)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915: stop abusing swiotlb_max_segment</title>
<updated>2022-10-31T12:32:04Z</updated>
<author>
<name>Robert Beckett</name>
<email>bob.beckett@collabora.com</email>
</author>
<published>2022-10-20T11:03:08Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d3f6bacfca86f6cf6bf85be1e8b54083d68d8195'/>
<id>urn:sha1:d3f6bacfca86f6cf6bf85be1e8b54083d68d8195</id>
<content type='text'>
swiotlb_max_segment used to return either the maximum size that swiotlb
could bounce, or for Xen PV PAGE_SIZE even if swiotlb could bounce buffer
larger mappings.  This made i915 on Xen PV work as it bypasses the
coherency aspect of the DMA API and can't cope with bounce buffering
and this avoided bounce buffering for the Xen/PV case.

So instead of adding this hack back, check for Xen/PV directly in i915
for the Xen case and otherwise use the proper DMA API helper to query
the maximum mapping size.

Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.

Fixes: a2daa27c0c61 ("swiotlb: simplify swiotlb_max_segment")
Reported-by: Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;
Signed-off-by: Robert Beckett &lt;bob.beckett@collabora.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
[hch: added the Xen hack, rewrote the changelog]
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221020110308.1582518-1-hch@lst.de
(cherry picked from commit 78a07fe777c42800bd1adaec12abe5dcee43919e)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/tgl+: Add locking around DKL PHY register accesses</title>
<updated>2022-10-31T12:31:57Z</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2022-10-25T11:44:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d7164a5048e8a6afe2cc4aaf7f12643c14e7f241'/>
<id>urn:sha1:d7164a5048e8a6afe2cc4aaf7f12643c14e7f241</id>
<content type='text'>
Accessing the TypeC DKL PHY registers during modeset-commit,
-verification, DP link-retraining and AUX power well toggling is racy
due to these code paths being concurrent and the PHY register bank
selection register (HIP_INDEX_REG) being shared between PHY instances
(aka TC ports) and the bank selection being not atomic wrt. the actual
PHY register access.

Add the required locking around each PHY register bank selection-&gt;
register access sequence.

Kudos to Ville for noticing the race conditions.

v2:
- Add the DKL PHY register accessors to intel_dkl_phy.[ch]. (Jani)
- Make the DKL_REG_TC_PORT macro independent of PHY internals.
- Move initing the DKL PHY lock to a more logical place.

v3:
- Fix parameter reuse in the DKL_REG_TC_PORT definition.
- Document the usage of phy_lock.

v4:
- Fix adding TC_PORT_1 offset in the DKL_REG_TC_PORT definition.

Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Jani Nikula &lt;jani.nikula@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.5+
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Imre Deak &lt;imre.deak@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221025114457.2191004-1-imre.deak@intel.com
(cherry picked from commit 89cb0ba4ceee6bed1059904859c5723b3f39da68)
Signed-off-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt;
</content>
</entry>
</feed>
