Lines Matching +full:usb +full:- +full:c
1 How USB works with driver model
5 ------------
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
13 -----------------------------
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
17 usb.c. In particular the usb_init() function is then implemented by the
22 -------------------------
25 as drivers in the USB uclass. For example:
28 { .compatible = "nvidia,tegra20-ehci", .data = USB_CTLR_T20 },
29 { .compatible = "nvidia,tegra30-ehci", .data = USB_CTLR_T30 },
30 { .compatible = "nvidia,tegra114-ehci", .data = USB_CTLR_T114 },
54 most cases, since they are all EHCI-compatible. For EHCI there are also some
58 This can hold run-time information needed by the driver for operation. It
63 in USB device mode (OTG operation). It can be omitted if that is not
71 The old ehci_hcd_init() function is no-longer used. Nor is it necessary to
72 set up the USB controllers from board init code. When 'usb start' is used,
79 ---------------
83 - struct usb_device
92 - struct usb_platdata
94 as a work-around for controllers which can act as USB devices in OTG
97 - struct usb_dev_platdata
100 address and speed - anything that can be determined before the device
104 - struct usb_bus_priv
112 USB buses
113 ---------
115 Given a controller, you know the bus - it is the one attached to the
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
133 Enumeration in U-Boot takes a long time since devices are probed one at a
137 Up to 127 devices can be on each bus. USB has four bus speeds: low
140 newer (XHCI). If you connect a super-speed device to a high-speed hub, you
141 will only get high-speed.
144 USB operations
145 --------------
148 like. These are now implemented by the USB uclass and route through the
150 device itself - i.e. they don't pass down the stack to the controller.
151 U-Boot simply finds the controller to which the device is attached, and sends
153 properly. Having said that, the USB device which should receive the message
168 USB Devices
169 -----------
171 USB devices are found using a simple algorithm which works through the
172 available hubs in a depth-first search. Devices can be in any uclass, but
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
183 driver. For example, usb_storage.c defines a USB_DEVICE() to handle storage
184 devices, and it will be used for all USB devices which match.
189 -------------------------------------
191 It is useful to understand precisely how a USB bus is enumerating to avoid
192 confusion when dealing with USB devices.
196 - At some point the 'usb start' command is run
197 - This calls usb_init() which works through each controller in turn
198 - The controller is probed(). This does no enumeration.
199 - Then usb_scan_bus() is called. This calls usb_scan_device() to scan the
200 (only) device that is attached to the controller - a root hub
201 - usb_scan_device() sets up a fake struct usb_device and calls
204 - usb_setup_device() first calls usb_prepare_device() to set the device
206 - at this point the device is enumerated but we do not have a real struct
209 - back in usb_scan_device(), we call usb_find_child() to try to find an
213 - if usb_find_child() does not find an existing device, we call
215 - usb_find_and_bind_driver() searches all available USB drivers (declared
218 - If it does not, it binds a generic driver. A generic driver is good enough
221 - in any case, when usb_find_child() and/or usb_find_and_bind_driver() are
224 - first we store basic information about the new device (address, port,
227 - then we call device_probe() which probes the device
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
236 - note that we have called usb_select_config() twice. This is inefficient
239 - at this point the device is set up and ready for use so far as the USB
241 - the device's probe() method is then called. It can send messages and do
252 - usb_hub_post_probe() calls usb_hub_scan() to scan the hub, which in turn
254 - hub power is enabled
255 - we loop through each port on the hub, performing the same steps for each
256 - first, check if there is a device present. This happens in
259 - you will recognise usb_scan_device() from the steps above. It sets up the
261 continues here (recursively, depth-first)
262 - once all hub ports are scanned in this way, the hub is ready for use and
264 - additional controllers are scanned in the same way
268 - the bus enumeration happens by virtue of driver model's natural device flow
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
272 - hub scanning happens automatically after a hub is probed
276 ----
278 USB hubs are scanned as in the section above. While hubs have their own
281 - they both attach private data to their children (struct usb_device,
283 - they both use usb_child_pre_probe() to set up their children as proper USB
287 Example - Mass Storage
288 ----------------------
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
318 -----------------------------
320 As an example of the old way of doing things, see usb_ether.c. When the bus
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
328 (e.g drivers/usb/eth/asix.c) should include a USB_DEVICE() declaration, so
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
332 and then usb_ether.c and the usb_host_eth_scan() will melt away.
336 -------
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
350 usb@1 {
351 compatible = "sandbox,usb";
353 compatible = "usb-hub";
354 usb,device-class = <USB_CLASS_HUB>;
355 hub-emul {
356 compatible = "sandbox,usb-hub";
357 #address-cells = <1>;
358 #size-cells = <0>;
359 flash-stick {
361 compatible = "sandbox,usb-flash";
372 When 'usb start' is used, the following 'dm tree' output will be available:
374 usb [ + ] `-- usb@1
375 usb_hub [ + ] `-- hub
376 usb_emul [ + ] |-- hub-emul
377 usb_emul [ + ] | `-- flash-stick
378 usb_mass_st [ + ] `-- usb_mass_storage
383 usb_find_and_bind_driver() based on the USB_DRIVER in usb_storage.c. While
384 'flash-stick' is the emulation device, 'usb_mass_storage' is the real U-Boot
385 USB device driver that talks to it.
389 -----------
391 It is pretty uncommon to have a large USB bus with lots of hubs on an
395 - breadth-first search would allow devices to be reset and probed in
397 - enumeration could be lazy, in the sense that we could enumerate just the
406 - Convert usb_ether to use driver model as described above
407 - Test that keyboards work (and convert to driver model)
408 - Move the USB gadget framework to driver model
409 - Implement OHCI in driver model
410 - Implement USB PHYs in driver model
411 - Work out a clever way to provide lazy init for USB devices
413 --
415 23-Mar-15