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