Hello,
On Thu 10-04-14 12:02:50, Marek Szyprowski wrote:
> 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.
Thanks for having a look in the series.
> 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
That would be a worthwhile thing to do. When I was reading the code this
seemed like something which could be done but I delibrately avoided doing
more unification than necessary for my purposes as I don't have any
hardware to test and don't know all the subtleties in the code... BTW, is
there some way to test the drivers without the physical video HW?
Honza
--
Jan Kara <j...@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
