Re: [PATCH] add raw video support for Samsung SUR40 touchscreen

[Florian Echtler <floe@butterbrot.org>]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

Hello everyone,

On 20.01.2015 14:06, Laurent Pinchart wrote:
> On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
>> On 01/20/15 13:59, Laurent Pinchart wrote:
>>> On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
>>>> I've CC-ed Laurent, I think he knows a lot more about this than I do.
>>>>
>>>> Laurent, when does the USB core use DMA? What do you need to do on the
>>>> driver side to have USB use DMA when doing bulk transfers?
>>>
>>> How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
>>> exepct ehci-tegra, max3421-hcd and musb use the default implementation
>>> usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
>>>
>>> Unless the buffer has already been mapped by the USB driver (in which case
>>> the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
>>> urb->transfer_flags and initialized the urb->transfer_dma field), the
>>> function will use dma_map_sg(), dma_map_page() or dma_map_single()
>>> depending on the buffer type (controlled through urb->sg and
>>> urb->num_sgs). DMA will thus always be used *expect* if the platform uses
>>> bounce buffers when the buffer can't be mapped directly for DMA.
>>
>> So we can safely use videobuf2-vmalloc, right?
> 
> That depends on the platform and whether it can DMA to vmalloc'ed memory :-) 
> To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's 
> worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.

The SUR40 sends raw video data without any headers over the bulk
endpoint in blocks of 16k, so I'm assuming that in this specific case,
vb2-dma-sg would be the most efficient choice?

On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
only in 3.19. If I want to maintain a backwards-compatible version for
older kernels, what do I use in that case?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]