<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_object.c, branch v5.14.8</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.14.8</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.14.8'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-04-15T08:55:18+00:00</updated>
<entry>
<title>drm/virtio: Create Dumb BOs as guest Blobs (v3)</title>
<updated>2021-04-15T08:55:18+00:00</updated>
<author>
<name>Vivek Kasireddy</name>
<email>vivek.kasireddy@intel.com</email>
</author>
<published>2021-04-13T05:26:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3389082bb98296ca5f31ac809a4e5dec5b069148'/>
<id>urn:sha1:3389082bb98296ca5f31ac809a4e5dec5b069148</id>
<content type='text'>
If support for Blob resources is available, then dumb BOs created
by the driver can be considered as guest Blobs.

v2: Don't skip transfer and flush commands as part of plane update
as the device may have created a shared mapping. (Gerd)

v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan)

Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Acked-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20210413052614.2486768-1-vivek.kasireddy@intel.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/virtio: fix possible leak/unlock virtio_gpu_object_array</title>
<updated>2021-03-09T11:06:18+00:00</updated>
<author>
<name>xndcn</name>
<email>xndchn@gmail.com</email>
</author>
<published>2021-03-05T15:18:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=377f8331d0565e6f71ba081c894029a92d0c7e77'/>
<id>urn:sha1:377f8331d0565e6f71ba081c894029a92d0c7e77</id>
<content type='text'>
virtio_gpu_object array is not freed or unlocked in some
failed cases.

Signed-off-by: xndcn &lt;xndchn@gmail.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20210305151819.14330-1-xndchn@gmail.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/shmem-helper: Use cached mappings by default</title>
<updated>2020-11-24T08:10:21+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2020-11-17T13:31:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0cf2ef46c6c0f1a0b475a63633706af8194484df'/>
<id>urn:sha1:0cf2ef46c6c0f1a0b475a63633706af8194484df</id>
<content type='text'>
SHMEM-buffer backing storage is allocated from system memory; which is
typically cachable. The default mode for SHMEM objects is writecombine
though.

Unify SHMEM semantics by defaulting to cached mappings. The exception
is pages imported via dma-buf. DMA memory is usually not cached.

DRM drivers that require write-combined mappings set the map_wc flag
in struct drm_gem_shmem_object to true. This currently affects lima,
panfrost and v3d.

The drivers mgag200, udl, virtio and vkms continue to use default
shmem mappings.

The drivers cirrus and gm12u320 change caching flags. Both used
writecombine and now switch over to shmem defaults. Both drivers use
SHMEM objects as shadow buffers for internal video memory, so cached
mappings will not affect them negatively.

v3:
	* set value of shmem pointer before dereferencing it in
	  __drm_gem_shmem_create() (Dan, kernel test robot)
v2:
	* recreate patch on top of latest SHMEM helpers
	* update lima, panfrost, v3d to select writecombine (Daniel, Rob)

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Acked-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20201117133156.26822-2-tzimmermann@suse.de
</content>
</entry>
<entry>
<title>drm/virtio: use kvmalloc for large allocations</title>
<updated>2020-11-05T11:33:26+00:00</updated>
<author>
<name>Sergey Senozhatsky</name>
<email>senozhatsky@chromium.org</email>
</author>
<published>2020-11-05T01:47:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea86f3defd55f141a44146e66cbf8ffb683d60da'/>
<id>urn:sha1:ea86f3defd55f141a44146e66cbf8ffb683d60da</id>
<content type='text'>
We observed that some of virtio_gpu_object_shmem_init() allocations
can be rather costly - order 6 - which can be difficult to fulfill
under memory pressure conditions. Switch to kvmalloc_array() in
virtio_gpu_object_shmem_init() and let the kernel vmalloc the entries
array.

Signed-off-by: Sergey Senozhatsky &lt;senozhatsky@chromium.org&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20201105014744.1662226-1-senozhatsky@chromium.org
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge drm/drm-next into drm-misc-next</title>
<updated>2020-11-02T10:17:54+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>maxime@cerno.tech</email>
</author>
<published>2020-11-02T10:17:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c489573b5b6ce6442ad4658d9d5ec77839b91622'/>
<id>urn:sha1:c489573b5b6ce6442ad4658d9d5ec77839b91622</id>
<content type='text'>
Daniel needs -rc2 in drm-misc-next to merge some patches

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;
</content>
</entry>
<entry>
<title>drm/virtio: implement blob resources: resource create blob ioctl</title>
<updated>2020-09-29T09:23:51+00:00</updated>
<author>
<name>Gerd Hoffmann</name>
<email>kraxel@redhat.com</email>
</author>
<published>2020-09-24T00:32:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=897b4d1acaf56314652c6a8e75d9f86b5e45638d'/>
<id>urn:sha1:897b4d1acaf56314652c6a8e75d9f86b5e45638d</id>
<content type='text'>
Implement resource create blob as specified.

Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Acked-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-18-gurchetansingh@chromium.org
Co-developed-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Signed-off-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/virtio: implement blob resources: implement vram object</title>
<updated>2020-09-29T09:23:33+00:00</updated>
<author>
<name>Gerd Hoffmann</name>
<email>kraxel@redhat.com</email>
</author>
<published>2020-09-24T00:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16845c5d540929d2f4dc845f11fbbb238e69170a'/>
<id>urn:sha1:16845c5d540929d2f4dc845f11fbbb238e69170a</id>
<content type='text'>
A virtio-gpu vram object is based on range-based allocation.
No guest shmemfs backing, so we call drm_gem_private_object_init.

This is for host memory without any guest backing (atleast initially).

Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Acked-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-12-gurchetansingh@chromium.org
Co-developed-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Signed-off-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
</content>
</entry>
<entry>
<title>drm/virtio: implement blob resources: expose virtio_gpu_resource_id_get</title>
<updated>2020-09-29T09:23:28+00:00</updated>
<author>
<name>Gurchetan Singh</name>
<email>gurchetansingh@chromium.org</email>
</author>
<published>2020-09-24T00:32:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f895c70713721da661588b3004424974d6125fe8'/>
<id>urn:sha1:f895c70713721da661588b3004424974d6125fe8</id>
<content type='text'>
VRAM object will need it.

Signed-off-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Acked-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-10-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/virtio: blob prep: refactor getting pages and attaching backing</title>
<updated>2020-09-29T09:22:42+00:00</updated>
<author>
<name>Gurchetan Singh</name>
<email>gurchetansingh@chromium.org</email>
</author>
<published>2020-09-24T00:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=30172efbfb842cd898e34fea8694ed250200eaab'/>
<id>urn:sha1:30172efbfb842cd898e34fea8694ed250200eaab</id>
<content type='text'>
Useful for upcoming blob resources.

Signed-off-by: Gurchetan Singh &lt;gurchetansingh@chromium.org&gt;
Acked-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-1-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
</content>
</entry>
<entry>
<title>drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs</title>
<updated>2020-09-25T07:21:33+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2020-09-23T10:21:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c6069a02fa554302b93274c6d75d14251200de18'/>
<id>urn:sha1:c6069a02fa554302b93274c6d75d14251200de18</id>
<content type='text'>
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-19-tzimmermann@suse.de
</content>
</entry>
</feed>
