From: Sam Ravnborg <sam@ravnborg.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: linux-doc@vger.kernel.org, airlied@linux.ie,
dri-devel@lists.freedesktop.org, thierry.reding@gmail.com,
kraxel@redhat.com, afd@ti.com, m.szyprowski@samsung.com,
arnd@arndb.de, corbet@lwn.net, jonathanh@nvidia.com,
matthew.auld@intel.com, linux+etnaviv@armlinux.org.uk,
labbott@redhat.com, linux-media@vger.kernel.org,
pawel@osciak.com, intel-gfx@lists.freedesktop.org,
etnaviv@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
thomas.hellstrom@intel.com, rodrigo.vivi@intel.com,
linux-tegra@vger.kernel.org, mchehab@kernel.org,
gregkh@linuxfoundation.org, lmark@codeaurora.org,
tfiga@chromium.org, kyungmin.park@samsung.com,
robin.murphy@arm.com, christian.koenig@amd.com
Subject: Re: [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Date: Sun, 27 Sep 2020 21:16:05 +0200 [thread overview]
Message-ID: <20200927191605.GA237178@ravnborg.org> (raw)
In-Reply-To: <8761e0dd-569e-0ea0-7bc5-25e4f7cb67cc@suse.de>
Hi Thomas.
> >
> > struct simap {
> > union {
> > void __iomem *vaddr_iomem;
> > void *vaddr;
> > };
> > bool is_iomem;
> > };
> >
> > Where simap is a shorthand for system_iomem_map
> > And it could al be stuffed into a include/linux/simap.h file.
> >
> > Not totally sold on the simap name - but wanted to come up with
> > something.
>
> Yes. Others, myself included, have suggested to use a name that does not
> imply a connection to the dma-buf framework, but no one has come up with
> a good name.
>
> I strongly dislike simap, as it's entirely non-obvious what it does.
> dma-buf-map is not actually wrong. The structures represents the mapping
> of a dma-able buffer in most cases.
>
> >
> > With this approach users do not have to pull in dma-buf to use it and
> > users will not confuse that this is only for dma-buf usage.
>
> There's no need to enable dma-buf. It's all in the header file without
> dependencies on dma-buf. It's really just the name.
>
> But there's something else to take into account. The whole issue here is
> that the buffer is disconnected from its originating driver, so we don't
> know which kind of memory ops we have to use. Thinking about it, I
> realized that no one else seemed to have this problem until now.
> Otherwise there would be a solution already. So maybe the dma-buf
> framework *is* the native use case for this data structure.
We have at least:
linux/fb.h:
union {
char __iomem *screen_base; /* Virtual address */
char *screen_buffer;
};
Which solve more or less the same problem.
> Anyway, if a better name than dma-buf-map comes in, I'm willing to
> rename the thing. Otherwise I intend to merge the patchset by the end of
> the week.
Well, the main thing is that I think this shoud be moved away from
dma-buf. But if indeed dma-buf is the only relevant user in drm then
I am totally fine with the current naming.
One alternative named that popped up in my head: struct sys_io_map {}
But again, if this is kept in dma-buf then I am fine with the current
naming.
In other words, if you continue to think this is mostly a dma-buf
thing all three patches are:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-09-27 19:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 11:55 [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory Thomas Zimmermann
2020-09-25 11:55 ` [PATCH v3 1/4] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr Thomas Zimmermann
2020-09-25 11:55 ` [PATCH v3 2/4] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces Thomas Zimmermann
2020-09-25 11:56 ` [PATCH v3 3/4] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces Thomas Zimmermann
2020-09-25 11:56 ` [PATCH v3 4/4] dma-buf: Document struct dma_buf_map Thomas Zimmermann
2020-09-25 18:57 ` [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory Tomasz Figa
2020-09-26 7:13 ` Sam Ravnborg
2020-09-27 18:36 ` Thomas Zimmermann
2020-09-27 19:16 ` Sam Ravnborg [this message]
2020-09-28 6:50 ` Christian König
2020-09-28 7:37 ` Thomas Zimmermann
2020-09-28 11:22 ` Christian König
2020-09-29 9:14 ` Daniel Vetter
2020-09-29 11:09 ` Christian König
2020-09-29 11:14 ` Thomas Zimmermann
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=20200927191605.GA237178@ravnborg.org \
--to=sam@ravnborg.org \
--cc=afd@ti.com \
--cc=airlied@linux.ie \
--cc=arnd@arndb.de \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jonathanh@nvidia.com \
--cc=kraxel@redhat.com \
--cc=kyungmin.park@samsung.com \
--cc=labbott@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lmark@codeaurora.org \
--cc=m.szyprowski@samsung.com \
--cc=matthew.auld@intel.com \
--cc=mchehab@kernel.org \
--cc=pawel@osciak.com \
--cc=robin.murphy@arm.com \
--cc=rodrigo.vivi@intel.com \
--cc=tfiga@chromium.org \
--cc=thierry.reding@gmail.com \
--cc=thomas.hellstrom@intel.com \
--cc=tzimmermann@suse.de \
/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).