[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180920063201.nt7kw555s4clshzr@sirius.home.kraxel.org>
Date: Thu, 20 Sep 2018 08:32:01 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Jiandi An <jiandi@....com>
Cc: Dave Airlie <airlied@...il.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
"virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
Dave Airlie <airlied@...ux.ie>,
"open list:VIRTIO CORE, NET..."
<virtualization@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Lendacky, Thomas" <Thomas.Lendacky@....com>,
"Singh, Brijesh" <brijesh.singh@....com>
Subject: Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
Hi,
> void virtio_gpu_cmd_transfer_to_host_2d(struct virtio_gpu_device *vgdev,
> uint32_t resource_id, uint64_t offset,
> ...
> struct virtio_gpu_fbdev *vgfbdev = vgdev->vgfbdev;
> struct virtio_gpu_framebuffer *fb = &vgfbdev->vgfb;
> struct virtio_gpu_object *obj = gem_to_virtio_gpu_obj(fb->base.obj[0]);
Ah, right. Should have noticed this on review. You sync the fbcon
framebuffer unconfitionally ...
> Is there better way to get to the virtio_gpu_object created in the
> virtio_gpu_mode_dumb_create() path from virtio_gpu_device or somehow from drm_file
> via gem_handle down at the layer of virtio_gpu_cmd_transfer_to_host()?
Just pass it down, the call sites all know it (see patch just sent).
cheers,
Gerd
Powered by blists - more mailing lists