linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Florian Echtler <floe@butterbrot.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Date: Wed, 21 Jan 2015 14:29:58 +0100	[thread overview]
Message-ID: <54BFA9D6.1040201@xs4all.nl> (raw)
In-Reply-To: <54BFA989.4090405@butterbrot.org>

On 01/21/15 14:28, Florian Echtler wrote:
> 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?

Easiest would actually be to copy all the videobuf2 sources and headers
to that older kernel.

Obviously, for upstreaming you should always use the latest APIs and
never use backwards-compatible constructs.

Regards,

	Hans


  reply	other threads:[~2015-01-21 13:31 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 10:35 [PATCH] add raw video support for Samsung SUR40 touchscreen Florian Echtler
2015-01-19 10:38 ` Hans Verkuil
2015-01-20  9:24   ` Florian Echtler
2015-01-20  9:30     ` Hans Verkuil
2015-01-20 12:59       ` Laurent Pinchart
2015-01-20 13:03         ` Hans Verkuil
2015-01-20 13:06           ` Laurent Pinchart
2015-01-21 13:28             ` Florian Echtler
2015-01-21 13:29               ` Hans Verkuil [this message]
2015-01-29 21:35                 ` Florian Echtler
2015-02-03 20:45                   ` Florian Echtler
2015-02-04  8:08                     ` Hans Verkuil
2015-02-04 10:08                       ` Florian Echtler
2015-02-04 10:22                         ` Hans Verkuil
2015-02-04 10:56                           ` Florian Echtler
2015-02-04 11:34                             ` Laurent Pinchart
2015-02-04 11:39                               ` Hans Verkuil
2015-02-04 13:21                                 ` Florian Echtler
2015-02-04 14:06                                   ` Laurent Pinchart
2015-02-04 13:51                                 ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54BFA9D6.1040201@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=floe@butterbrot.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).