Re: [Linux-uvc-devel] rev 4 test with kernel smp Intel x86_64

[michel X. <mx...@ma...>]

Le Vendredi 6 Janvier 2006 11:59, Laurent Pinchart a écrit :
> > Laurent,
> > I am still trying to figure out where the corruption come from on the SMP
> > box. After some usefull uvc_printk() and moving some part of code from
> > uvc_video_decode() to uvc_video_complete() i can make MJPEG working or
> > not
> >
> > :( even if my code do nothing exept take the value in the iso desc buffer
> >
> > brr .
>
> Mmmmm... Sounds like a timing issue... I don't like those.
>
> > On each usb packet desc (data[0]) the first field reffer to the packet
> > header lenght ?
>
> (from the UVC specs)
>
> "Each Uncompressed frame is considered a single video sample. A video
> sample is made up of one or more payload transfers (as defined in the USB
> Device Class Specification for Video Devices).
>
> For an isochronous pipe, each (micro) frame will contain a single payload
> transfer. Each payload transfer will consist of a payload header
> immediately followed by payload data in one or more data transactions (up
> to 3 data transactions for high speed high bandwidth endpoints)."
>
> So each frame contains a header followed by data. The frame can span up to
> 3 data transactions, but that's handled by the USB layer and transparent
> for the driver.
>
> > with yuyv palette the stream start with that field set to 0
> > then toggle to 12 in the stream and  for a short  times ( ~2 usb packet)
> > goes to 0 when the packet length is full ? this feature only appear on
> > yuyv palette.
>
> That shouldn't happen. From my understanding of the spec, the header length
> should always be at least 2 (the HLE and BFH fields seem to be required,
> the PTS and SCR fields are optional).
>
> > On a UP box this field is constant and always egal to 12.
>
> That's how it should be.
>
> > I think we are not getting the right data from the urb buffer here :(
>
> Might... I'd like you to run the same tests on the SMP box with SMP
> disabled. I'd like to be sure it's not a USB controller issue. Which kernel
> version are you running ?
>
> > In my experiment i have get some good kernel crash :)  I suspect on
> > restart the last synchro bit in the queue is not reset or maybe my
> > grabber is wrong and need to dequeue all buffers on stop ?
>
> The synchro bit is reset on restart, but I had forgotten to mark the
> buffers as idle. This is fixed in svn.
>
> If the last packet of a frame is lost (which can happen with isochronous
> transfers), the EOF bit will not be seen and the FID bit will toggle on the
> next frame. The driver currently doesn't handle that properly, but it
> shouldn't result in a 0 header length. Try to print the second header byte
> as well (data[1]) as an hexadecimal number, and see if it tells you
> anything (have a look at USB_Video_Payload_Uncompressed_1.1.pdf to find the
> stream header description).
>
> Laurent Pinchart
Laurent,
http://mxhaard.free.fr/spca50x/Investigation/uvc/
messages.tar.gz from my /var/log/messages
first part MJPEG stream working
second part YUYV not working
I have also set here the uvc_video_complete() used for this record 
for a best understanding (without pass by indent sorry :))
The only difference from the original is i bypass when len <= data[0] as i did 
not want to fill all my harddrive :)
-- 
Michel Xhaard
http://mxhaard.free.fr