On Tue, 27 Oct 2009, Sarah Sharp wrote:
> The EHCI specification says that an EHCI host controller may cache part of
> the isochronous schedule. The EHCI controller must advertise how much it
> caches in the schedule through the HCCPARAMS register isochronous
> scheduling threshold (IST) bits.
>
> In theory, adding new iTDs within the IST should be harmless. The HW will
> follow the old cached linked list and miss the new iTD. SW will notice HW
> missed the iTD and return 0 for the transfer length.
>
> However, Intel ICH9 chipsets (and some later chipsets) have issues when SW
> attempts to schedule a split transaction within the IST. All transfers
> will cease being sent out that port, and the drivers will see isochronous
> packets complete with a length of zero. Start of frames may or may not
> also disappear, causing the device to go into auto-suspend. This "bus
> stall" will continue until a control or bulk transfer is queued to a
> device under that roothub.
...
> /* Tried to schedule too far into the future? */
> - if (unlikely((start + sched->span) >= max)) {
> + if (unlikely(((start - now) & (mod - 1)) + sched->span
> + >= max - 2 * SCHEDULE_SLOP)) {
Small typo: That last line should read:
>= mod - 2 * SCHEDULE_SLOP)) {
With this change, the "max" variable is no longer used except in a
debugging printk, where it isn't needed. It can be eliminated
completely.
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
