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

[Hans Verkuil <hverkuil@xs4all.nl>]

On 04/11/2014 12:18 AM, Jan Kara wrote:
> On Thu 10-04-14 23:57:38, Jan Kara wrote:
>> On Thu 10-04-14 14:22:20, Hans Verkuil wrote:
>>> On 04/10/14 14:15, Jan Kara wrote:
>>>> On Thu 10-04-14 13:07:42, Hans Verkuil wrote:
>>>>> On 04/10/14 12:32, Jan Kara wrote:
>>>>>>   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?
>>>>>
>>>>> You can use the vivi driver (drivers/media/platform/vivi) for this.
>>>>> However, while the vivi driver can import dma buffers it cannot export
>>>>> them. If you want that, then you have to use this tree:
>>>>>
>>>>> http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vb2-part4
>>>>   Thanks for the pointer that looks good. I've also found
>>>> drivers/media/platform/mem2mem_testdev.c which seems to do even more
>>>> testing of the area I made changes to. So now I have to find some userspace
>>>> tool which can issue proper ioctls to setup and use the buffers and I can
>>>> start testing what I wrote :)
>>>
>>> Get the v4l-utils.git repository (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/).
>>> You want the v4l2-ctl tool. Don't use the version supplied by your distro,
>>> that's often too old.
>>>
>>> 'v4l2-ctl --help-streaming' gives the available options for doing streaming.
>>>
>>> So simple capturing from vivi is 'v4l2-ctl --stream-mmap' or '--stream-user'.
>>> You can't test dmabuf unless you switch to the vb2-part4 branch of my tree.
>>   Great, it seems to be doing something and it shows there's some bug in my
>> code. Thanks a lot for help.
>   OK, so after a small fix the basic functionality seems to be working. It
> doesn't seem there's a way to test multiplanar buffers with vivi, is there?

For that you need to switch to the vb2-part4 branch as well. That has support
for multiplanar.

Regards,

	Hans