<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/vmwgfx, 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-05-03T14:04:22+00:00</updated>
<entry>
<title>fbdev: Use pageref offset for deferred-I/O writeback</title>
<updated>2022-05-03T14:04:22+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-04-29T10:08:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2d8b4289c937447ab710052f15a18f686db73dc'/>
<id>urn:sha1:e2d8b4289c937447ab710052f15a18f686db73dc</id>
<content type='text'>
Use pageref-&gt;offset instead of page-&gt;index for deferred-I/O writeback
where appropriate. Distinguishes between file-mapping offset and video-
memory offset. While at it, also remove unnecessary references to
struct page.

Fbdev's deferred-I/O code uses the two related page-&gt;index and
pageref-&gt;offset. The former is the page offset in the mapped file,
the latter is the byte offset in the video memory (or fbdev screen
buffer). It's the same value for fbdev drivers, but for DRM the values
can be different. Because GEM buffer objects are mapped at an offset
in the DRM device file, page-&gt;index has this offset added to it as well.
We currently don't hit this case in DRM, because all affected mappings
of GEM memory are performed with an internal, intermediate shadow buffer.

The value of page-&gt;index is required by page_mkclean(), which we
call to reset the mappings during the writeback phase of the deferred
I/O. The value of pageref-&gt;offset is for conveniently getting an offset
into video memory in fb helpers.

v4:
	* fix commit message (Javier)

Suggested-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-6-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev: Rename pagelist to pagereflist for deferred I/O</title>
<updated>2022-05-03T14:04:22+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-04-29T10:08:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e80eec1b871a2acb8f5c92db4c237e9ae6dd322b'/>
<id>urn:sha1:e80eec1b871a2acb8f5c92db4c237e9ae6dd322b</id>
<content type='text'>
Rename various instances of pagelist to pagereflist. The list now
stores pageref structures, so the new name is more appropriate.

In their write-back helpers, several fbdev drivers refer to the
pageref list in struct fb_deferred_io instead of using the one
supplied as argument to the function. Convert them over to the
supplied one. It's the same instance, so no change of behavior
occurs.

v4:
	* fix commit message (Javier)

Suggested-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-5-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev: Track deferred-I/O pages in pageref struct</title>
<updated>2022-05-03T14:04:22+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-04-29T10:08:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=56c134f7f1b58be08bdb0ca8372474a4a5165f31'/>
<id>urn:sha1:56c134f7f1b58be08bdb0ca8372474a4a5165f31</id>
<content type='text'>
Store the per-page state for fbdev's deferred I/O in struct
fb_deferred_io_pageref. Maintain a list of pagerefs for the pages
that have to be written back to video memory. Update all affected
drivers.

As with pages before, fbdev acquires a pageref when an mmaped page
of the framebuffer is being written to. It holds the pageref in a
list of all currently written pagerefs until it flushes the written
pages to video memory. Writeback occurs periodically. After writeback
fbdev releases all pagerefs and builds up a new dirty list until the
next writeback occurs.

Using pagerefs has a number of benefits.

