Brutkey

R
@r@glauca.space

huh, reading the OHCI spec and we're finally starting to understand why "... and then there's isochronous" is a thing

while the packets aren't too different and many lower-end device controller IPs don't treat them that differently, apparently OHCI requires doing a whole Separate Thing for them

R
@r@glauca.space

which frustrated hardware/driver engineer caused this paragraph to be added to the spec?

Screenshot of the USB OHCI specification. The following paragraph is highlighted: However, if SchedulingOverrun errors persist for 32759 consecutive frames, then stale Isochronous Transfer Descriptors in the periodic list can look like Isochronous Transfer Descriptors that are scheduled for later delivery (this may not appear serious, but transmitting an isochronous packet in any but its assigned frame can cause serious problems, not to mention that any packet status words that may have been written may be mistaken by the Host Controller as buffer offsets, causing even more problems).