Re: [RFC] Helper to abstract vma handling in media layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]