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