Hello,

On 2014-03-17 20:49, Jan Kara wrote:

The following patch series is my first stab at abstracting vma handling from the various media drivers. After this patch set drivers have to know much less details about vmas, their types, and locking. My motivation for the series is that I want to change get_user_pages() locking and I want to handle subtle locking details in as few places as possible.

The core of the series is the new helper get_vaddr_pfns() which is given a virtual address and it fills in PFNs into provided array. If PFNs correspond to normal pages it also grabs references to these pages. The difference from get_user_pages() is that this function can also deal with pfnmap, mixed, and io mappings which is what the media drivers need.

The patches are just compile tested (since I don't have any of the hardware I'm afraid I won't be able to do any more testing anyway) so please handle with care. I'm grateful for any comments.

Thanks for posting this series! I will check if it works with our hardware soon. This is something I wanted to introduce some time ago to simplify buffer handling in dma-buf, but I had no time to start working.

However I would like to go even further with integration of your pfn vector idea. This structure looks like a best solution for a compact representation of the memory buffer, which should be considered by the hardware as contiguous (either contiguous in physical memory or mapped contiguously into dma address space by the respective iommu). As you already noticed it is widely used by graphics and video drivers.

I would also like to add support for pfn vector directly to the dma-mapping subsystem. This can be done quite easily (even with a fallback for architectures which don't provide method for it). I will try to prepare rfc soon. This will finally remove the need for hacks in media/v4l2-core/videobuf2-dma-contig.c

Thanks for motivating me to finally start working on this!

Best regards