Hi Hans, On Wednesday 04 February 2015 12:39:30 Hans Verkuil wrote: > On 02/04/15 12:34, Laurent Pinchart wrote: > > On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: > >> On 04.02.2015 11:22, Hans Verkuil wrote: > >>> On 02/04/15 11:08, Florian Echtler wrote: > >>>> On 04.02.2015 09:08, Hans Verkuil wrote: > >>>>> You can also make a version with vmalloc and I'll merge that, and then > >>>>> you can look more into the DMA issues. That way the driver is merged, > >>>>> even if it is perhaps not yet optimal, and you can address that part > >>>>> later. > >>>> > >>>> OK, that sounds sensible, I will try that route. When using > >>>> videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? > >>> > >>> vmalloc doesn't need those, so you can just drop any alloc_ctx related > >>> code. > >> > >> That's what I assumed, however, I'm running into the same problem as > >> with dma-sg when I switch to vmalloc...? > > > > I don't expect vmalloc to work, as you can't DMA to vmalloc memory > > directly without any IOMMU in the general case (the allocated memory being > > physically fragmented). > > > > dma-sg should work though, but you won't be able to use usb_bulk_msg(). > > You need to create the URBs manually, set their sg and num_sgs fields and > > submit them. > > So it works for other usb media drivers because they allocate memory > using kmalloc (and presumably the usb core can DMA to that), and then memcpy > it to the vmalloc-ed buffers? Correct. In the uvcvideo case that's unavoidable as headers need to be removed from the packets. > Anyway Florian, based on Laurent's explanation I think trying to make > dma-sg work seems to be the best solution. And I've learned something > new :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
