On 15.12.2014 23:34, Hans Verkuil wrote: > On 12/15/2014 11:15 PM, Florian Echtler wrote: >> On 15.12.2014 17:01, Hans Verkuil wrote: >>> On 12/15/2014 04:47 PM, Florian Echtler wrote: >>> Why on earth is sur40_poll doing anything with video buffers? That's >>> all handled by vb2. As far as I can tell you can just delete everything >>> from '// deal with video data here' until the end of the poll function. >> Right now, the code doesn't do anything, but I'm planning to add the >> actual data retrieval at this point later. I'd like to use the >> input_polldev thread for this, as a) the video data should be fetched >> synchronously with the input device data and b) the thread will be >> running continuously anyway. > Ah, now I see it. One additional question you might be able to answer: if I use vb2_dma_contig_init_ctx for the allocator context, will usb_bulk_msg with a vb2_buffer then automatically use DMA? I want to avoid unnecessary memcpy operations, so ideally the USB host controller should directly put the data into the buffer which is then passed to userspace. Does this require any additional setup? >>> But, as I said, that code doesn't belong there at all, so just remove it. >> See above - that was actually intentional. It's kind of a hackish >> solution, but for the moment, I'd just like to get a video stream with >> minimal overhead, so I'm reusing the polldev thread. > OK. If you are planning to upstream this driver, then this probably needs > another look. Once I get it working, I'll submit a patch for further discussion. Best, Florian -- SENT FROM MY DEC VT50 TERMINAL
Attachment:
signature.asc
Description: OpenPGP digital signature
