Lines Matching refs:USB

1 How USB works with driver model
7 Driver model USB support makes use of existing features but changes how
9 understand how things work with USB in U-Boot when driver model is enabled.
12 Enabling driver model for USB
15 A new CONFIG_DM_USB option is provided to enable driver model for USB. This
16 causes the USB uclass to be included, and drops the equivalent code in
25 as drivers in the USB uclass. For example:
63 in USB device mode (OTG operation). It can be omitted if that is not
72 set up the USB controllers from board init code. When 'usb start' is used,
94 	as a work-around for controllers which can act as USB devices in OTG
112 USB buses
117 root hub attached to it. This hub, which is itself a USB device, can provide
123 and from there the devices are numbered in sequence. The USB uclass takes
126 USB devices are enumerated by finding a device on a particular hub, and
127 setting its address to the next available address. The USB bus stretches out
137 Up to 127 devices can be on each bus. USB has four bus speeds: low
144 USB operations
148 like. These are now implemented by the USB uclass and route through the
153 properly. Having said that, the USB device which should receive the message
168 USB Devices
171 USB devices are found using a simple algorithm which works through the
179 The enumeration process needs to work out which driver to attach to each USB
182 with USB devices - you can use the USB_DEVICE() macro to declare a USB
184 devices, and it will be used for all USB devices which match.
191 It is useful to understand precisely how a USB bus is enumerating to avoid
192 confusion when dealing with USB devices.
215 - usb_find_and_bind_driver() searches all available USB drivers (declared
228 - the first probe step is actually the USB controller's (or USB hubs's)
231 USB this calls usb_child_pre_probe() which grabs the information that was
239 - at this point the device is set up and ready for use so far as the USB
269 - most logic is in the USB controller and hub uclasses; the actual device
270 drivers do not need to know they are on a USB bus, at least so far as
278 USB hubs are scanned as in the section above. While hubs have their own
283 - they both use usb_child_pre_probe() to set up their children as proper USB
290 As an example of a USB device driver, see usb_storage.c. It uses its own
312 When usb_find_and_bind_driver() is called on a USB device with the
317 Counter-example: USB Ethernet
321 is scanned, all Ethernet devices will be created as generic USB devices (in
327 In fact, usb_ether should be moved to driver model. Each USB Ethernet driver
329 that it will be found as part of normal USB enumeration. Then, instead of a
330 generic USB driver, a real (driver-model-aware) driver will be used. Since
338 All driver model uclasses must have tests and USB is no exception. To
339 achieve this, a sandbox USB controller is provided. This can make use of
340 emulation drivers which pretend to be USB devices. Emulations are provided
341 for a hub and a flash stick. These are enough to create a pretend USB bus
345 Tests in test/dm/usb.c make use of this feature. It allows much of the USB
385 USB device driver that talks to it.
391 It is pretty uncommon to have a large USB bus with lots of hubs on an
408 - Move the USB gadget framework to driver model
410 - Implement USB PHYs in driver model
411 - Work out a clever way to provide lazy init for USB devices