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).
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.
In any case, I don't know that anyone's actually tried to use ISO
transfers with that driver yet. I certainly haven't.
BTW I think that N800 would also make a good platform for this kind
of video streaming ... it's got a video camera, and is a lot more
accessible to random developers than a DaVinci EVM. :)
> I have configured an isochronous in-endpoint with a payload size of 642
> byte [1]. The Video Class Device (DVEVM) gets correctly recognized when
> connected via USB to a Windows XP host.
That's a good milestone! Getting all the USB descriptors straight for
such a device could be confusing.
> 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...
> [UVC driver code debugging]
> I added some "printk's" in the reinit_write_data(..) function, which is
> called when a request completes. These kernel messages show me
> respectively the first then bytes of every microframe which are passed
> to the buffer (req->buf). If I understood things correctly this should
> be done every 125us [1] in our case. The mentioned kernel messages seems
> to be right on the DVEVM. In addition, the manually set header toggles
> every 240 [1] microframes to indicate the end of a video frame. To sum
> up, the generated stream (from a video file) respectively the packed
> microframes show up as expected.
I don't know USB video, but that sounds plausible.
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.
What you want to happen is that your driver loads one microframe's
data into one fifo while the USB host is unloading the previous
microframe's data, so that there's never a situation where the host
asks for data and nothing is in the fifo ("underrun").
One part of that is correct hardware setup ... sketched above.
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.
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.
> But what I see on the screen isn't what I receive on the XP host or I
> would see at least a picture (or the complete video stream). This
> assumption is confirmed by using a USB Sniffer-Tool on the XP host[3]; A
> microframe of 642 bytes is received, but gets repeated afterwards many
> times [3] before the payload changes.
If the hardware was misconfigured (see above) I could believe all kinds
of nastiness would show up.
- Dave
> Additionally, I added the dmesg debug output [2a, 2b].
>
> Any help or direction are much appreciated.
>
> Thanks in advance!
> Patrik
>
>
> [1]
> -YUV 4:2:2 format with 30 frames / sec
> -Videoframesize: 320*240*16Bit (uncompressed)
> -bInterval ("sampling rate") is set to one -> 125us -> 8000 microframes
> per second
> -8000/30fps = 266 Microframes/Videoframe
> => 240 microframes per packet with payload of 640 byte + 2 byte header
> => 16 zero length frames
> => High-Speed transfer is sufficient
High speed had *better* be sufficient!!
> [2a]
> Output dmesg with original kernel 2.6.10_mvl401-davinci_evm:
> musb_gadget_queue 947: <== to ep2in request=c673a960
> txstate 228: hw_ep2, maxpacket 642, fifo count 642, txcsr 6004
> musb_write_fifo 276: TX ep2 fifo c805e428 count 642 buf c6727c00
> txstate 303: ep2in TX/IN pio len 642/642, txcsr 6007, fifo 642/642
> musb_interrupt 1375: <== IRQ peripheral usb0000 tx0004 rx0000
> musb_g_tx 323: <== ep2in, txcsr 6004
> musb_g_tx 349: underrun on ep2, req c673a960
> musb_g_giveback 129: ep2in done request c673a960, 642/642
> musb_gadget_queue 947: <== to ep2in request=c673a960
> txstate 228: hw_ep2, maxpacket 642, fifo count 642, txcsr 6004
> musb_write_fifo 276: TX ep2 fifo c805e428 count 642 buf c6727c00
> txstate 303: ep2in TX/IN pio len 642/642, txcsr 6007, fifo 642/642
> musb_interrupt 1375: <== IRQ peripheral usb0000 tx0004 rx0000
> musb_g_tx 323: <== ep2in, txcsr 6004
> musb_g_tx 349: underrun on ep2, req c673a960
> musb_g_giveback 129: ep2in done request c673a960, 642/642
>
> [2b]
> Output dmesg with kernel 2.6.19-rc3-omap1 from git:
> musb_gadget_queue 1162: <== to ep2in request=c7587520
> txstate 280: hw_ep2, maxpacket 642, fifo count 642, txcsr 6004
> musb_write_fifo 242: TX ep2 fifo c805e428 count 642 buf ff6c2000
> txstate 388: ep2in TX/IN pio len 642/642, txcsr 6000, fifo 642/642
> musb_interrupt 1327: ** IRQ peripheral usb0000 tx0004 rx0000
> musb_g_tx 408: <== ep2in, txcsr 6000
> musb_g_giveback 142: ep2in done request c7587520, 642/642
> musb_gadget_queue 1162: <== to ep2in request=c7587520
> txstate 280: hw_ep2, maxpacket 642, fifo count 642, txcsr 6004
> musb_write_fifo 242: TX ep2 fifo c805e428 count 642 buf ff6c2000
> txstate 388: ep2in TX/IN pio len 642/642, txcsr 6000, fifo 642/642
> musb_interrupt 1327: ** IRQ peripheral usb0000 tx0004 rx0000
> musb_g_tx 408: <== ep2in, txcsr 6000
> musb_g_giveback 142: ep2in done request c7587520, 642/642
>
> [3]
> "Complete" trace:
> http://www.anduril.ch/utlog.rar -> unzipped : 128Mb
>
> "Shrinked" trace:
> http://www.anduril.ch/utlog_small.rar -> unzipped: 7Mb
>
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
