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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