For pages of the framebuffer, the deferred I/O code used struct
page.lru as an entry into the list of dirty pages. The lru field is
owned by the page cache, which makes deferred I/O incompatible with
some memory pages (e.g., most notably DRM's GEM SHMEM allocator).
struct fb_deferred_io_pageref now provides an entry into a list of
dirty framebuffer pages, freeing lru for use with the page cache.

Drivers also assumed that struct page.index is the page offset into
the framebuffer. This is not true for DRM buffers, which are located
at various offset within a mapped area. struct fb_deferred_io_pageref
explicitly stores an offset into the framebuffer. struct page.index
is now only the page offset into the mapped area.

These changes will allow DRM to use fbdev deferred I/O without an
intermediate shadow buffer.

v3:
	* use pageref-&gt;offset for sorting
	* fix grammar in comment
v2:
	* minor fixes in commit message

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-3-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>fbdev: Put mmap for deferred I/O into drivers</title>
<updated>2022-05-03T14:04:21+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2022-04-29T10:08:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5905585103276b7c14bb9a7de4b575216cb6dac4'/>
<id>urn:sha1:5905585103276b7c14bb9a7de4b575216cb6dac4</id>
<content type='text'>
The fbdev mmap function fb_mmap() unconditionally overrides the
driver's implementation if deferred I/O has been activated. This
makes it hard to implement mmap with anything but a vmalloc()'ed
software buffer. That is specifically a problem for DRM, where
video memory is maintained by a memory manager.

Leave the mmap handling to drivers and expect them to call the
helper for deferred I/O by thmeselves.

v4:
	* unlock mm_lock in fb_mmap() error path (Dan)
v3:
	* fix warning if fb_mmap is missing (kernel test robot)
v2:
	* print a helpful error message if the defio setup is
	  incorrect (Javier)

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-2-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>Backmerge tag 'v5.18-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next</title>
<updated>2022-05-03T06:08:48+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2022-05-03T06:08:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e954d2c94d007afe487044ecfa48f2518643df0e'/>
<id>urn:sha1:e954d2c94d007afe487044ecfa48f2518643df0e</id>
<content type='text'>
Linux 5.18-rc5

There was a build fix for arm I wanted in drm-next, so backmerge rather then cherry-pick.

Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Reserve fence slots on buffer objects in cotables</title>
<updated>2022-04-23T01:41:14+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-04-22T16:13:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=544ccad739251b21dfa1e7f4b57aa9ea50d2d0f1'/>
<id>urn:sha1:544ccad739251b21dfa1e7f4b57aa9ea50d2d0f1</id>
<content type='text'>
The buffer objects created by cotables were missing fence reservations.
They are created from vmw_validation_res_validate which makes them miss
the ttm_eu_reserve_buffers which is called from vmw_validation_bo_reserve.

Cotables are the only resources which create a buffer object in the
create callback so make sure the code also reserves the slots.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Co-developed-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4")
Link: https://patchwork.freedesktop.org/patch/msgid/20220422161342.1142584-1-zack@kde.org
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix gem refcounting and memory evictions</title>
<updated>2022-04-21T01:30:43+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-04-20T04:03:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=298799a28264ce400d9ff95c51b7adcb123d866e'/>
<id>urn:sha1:298799a28264ce400d9ff95c51b7adcb123d866e</id>
<content type='text'>
v2: Add the last part of the ref count fix which was spotted by
Philipp Sieweck where the ref count of cpu writers is off due to
ERESTARTSYS or EBUSY during bo waits.

The initial GEM port broke refcounting on shareable (prime) surfaces and
memory evictions. The prime surfaces broke because the parent surfaces
weren't increasing the ref count on GEM surfaces, which meant that
the memory backing textures could have been deleted while the texture
was still accessible. The evictions broke due to a typo, the code was
supposed to exit if the passed buffers were not vmw_buffer_object
not if they were. They're tied because the evictions depend on having
memory to actually evict.

This fixes crashes with XA state tracker which is used for xrender
acceleration on xf86-video-vmware, apps/tests which use a lot of
memory (a good test being the piglit's streaming-texture-leak) and
desktops.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reported-by: Philipp Sieweck &lt;psi@informatik.uni-kiel.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.17+
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220420040328.1007409-1-zack@kde.org
</content>
</entry>
<entry>
<title>drm/vmwgfx: Add debugfs entries for various ttm resource managers</title>
<updated>2022-04-21T01:06:02+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-04-12T03:35:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af4a25bbe5e7e60ff696ef5c1ec48ab2d51c17c6'/>
<id>urn:sha1:af4a25bbe5e7e60ff696ef5c1ec48ab2d51c17c6</id>
<content type='text'>
Use the newly added TTM's ability to automatically create debugfs entries
for specified placements. This creates debugfs files that can be read to
get information about various TTM resource managers which are used by
vmwgfx.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220412033526.369115-3-zack@kde.org
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
</content>
</entry>
<entry>
<title>drm/ttm: remove bo-&gt;moving</title>
<updated>2022-04-07T10:53:54+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2021-11-23T10:30:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8bb31587820a6e04cb613b49238b1800d1a97223'/>
<id>urn:sha1:8bb31587820a6e04cb613b49238b1800d1a97223</id>
<content type='text'>
This is now handled by the DMA-buf framework in the dma_resv obj.

Also remove the workaround inside VMWGFX to update the moving fence.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-14-christian.koenig@amd.com
</content>
</entry>
<entry>
<title>dma-buf: add DMA_RESV_USAGE_KERNEL v3</title>
<updated>2022-04-07T10:53:54+00:00</updated>
<author>
<name>Christian König</name>
<email>christian.koenig@amd.com</email>
</author>
<published>2021-11-26T13:12:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b29895e18304feb7e8afc6388db7ece60327b23c'/>
<id>urn:sha1:b29895e18304feb7e8afc6388db7ece60327b23c</id>
<content type='text'>
Add an usage for kernel submissions. Waiting for those are mandatory for
dynamic DMA-bufs.

As a precaution this patch also changes all occurrences where fences are
added as part of memory management in TTM, VMWGFX and i915 to use the
new value because it now becomes possible for drivers to ignore fences
with the WRITE usage.

v2: use "must" in documentation, fix whitespaces
v3: separate out some driver changes and better document why some
    changes should still be part of this patch.

Signed-off-by: Christian König &lt;christian.koenig@amd.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-5-christian.koenig@amd.com
</content>
</entry>
</feed>
