On Tue, 24 Mar 2015, Peter Chen wrote: > On Mon, Mar 23, 2015 at 10:11:04AM -0400, Alan Stern wrote: > > On Mon, 23 Mar 2015, Peter Chen wrote: > > > > > For going on debugging this problem, we need > > > > I will have the hardware only for one more day, so I may not be able to > > get all the information you want. > > > > > - Your bus analyzer file, I think there should be no enough IN/OUT > > > tokens within one frame, does the remaining time to frame boundaries > > > is enough? > > > > Here's an example: There are four OUT transfers near the start of the > > frame, and they take about 300 us. The remaining 700 us in the frame > > are completely idle, even though they should contain four IN transfers. > > How do you know the frame has filled already at that time? The software > makes sure it fills frame in time before next time frame? I'm not sure I understand the question. The USB analyzer log showed something like this (this is a rough approximation because I didn't keep the original analyzer output file): Timestamp Transaction s.mmm uuu ----------------------------------- 0.000 000 SOF 0.000 030 Isoc OUT 0.000 091 Isoc OUT 0.000 162 Isoc OUT 0.000 224 Isoc OUT 0.001 000 SOF In this example, there are 4 OUT transfers taking about 290 us and then nothing else for the rest of the frame. I also know, from looking at the "periodic" file in the EHCI debugfs directory, that each frame was linked to 8 siTDs: siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x01, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD OUT, Smask = 0x02, Cmask = 0x00, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x04, Cmask = 0x70, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 siTD IN, Smask = 0x08, Cmask = 0xe0, transfer length = 64 Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
