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?
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
