slhci(4) [netbsd man page]
SLHCI(4) BSD Kernel Interfaces Manual SLHCI(4) NAME
slhci -- Cypress/ScanLogic SL811HS USB Host Controller driver SYNOPSIS
PCMCIA (CF) controllers slhci* at pcmcia? function ? usb* at slhci? ISA controllers slhci* at isa? port ? irq ? usb* at slhci? x68k slhci0 at intio0 addr 0xece380 intr 251 slhci1 at intio0 addr 0xeceb80 intr 250 usb* at slhci? options SLHCI_TRY_LSVH DESCRIPTION
The slhci driver provides support for Cypress/ScanLogic SL811HS USB Host Controller. The driver supports control, bulk, and interrupt transfers but not isochronous (audio), which cannot be supported by this chip without per- fectly reliable 1ms interrupts. USB is polled and this chip requires the driver to initiate all transfers. The driver interrupts at least once every ms when a device is attached even if no data is transferred. The driver polls the chip when the transfer is expected to be com- pleted soon; with maximum use of the bus, the driver will not exit for most of each ms. Use of this driver can easily have a significant performance impact on any system. The chip is unreliable in some conditions, possibly due in part to difficulty meeting timing restrictions (this is likely to be worse on mul- tiprocessor systems). Unexpected device behavior may trigger some problems; power cycling externally powered devices may help resolve per- sistent problems. Detection of invalid chip state will usually cause the driver to halt, however is recommended that all data transfers be verified. Data corruption due to controller error will not be detected automatically. Unmounting and remounting a device is necessary to prevent use of cached data. The driver currently will start the next incoming packet before copying in the previous packet but will not copy the next outgoing packet before the previous packet is transferred. Reading or writing the chip is about the same speed as the USB bus, so this means that one outgo- ing transfer is half the speed of one incoming transfer and two outgoing transfers are needed to use the full available bandwidth. All revisions of the SL811HS have trouble with low speed devices attached to some (likely most) hubs. Low speed traffic via hub is not allowed by default, but can be enabled with options SLHCI_TRY_LSVH in the kernel config file or by setting the slhci_try_lsvh variable to non-zero using ddb(4) or gdb(1). Many USB keyboards have built in hubs and may be low speed devices. All USB mice I have seen are low speed devices, however a serial mouse should be usable on a hub with a full speed Serial-USB converter. A PS2-USB keyboard and mouse converter is likely to be a single low speed device. Some hardware using this chip does not provide the USB minimum 100mA current, which could potentially cause problems even with externally powered hubs. The system can allow excess power use in some other cases as well. Some signs of excess power draw may cause the driver to halt, however this may not stop the power draw. To be safe verify power use and availability before connecting any device. HARDWARE
Hardware supported by the slhci driver includes: Ratoc CFU1U Nereid Ethernet/USB/Memory board SEE ALSO
config(1), isa(4), pcmcia(4), usb(4) Cypress SL811HS datasheet, errata, and application note, http://www.cypress.com. HISTORY
The slhci driver appeared in NetBSD 2.0 and was rewritten in NetBSD 5.0. AUTHORS
Tetsuya Isaki <isaki@NetBSD.org> Matthew Orgass BSD
April 24, 2007 BSD
Check Out this Related Man Page
hubd(7D) hubd(7D) NAME
hubd - USB hub driver SYNOPSIS
hub@unit-address The hubd is a USBA (Solaris USB Architecture) compliant client driver that supports USB hubs conforming to the Universal Serial Bus Speci- fication 2.0. The hubd driver supports bus-powered and self-powered hubs. The driver supports hubs with individual port power, ganged power and no power switching. When a device is attached to a hub port, the hubd driver enumerates the device by determining its type and assigning an address to it. For multi-configuration devices, hubd sets the preferred configuration (refer to cfgadm_usb(1M) to select a configuration). The hubd driver attaches a driver to the device if one is available for the default or selected configuration. When the device is disconnected from the hub port, the hubd driver offlines any driver instance attached to the device. /kernel/drv/hubd 32- bit ELF kernel module /kernel/drv/amd64/hubd 64- bit ELF kernel module /kernel/drv/sparcv9/hubd 64-bit SPARC ELF kernel module See attributes(5) for a description of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Architecture |SPARC, , PCI-based systems | +-----------------------------+-----------------------------+ |Availability |SUNWusb | +-----------------------------+-----------------------------+ cfgadm_usb(1M), attributes(5), usba(7D) Writing Device Drivers Universal Serial Bus Specification 2.0 System Administration Guide: Basic Administration http://www.sun.com/io In addition to being logged, the following messages may also appear on the system console. Messages are formatted in the following manner: WARNING: <device path> <hubd<instance number>): Message... where <instance number> is the instance number of hubd and <device path> is the physical path to the device in /devices directory. Messages from the root hub are displayed with a usb<instance number> prefix instead of hub<instance number> as the root hub is an integrated part of the host controller. Connecting device on port <number> failed. The driver failed to enumerate the device connected on port <number> of hub. If enumeration fails, disconnect and re-connect. Use of a USB 1.0 hub behind a high speed port may cause unexpected failures. Devices connected to a USB 1.0 hub which are in turn connected to an external USB 2.0 hub, may misbehave unexpectedly or suddenly go offline. This is due to a documented incompatibility between USB 1.0 hubs and USB 2.0 hub Transaction Translators. Please use only USB 2.0 or USB 1.1 hubs behind high-speed ports. Connecting a high speed device to a non-high speed hub (port x) will result in a loss of performance. Please connect the device to a high speed port to get the maximum performance. USB 2.0 devices connected to USB 1.0 or 1.1 hubs cannot run at their highest speed, even when the hub is in turn connected to a high- speed port. For best performance, reconnect without going through a USB 1.0 or 1.1 hub. Cannot access <device>. Please reconnect. This hub has been disconnected because a device other than the original one has been inserted. The driver informs you of this fact by displaying the name of the original device. Devices not identical to the previous one on this port. Please disconnect and reconnect. Same condition as described above; however in this case, the driver is unable to identify the original device with a name string. Hub driver supports max of <n> ports on hub. Hence, using the first <number of physical ports> of <n> ports available. The current hub driver supports hubs that have <n> ports or less. A hub with more than <n> ports has been plugged in. Only the first <n> out of the total <number of physical ports> ports are usable. The following messages may be logged into the system log. They are formatted in the following manner: <device path> <hubd<instance number>): message... Global over current condition, please disconnect hub. The driver detected an over current condition. This means that the aggregate current being drawn by the devices on the downstream port exceeds a preset value. Refer to section 7.2.1.2 and 11.13 of the Universal Serial Bus Specification 2.0. You must remove and insert this hub to render it and its downstream devices functional again. If this message continues to display for a particular hub, you may need to remove downstream devices to eliminate the problem. Local power has been lost, please disconnect hub. A USB self-powered hub has lost external power. All USB devices connected down-stream from this hub will cease to function. Disconnect the hub, plug in the external power-supply and then plug in the hub again. Local power has been lost, the hub could draw <x> mA power from the USB bus. A USB self/bus-powered hub has lost external power. Some USB devices connected down-stream from this hub may cease to func- tion. Disconnect the external power-supply and then plug in the hub again. 20 June 2005 hubd(7D)