[PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2

[Mauro Carvalho Chehab]

Em 20-04-2012 09:25, Tomasz Stanislawski escreveu:
> Hi Remi,

>> Now, I do realize that some devices cannot support USERPTR efficiently,
>> then they should not support USERPTR. 
> 
> The problem is not there is *NO* device that can handle USERPTR reliably.
> The can handle USERPTR generated by malloc or page cache (not sure).
> Memory mmaped from other devices, frameworks etc may or may not work.
> Even if the device has its IOMMU the DMA layer provides no generic way to
> transform from one device to the mapping in some other device.
> 
> It is done using platform-defendant hacks like extracting PFNs from mappings,
> hack-forming them into struct pages or scatterlists, mapping it and hoping
> that the memory is not going to release it in some other thread.
> 
> The only sure way is to copy data from userptr to MMAP buffer.

All you're talking about is related to userptr abuse that happened
on Embedded devices, of using it for something that were never
meant to be used (dev2dev).

While the DMABUF patches aren't applied, there's just one mode defined
at the V4L2 API for dev2dev: overlay mode[1].

Most embedded applications and drivers decided that, instead of using
overlay mode, to abuse of userptr to do dev2dev. As you've pointed,
it was noticed in practice that this sometimes fail.

Yes, such abuse should be dropped, and DMABUF is the right way to
address it.

That doesn't mean that USERPTR should be dropped for the thing it were
originally created: dev2user or user2dev.

Regards,
Mauro

[1] Even so, not all PC motherboards are capable of supporting the overlay mode:
it is known that several chipsets have problems on their DMA engines, 
with causes data losses when a DMA transfer happens without passing through 
the system main memory (PCI2PCI transfers). So, drivers check the PCI quirks 
table to detect if dev2dev is supported, before exposing overlay mode to
userspace.