<div dir="ltr">Hello everyone,<br><br>(Thanks to Dan for letting me know my last email got corrupted :/ - resending it here)<div><br>Sincere apologies for chiming in a bit late here, but was off due to some health issues.<br><br>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.<br><br>On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis <<a href="mailto:afd@ti.com">afd@ti.com</a>> wrote:<br>><br>> On 1/21/19 5:22 AM, Brian Starkey wrote:<br>> > Hi,<br>> ><div>> > Sorry for being a bit sporadic on this. I was out travelling last week<br>> > with little time for email.<br>> ><br>> > On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:<br>> >> On 1/17/19 7:11 PM, Liam Mark wrote:<br>> >>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:<br>> >>><br><snip><br>> >>>>>>> Yeah.. that's certainly the theory. Are there any DMA-BUF<br>> >>>>>>> implementations which actually do that? I hear it quoted a lot,<br>> >>>>>>> because that's what the docs say - but if the reality doesn't match<br>> >>>>>>> it, maybe we should change the docs.<br>> >>>>>>><br>> >>>>>><br>> >>>>>> Do you mean on the userspace side? I'm not sure, seems like Android<br>> >>>>>> might be doing this wrong from what I can gather. From kernel side if<br>> >>>>>> you mean the "de-allocate the backing storage", we will have some cases<br>> >>>>>> like this soon, so I want to make sure userspace is not abusing DMA-BUF<br>> >>>>>> in ways not specified in the documentation. Changing the docs to force<br>> >>>>>> the backing memory to always be allocated breaks the central goal in<br>> >>>>>> having attach/map in DMA-BUF separate.<br>> ><br>> > Actually I meant in the kernel, in exporters. I haven't seen anyone<br>> > using the API as it was intended (defer allocation until first map,<br>> > migrate between different attachments, etc.). Mostly, backing storage<br>> > seems to get allocated at the point of export, and device mappings are<br>> > often held persistently (e.g. the DRM prime code maps the buffer at<br>> > import time, and keeps it mapped: drm_gem_prime_import_dev).<br>> ><br>><br>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)<br> - 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.<br>- from dma-buf PoV, ION is an exporter of dma-buf buffers, for its users that have specific requirements.<br><br>> I haven't either, which is a shame as it allows for some really useful<br>> management strategies for shared memory resources. I'm working on one<div>> such case right now, maybe I'll get to be the first to upstream one :)<br>><br>Yes, it would, and great that you're looking to be the first one to do it :)<br><br>> > I wasn't aware that CPU access before first device access was<br>> > considered an abuse of the API - it seems like a valid thing to want<br>> > to do.<br>> ><br>><br>> That's just it, I don't know if it is an abuse of API, I'm trying to get<br>> some clarity on that. If we do want to allow early CPU access then that<br>> seems to be in contrast to the idea of deferred allocation until first<br>> device map, what is supposed to backing the buffer if no devices have<br>> attached or mapped yet? Just some system memory followed by migration on<br>> the first attach to the proper backing? Seems too time wasteful to be<br>> have a valid use.<br>><br>> Maybe it should be up to the exporter if early CPU access is allowed?<br>><br>> I'm hoping someone with authority over the DMA-BUF framework can clarify<br>> original intentions here.<br>><br><br>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.</div><div><br></div><div>Hope this helps,</div><div>Sumit.</div><div><br></div></div></div></div>