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 },
53 The ops here are ehci_usb_ops. All EHCI drivers will use these same ops in
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
67 call ehci_register() to register itself as an EHCI device. It should call
68 ehci_deregister() in the remove() method. Registering a new EHCI device
71 The old ehci_hcd_init() function is no-longer used. Nor is it necessary to
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
139 and newer (EHCI), and super (5Gbps) which is only available with USB3 and
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.
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 -----------------------------
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