[PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

[Sumit Semwal]

Hello everyone,

(Thanks to Dan for letting me know my last email got corrupted :/ -
resending it here)

Sincere apologies for chiming in a bit late here, but was off due to some
health issues.

Also, adding Daniel Vetter to the mix, since he has been one of the core
guys who shaped up dma-buf as it is today.

On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis <afd at ti.com> wrote:
>
> On 1/21/19 5:22 AM, Brian Starkey wrote:
> > Hi,
> >
> > Sorry for being a bit sporadic on this. I was out travelling last week
> > with little time for email.
> >
> > On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
> >> On 1/17/19 7:11 PM, Liam Mark wrote:
> >>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >>>
<snip>
> >>>>>>> Yeah.. that's certainly the theory. Are there any DMA-BUF
> >>>>>>> implementations which actually do that? I hear it quoted a lot,
> >>>>>>> because that's what the docs say - but if the reality doesn't
match
> >>>>>>> it, maybe we should change the docs.
> >>>>>>>
> >>>>>>
> >>>>>> Do you mean on the userspace side? I'm not sure, seems like Android
> >>>>>> might be doing this wrong from what I can gather. From kernel side
if
> >>>>>> you mean the "de-allocate the backing storage", we will have some
cases
> >>>>>> like this soon, so I want to make sure userspace is not abusing
DMA-BUF
> >>>>>> in ways not specified in the documentation. Changing the docs to
force
> >>>>>> the backing memory to always be allocated breaks the central goal
in
> >>>>>> having attach/map in DMA-BUF separate.
> >
> > Actually I meant in the kernel, in exporters. I haven't seen anyone
> > using the API as it was intended (defer allocation until first map,
> > migrate between different attachments, etc.). Mostly, backing storage
> > seems to get allocated at the point of export, and device mappings are
> > often held persistently (e.g. the DRM prime code maps the buffer at
> > import time, and keeps it mapped: drm_gem_prime_import_dev).
> >
>
I suppose some clarification on the 'intended use' part of dma-buf about
deferred allocation is due, so here it is: ( Daniel, please feel free to
chime in with your opinion here)
 - dma-buf was of course designed as a framework to allow intelligent
exporters to defer allocation until first map, and be able to migrate
backing storage if required etc. At the same time, it is not a
_requirement_ from any exporter, so exporters so far have just used it as a
convenient mechanism for zero-copy.
- from dma-buf PoV, ION is an exporter of dma-buf buffers, for its users
that have specific requirements.

> I haven't either, which is a shame as it allows for some really useful
> management strategies for shared memory resources. I'm working on one
> such case right now, maybe I'll get to be the first to upstream one :)
>
Yes, it would, and great that you're looking to be the first one to do it :)

> > I wasn't aware that CPU access before first device access was
> > considered an abuse of the API - it seems like a valid thing to want
> > to do.
> >
>
> That's just it, I don't know if it is an abuse of API, I'm trying to get
> some clarity on that. If we do want to allow early CPU access then that
> seems to be in contrast to the idea of deferred allocation until first
> device map, what is supposed to backing the buffer if no devices have
> attached or mapped yet? Just some system memory followed by migration on
> the first attach to the proper backing? Seems too time wasteful to be
> have a valid use.
>
> Maybe it should be up to the exporter if early CPU access is allowed?
>
> I'm hoping someone with authority over the DMA-BUF framework can clarify
> original intentions here.
>

I suppose dma-buf as a framework can't know or decide what the exporter
wants or can do - whether the exporter wants to use it for 'only
zero-copy', or do some intelligent things behind the scene, I think should
be best left to the exporter.

Hope this helps,
Sumit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190123/19cf9d76/attachment.html>