Hi David,
Thanks a lot for your detailed answer!
David Brownell wrote:
> On Tuesday 09 January 2007 8:27 am, Patrik Nagel wrote:
>
>> Hi,
>>
>> I'm writing an USB Video Class Driver (UVC) to use the DaVinci EVM
>> (1.10) as a video class device (camera). The UVC driver is based on the
>> gadget zero skeleton (USB Gadget API for Linux).
>>
>
> You'll also want to see how the CDC Ethernet driver works. Its
> altsetting support is a bit ugly, but for UVC you'll need several
> of those (one altsetting for each bandwidth/encoding).
>
I will have a look at the CDC Ethernet driver.
> Presumably you're using the MontaVista kernel because it has better
> video support? Be aware that the GIT tree (2.6.19-rc3, last updated
> in early November...) has much more current USB support ... more or
> less matching what's in the Nokia 800, which is different silicon.
> (But both DaVinci and the TUSB6010 have nasty DMA issues.) You should
> be able use that peripheral side code on the older kernels, but the
> host side has been substantially reworked.
>
Currently, I do not rely on the video support of the MontaVista kernel.
So I can use the 2.6.19-rc3 with better USB support. Anyway, I built a
"dual boot system" for the DVEVM with both kernel versions.
> In any case, I don't know that anyone's actually tried to use ISO
> transfers with that driver yet. I certainly haven't.
>
That lets me sleep better ;)
>> I'm also able to activate the
>> iso endpoint (alternate setting changes to one) or rather the DVEVM
>> starts streaming of video data. But the video software on the XP host
>> does not show any (moving) picture.
>>
>
> How are you connecting the video capture data on DaVinci to the ISO-IN
> data stream? Presumably you're starting with sending test patterns;
> moving imagery would come after that's known to work...
>
I have already transmitted successfully test patterns. I just toggled
between two colors (memset(..) in the reinit_write_data() function) and
filled the usb request buffer with it. The XP host did display the
alternating colors.
In a next step I want to stream video data from a stored video file.
Therefore I wrote a simple user space application, which opens the UVC
driver and allocates space by means of mmap. So that the allocated space
is accessible form both, the user and kernel space. Additionally, the
user space app opens the video file and reads continuously the needed
packets of 640 bytes into the allocated buffer (I did some "ugly"
synchronization..). That's what I did and is described in the posting
before.
I'm new to the linux driver programming, so is this the right way to
stream the file to the UVC driver? What kind of collection (fifo queue)
should I implement to avoid buffer underruns respectively how do I
implement that buffered synchronization between the user space app and
the kernel space driver? Named pipes? Code Example?
> What looks strange is those "underrun" errors. Your endpoint setup
> is probably wrong, unless you defined a new "fifo_mode":
>
> - maxpacket 642 means 512 bytes not enough, use 1024 byte hw maxpacket
> - this is ISO at 1 packet per uframe, you "must" use double buffering
>
> Which ties up 2KB of the 4 KB available on DaVinci. You might try
> enabling something like
>
> /* mode 5 - fits in 4KB, handles QVGA 16-bit uncompressed video */
> static const struct fifo_cfg __devinitdata mode_0_cfg[] = {
> { .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },
> { .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },
> { .hw_ep_num = 2, .style = FIFO_RXTX, .maxpacket = 512, },
> { .hw_ep_num = 3, .style = FIFO_RXTX, .maxpacket = 256, },
> { .hw_ep_num = 4, .style = FIFO_RXTX, .maxpacket = 1024, .mode = BUF_DOUBLE,
> },
> };
>
> and verify that your IN endpoint is using ep4 ... if you're using ep2 in
> the standard config, that reflects a bug somewhere (hardware maxpacket of
> 512, you're asking for 642, that doesn't fit!) that it got that far.
>
I have already configured an endpoint with a maxpacket of 1024 byte and
it gets assigned to the iso IN endpoint. I haven't tried yet the double
buffering mode, but will do that.
> Another part of that is software setup, and that's a place where
> gadget zero is at least sub-optimal ... it only queues one buffer
> at a time. With hardware double buffering, that might be able to
> work; but I think you'd be much better off queueing more packets,
> just in case whatever activity is feeding them is preempted for
> some reason.
>
Ok, I will try to queuing more packets. See my questions about that above.
> Also, be nice to yourself and turn off DMA at first. On DaVinci,
> that CPPI DMA controller is a real pain in the butt; and while it
> ought to handle ISO streams nicely, its design flaws are painful
> and the driver hasn't used it in that mode yet. Best to get your
> driver to work right first, THEN try for speed.
>
DMA is already turned off.
regards
Patrik
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
