Hi, Alan,
> >
> > We found an issue with FS isochronous device that is connected to
the
> > USB host controller through an HS hub. This is on an embedded
PowerPC
> > platform using an FPGA-based USB host controller. This issue exists
for
> > both FS isochronous IN and OUT transfers behind an HS hub.
> >
> > The test setup is that the application submits 50 maxp 1 transfers,
with
> > polling interval 4ms. The periodic frame list has 256 elements. The
> > application submits 2 batches of transfers with 50 transfers each.
Other
> > FS isochronous tests fail too if connected through an HS hub.
>
> To make this clear: You've got 2 isochronous URBs, each URB contains
50
> packets (i.e., urb->number_of_packets is 50), and each packet
transfers
> 1 byte. Is that right?
>
Yes.
> > Using direct connection, the test passes fine. However, if connected
> > through an HS hub, there are less than 100 transfers happen on the
bus.
> >
> > What we found is that when connected through an HS hub, the periodic
> > schedule is enabled, and scan_periodic is called constantly.
>
> What do you mean by "constantly"? scan_periodic should be called only
> when an interrupt occurs, which should be only when one of those 2
URBs
> completes. Therefore scan_periodic should be called only twice.
>
Because the HS hub (FS hub also, although tests pass through FS hubs) is
connected to the host controller, therefore, periodic schedule is
enabled all the time. That is why scan_periodic is called constantly. I
think it comes from ehci_work().
> > Our trace
> > show that the mark of last scanned frame entry, ehci->next_uframe,
often
> > is the frame entry that software links a new sitd in, and when next
> > scan_periodic start, that sitd is considered as out of date and is
> > unlinked.
>
> That shouldn't happen. Let's say URB #1 makes its last transfer in
> uframe N. There should be an interrupt when that uframe ends, and at
> that time scan_periodic should run and should update ehci->next_uframe
> to N+1. Then URB #2 should be submitted, and it should start
> approximately in uframe N+32 (4 ms = 32 uframes later). Therefore the
> next sitd should not be linked into uframe N+1.
>
I do see that scan_periodic() updates now_uframe, and my prints (which
messed up all the timing therefore not much use) show that with HS hub,
often now_uframe is incremented over clock, at the end of the procedure,
inside else:
} else {
now_uframe++; /* this one sometimes pass over
clock without round up happening*/
now_uframe %= mod;
}
} /* end of for(;;) */
} /* end of scan_periodic() */
If that is true (which I will verify), then scan_periodic could scan
ahead of frame index. The potential reason for this to happen could be
the interrupt from HS hub transfers, which hardware trace showed that
the submitted sitd's are interrupted by HS hub interrupt, and missing
sitd's happened afterwards. Although, at this point, we are not sure why
it is so.
> > I wonder whether the test setting is correct?
>
> What test setting?
>
The test setting of submitting 50 packets a time. I do not see anything
is incorrect.
Thanks,
Julie.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
--
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
