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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
