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

[Laurent P. <lau...@sk...>]

> 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