[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4561a2be-cc58-9e87-2a60-7d05a7e6f6df@tronnes.org>
Date: Wed, 27 Mar 2019 15:41:20 +0100
From: Noralf Trønnes <noralf@...nnes.org>
To: Gerd Hoffmann <kraxel@...hat.com>, dri-devel@...ts.freedesktop.org
Cc: Gurchetan Singh <gurchetansingh@...omium.org>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
"open list:VIRTIO GPU DRIVER"
<virtualization@...ts.linux-foundation.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 5/5] drm/virtio: rework resource creation workflow.
Den 18.03.2019 12.33, skrev Gerd Hoffmann:
> This patch moves the virtio_gpu_cmd_create_resource() call (which
> notifies the host about the new resource created) into the
> virtio_gpu_object_create() function. That way we can call
> virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
> already knows about the object when ttm initializes the object and calls
> our driver callbacks.
>
> Specifically the object is already created when the
> virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
> so the extra virtio_gpu_object_attach() calls done after
> virtio_gpu_object_create() are not needed any more.
>
> The fence support for the create ioctl becomes a bit more tricky though.
> The code moved into virtio_gpu_object_create() too. We first submit the
> (fenced) virtio_gpu_cmd_create_resource() command, then initialize the
> ttm object, and finally attach just created object to the fence for the
> command in case it didn't finish yet.
>
> Signed-off-by: Gerd Hoffmann <kraxel@...hat.com>
> ---
Acked-by: Noralf Trønnes <noralf@...nnes.org>
Powered by blists - more mailing lists