doc/driver-model/usb-info.txt

5 ------------
9 understand how things work with USB in U-Boot when driver model is enabled.
13 -----------------------------
21 Support for EHCI and XHCI
22 -------------------------
24 So far OHCI is not supported. Both EHCI and XHCI drivers should be declared
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
71 The old ehci_hcd_init() function is no-longer used. Nor is it necessary to
75 XHCI works in a similar way.
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
113 ---------
115 Given a controller, you know the bus - it is the one attached to the
133 Enumeration in U-Boot takes a long time since devices are probed one at a
140 newer (XHCI). If you connect a super-speed device to a high-speed hub, you
141 will only get high-speed.
145 --------------
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
156 methods are typically implemented by the EHCI and XHCI stacks.
159 each message type. For XHCI an additional alloc_device() method is provided
160 since XHCI needs to allocate a device context before it can even read the
169 -----------
172 available hubs in a depth-first search. Devices can be in any uclass, but
182 with USB devices - you can use the USB_DEVICE() macro to declare a USB
189 -------------------------------------
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)
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
272 - hub scanning happens automatically after a hub is probed
276 ----
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 ----------------------
317 Counter-example: USB Ethernet
318 -----------------------------
321 is scanned, all Ethernet devices will be created as generic USB devices (in
330 generic USB driver, a real (driver-model-aware) driver will be used. Since
336 -------
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";
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
384 'flash-stick' is the emulation device, 'usb_mass_storage' is the real U-Boot
389 -----------
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