From: Gerd Hoffmann <kraxel@redhat.com>
To: Gurchetan Singh <gurchetansingh@chromium.org>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>,
John Bates <jbates@chromium.org>
Subject: Re: [RFC PATCH 0/8] *** Refactor struct virtgpu_object ***
Date: Fri, 28 Feb 2020 11:28:10 +0100 [thread overview]
Message-ID: <20200228102810.wdrkt43oova7zib3@sirius.home.kraxel.org> (raw)
In-Reply-To: <CAAfnVB=hPaGUtq=w9X5DGnsCAAjMzP_dTNKQm-4hG5ORD=2r+A@mail.gmail.com>
Hi,
> > struct virtgpu_object {
>
> Yeah, using "virtgpu_" rather than "virtio_gpu" makes sense.
It wasn't my intention to suggest a rename. It's just that the kernel
is a bit inconsistent here and I picked the wrong name here. Most
places use virtio_gpu but some use virtgpu (file names, ioctl api).
> > struct virtgpu_object_hostmem {
> > struct virtgpu_object base;
> > {offset, range};
> > (...)
>
> I'm a kernel newbie, so it's not obvious to me why struct
> drm_gem_shmem_object would be a base class for struct
> virtgpu_object_hostmem?
I think it is easier to just continue using virtio_gpu_object in most
places and cast to virtio_gpu_object_{shmem,hostmem} only if needed.
Makes it easier to deal with common fields like hw_res_handle.
In the hostmem case we would simply not use the drm_gem_shmem_object
fields except for drm_gem_shmem_object.base (which is drm_gem_object).
> Side question: is drm_gem_object_funcs.vmap(..) /
> drm_gem_object_funcs.vunmap(..) even possible for hostmem?
Sure. Using ioremap should work, after asking the host to map the
object at some location in the pci bar.
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-02-28 10:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 0:25 [RFC PATCH 0/8] *** Refactor struct virtgpu_object *** Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 1/8] drm/virtio: make mmap callback consistent with callbacks Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 2/8] drm/virtio: add virtio_gpu_is_shmem helper Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 3/8] drm/virtio: add virtio_gpu_get_handle function Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 4/8] drm/virtio: make RESOURCE_UNREF use virtio_gpu_get_handle(..) Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 5/8] drm/virtio: make {ATTACH_RESOURCE, DETACH_RESOURCE} " Gurchetan Singh
2020-02-27 0:25 ` [RFC PATCH 6/8] drm/virtio: rename virtio_gpu_object_array to virtio_gpu_gem_array Gurchetan Singh
2020-02-27 0:26 ` [RFC PATCH 7/8] drm/virtio: rename virtio_gpu_object_params to virtio_gpu_create_params Gurchetan Singh
2020-02-27 0:26 ` [RFC PATCH 8/8] drm/virtio: rename virtio_gpu_object to virtio_gpu_shmem Gurchetan Singh
2020-02-27 7:23 ` [RFC PATCH 0/8] *** Refactor struct virtgpu_object *** Gerd Hoffmann
2020-02-28 2:03 ` Gurchetan Singh
2020-02-28 10:28 ` Gerd Hoffmann [this message]
2020-02-27 10:59 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200228102810.wdrkt43oova7zib3@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=jbates@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).