similar to: [PATCH v3 4/4] drm/virtio: Support virtgpu exported resources

Displaying 20 results from an estimated 5000 matches similar to: "[PATCH v3 4/4] drm/virtio: Support virtgpu exported resources"

2020 Jun 08
0
[PATCH v3 4/4] drm/virtio: Support virtgpu exported resources
On Mon, Jun 08, 2020 at 07:36:55PM +0900, David Stevens wrote: > On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote: > > > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) { > > > > > +
2020 May 13
0
[PATCH v3 4/4] drm/virtio: Support virtgpu exported resources
On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote: > Add support for UUID-based resource sharing mechanism to virtgpu. This > implements the new virtgpu commands and hooks them up to dma-buf's > get_uuid callback. > > Signed-off-by: David Stevens <stevensd at chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++ >
2020 Mar 02
0
[virtio-dev] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources
On Mon, Mar 2, 2020 at 4:15 AM David Stevens <stevensd at chromium.org> wrote: > > Add support for UUID-based resource sharing mechanism to virtgpu. This > implements the new virtgpu commands and hooks them up to dma-buf's > get_uuid callback. > > Signed-off-by: David Stevens <stevensd at chromium.org> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++
2020 Mar 04
0
[PATCH v2 4/4] drm/virtio: Support virtgpu exported resources
Hi, > + if (vgdev->has_resource_assign_uuid) { > + spin_lock(&vgdev->resource_export_lock); > + if (bo->uuid_state == UUID_NOT_INITIALIZED) { > + bo->uuid_state = UUID_INITIALIZING; > + needs_init = true; > + } > + spin_unlock(&vgdev->resource_export_lock); > + > + if (needs_init) { > + ret =
2020 Aug 18
0
[PATCH v6 0/3] Support virtio cross-device resources
On Tue, Aug 18, 2020 at 10:37:41AM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1]. It will be used to import virtio resources into > the virtio-video driver currently under discussion [2]. The patch > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this
2020 May 28
0
[PATCH v4 0/3] Support virtio cross-device resources
On Tue, May 26, 2020 at 07:58:08PM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1]. It will be used to import virtio resources into > the virtio-video driver currently under discussion [2]. The patch > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this
2020 Jun 09
0
[PATCH v5 0/3] Support virtio cross-device resources
On Tue, Jun 09, 2020 at 10:25:15AM +0900, David Stevens wrote: > This patchset implements the current proposal for virtio cross-device > resource sharing [1]. It will be used to import virtio resources into > the virtio-video driver currently under discussion [2]. The patch > under consideration to add support in the virtio-video driver is [3]. > It uses the APIs from v3 of this
2020 Mar 04
0
[virtio-dev] [PATCH v2 4/4] drm/virtio: Support virtgpu exported resources
On Tue, Mar 03, 2020 at 11:42:22AM +0900, David Stevens wrote: > > cmd_p->hdr.ctx_id = > > > > Before this completion of this hypercall, this resource can be > > considered context local, while afterward it can be considered > > "exported". > > Maybe I'm misunderstanding render contexts, but exporting a resource > doesn't seem related to
2015 Jun 16
0
[PATCH 2/3] drm/virtgpu: initialise fbdev after getting initial display info
From: Dave Airlie <airlied at redhat.com> This should avoid issues with the fbdev path trying to render before we've gotten the display info. Signed-off-by: Dave Airlie <airlied at redhat.com> [ kraxel: wait for display-info reply ] Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c | 4
2015 Jun 16
0
[PATCH 2/3] drm/virtgpu: initialise fbdev after getting initial display info
From: Dave Airlie <airlied at redhat.com> This should avoid issues with the fbdev path trying to render before we've gotten the display info. Signed-off-by: Dave Airlie <airlied at redhat.com> [ kraxel: wait for display-info reply ] Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_kms.c | 4
2020 Mar 05
0
[PATCH 19/22] drm/virtgpu: Use simple encoder
The virtgpu driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/virtio/virtgpu_display.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c index
2020 Aug 05
1
[PATCH v3 34/38] drm/virtio: convert to LE accessors
Virtgpu is modern-only. Use LE accessors for config space. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_kms.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 0a5c8cf409fb..4d944a0dff3e 100644 ---
2020 Sep 15
0
[PATCH v2 17/21] drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
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 <tzimmermann at suse.de> --- drivers/gpu/drm/virtio/virtgpu_drv.c | 1 - drivers/gpu/drm/virtio/virtgpu_object.c | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or %lu format string, which does not work correctly on all architectures and causes this compiler warning on ARM: drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or %lu format string, which does not work correctly on all architectures and causes this compiler warning on ARM: drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str': drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2017 Mar 01
2
[PATCH] drm: virtio: use kmem_cache
Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
2017 Mar 01
2
[PATCH] drm: virtio: use kmem_cache
Just use kmem_cache instead of rolling our own, limited implementation. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +-- drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++++++----------------------------- 2 files changed, 11 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
2023 Feb 28
2
[PATCH v3] drm/virtio: Add option to disable KMS support
Hi Am 27.02.23 um 19:15 schrieb Rob Clark: > On Mon, Feb 27, 2023 at 9:57 AM Dmitry Osipenko > <dmitry.osipenko at collabora.com> wrote: >> >> On 2/27/23 20:38, Rob Clark wrote: >> ... >>> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) { >>> + /* get display info */ >>> + virtio_cread_le(vgdev->vdev, struct
2016 Nov 09
3
BUG: 'list_empty(&vgdev->free_vbufs)' is true!
On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at
2016 Nov 09
3
BUG: 'list_empty(&vgdev->free_vbufs)' is true!
On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at