forked from Minki/linux
2e27980e6e
In order to update the root port or TT's bandwidth interval table, we will need to keep track of a list of endpoints, per interval. That way we can easily know the new largest max packet size when we have to remove an endpoint. Add an endpoint list for each root port or TT structure, sorted by endpoint max packet size. Insert new endpoints into the list such that the head of the list always has the endpoint with the greatest max packet size. Only insert endpoints and update the interval table with new information when those endpoints are periodic. Make sure to update the number of active TTs when we add or drop periodic endpoints. A TT is only considered active if it has one or more periodic endpoints attached (control and bulk are best effort, and counted in the 20% reserved on the high speed bus). If the number of active endpoints for a TT was zero, and it's now non-zero, increment the number of active TTs for the rootport. If the number of active endpoints was non-zero, and it's now zero, decrement the number of active TTs. We have to be careful when we're checking the bandwidth for a new configuration/alt setting. If we don't have enough bandwidth, we need to be able to "roll back" the bandwidth information stored in the endpoint and the root port/TT interval bandwidth table. We can't just create a copy of the interval bandwidth table, modify it, and check the bandwidth with the copy because we have lists of endpoints and entries can't be on more than one list. Instead, we copy the old endpoint bandwidth information, and use it to revert the interval table when the bandwidth check fails. We don't check the bandwidth after endpoints are dropped from the interval table when a device is reset or freed after a disconnect, because having endpoints use less bandwidth should not push the bandwidth usage over the limits. Besides which, we can't fail a device disconnect. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
||
---|---|---|
.. | ||
atm | ||
c67x00 | ||
class | ||
core | ||
dwc3 | ||
early | ||
gadget | ||
host | ||
image | ||
misc | ||
mon | ||
musb | ||
otg | ||
renesas_usbhs | ||
serial | ||
storage | ||
wusbcore | ||
Kconfig | ||
Makefile | ||
README | ||
usb-skeleton.c |
To understand all the Linux-USB framework, you'll use these resources: * This source code. This is necessarily an evolving work, and includes kerneldoc that should help you get a current overview. ("make pdfdocs", and then look at "usb.pdf" for host side and "gadget.pdf" for peripheral side.) Also, Documentation/usb has more information. * The USB 2.0 specification (from www.usb.org), with supplements such as those for USB OTG and the various device classes. The USB specification has a good overview chapter, and USB peripherals conform to the widely known "Chapter 9". * Chip specifications for USB controllers. Examples include host controllers (on PCs, servers, and more); peripheral controllers (in devices with Linux firmware, like printers or cell phones); and hard-wired peripherals like Ethernet adapters. * Specifications for other protocols implemented by USB peripheral functions. Some are vendor-specific; others are vendor-neutral but just standardized outside of the www.usb.org team. Here is a list of what each subdirectory here is, and what is contained in them. core/ - This is for the core USB host code, including the usbfs files and the hub class driver ("khubd"). host/ - This is for USB host controller drivers. This includes UHCI, OHCI, EHCI, and others that might be used with more specialized "embedded" systems. gadget/ - This is for USB peripheral controller drivers and the various gadget drivers which talk to them. Individual USB driver directories. A new driver should be added to the first subdirectory in the list below that it fits into. image/ - This is for still image drivers, like scanners or digital cameras. ../input/ - This is for any driver that uses the input subsystem, like keyboard, mice, touchscreens, tablets, etc. ../media/ - This is for multimedia drivers, like video cameras, radios, and any other drivers that talk to the v4l subsystem. ../net/ - This is for network drivers. serial/ - This is for USB to serial drivers. storage/ - This is for USB mass-storage drivers. class/ - This is for all USB device drivers that do not fit into any of the above categories, and work for a range of USB Class specified devices. misc/ - This is for all USB device drivers that do not fit into any of the above categories.