On 9/22/05, Charles Forsyth <[EMAIL PROTECTED]> wrote: > > EHCI is an extension to UHCI to enable a much greater degree of buffering > > it's an incompatible extension since asynchronous requests are no longer put > in the > frame list but go on a separate queue elsewhere, and the descriptors are > different; > it retains many of the annoying features though! > there are extra descriptors to handle the micro-frame intervals > that give the extra speed, and split transactions with the hubs. > the bizarre thing is that the EHCI controller handles only the high-speed > devices, not low-speed or full-speed ones (note that `full speed' is not > `high speed'). > you need a `companion controller' for the low-/full-speed devices, and that > controller can be either OHCI or UHCI. of course, that requires special > hardware > to route devices to one controller or another per root port, and new software > to manage the distribution of work between them. of course, the > implemenation > can choose from two possible routing schemes. there is an (optional) `light' > reset (distinguished from the usual `soft' reset). such fun! > >
All of this begins to remind me why I normally don't muck around in OS kernels. It's so really not fun or interesting to deal with the braindead-ness of hardware. There are people that get off on this stuff but it's not me. I'd rather drink my brains out.
