When two controllers are attached to a physical port (e.g. in the
case of EHCI and its companion controllers, problems can occur if
the BIOS still has control of one controller when we try to use the
other one. So perform a first pass to scan the PCI bus and take
ownership of and reset all the controllers we find, and perform a
second pass to initialise the controllers and probe for attached
devices.
As we don't support hot plugging, split the second pass into two,
with the first probing the EHCI controllers and handing over any
low and full speed devices to the companion controllers, and the
second probing the remaining controller types.
* Add new heap manager.
* Convert OHCI driver to use new heap manager.
* Convert UHCI driver to use new heap manager.
* Convert EHCI driver to use new heap manager.
* Convert XHCI driver to use new heap manager.
* Convert SMP to use new heap manager.
* Add a "usbinit" boot option to handle various buggy USB devices.
This replaces the "keyboard=buggy-usb" option, and adds a second
workaround to handle the problem seen in issue #107.
Low and full speed USB devices that are attached directly to an EHCI port
have to be handled by a companion controller (either UHCI or OHCI). We hand
over ports when we detect a low or full speed device is attached by setting
the Port Owner bit in the Port Status and Control register. However some AMD
companion controllers fail to detect the device after this has been done.
Resetting the EHCI controller works around this quirk.
This fixes issue #6 and issue #71.
Previously every second transfer was dropped. We didn't notice, because
they were normally key release events, which we ignored anyway. However
the new keyboard report handler needs to see the release events.
A USB keyboard may return key codes in any of the 6 key code array
positions (issue #48). So we have to compare the latest report to
the previous one to detect new key presses and handle rollover. As
the same change is needed for all HCI types, factor out the common
code into the base driver.
Using Interrupt On Completion is not robust, because the interrupt flag
is also set if a short transfer is detected. So we need to poll the
Active flag in the transfer descriptors.
Low/full speed USB devices attached directly to the root hub must be
rerouted to a companion controller. We can't rely on the BIOS to do
this for us. This requires us to initialise the EHCI device before
initialising any of its companions.
This also allows us to support keyboards attached via a high speed
hub on a system with EHCI plus companions.
