Lines Matching +full:usb +full:- +full:a
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
62 Note that usb_platdata is currently only used to deal with setting up a bus
63 in USB device mode (OTG operation). It can be omitted if that is not
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
72 set up the USB controllers from board init code. When 'usb start' is used,
75 XHCI works in a similar way.
79 ---------------
83 - struct usb_device
84 This holds information about a device on the bus. All devices have
86 have this structure. You can access it for a device 'dev' with
92 - struct usb_platdata
93 This holds platform data for a controller. So far this is only used
94 as a work-around for controllers which can act as USB devices in OTG
97 - struct usb_dev_platdata
98 This holds platform data for a device. You can access it for a
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
116 controller. Each controller handles exactly one bus. Every controller has a
117 root hub attached to it. This hub, which is itself a USB device, can provide
119 possible to power up a hub and find out which of its ports have devices
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
128 in a tree structure, potentially with multiple hubs each with several ports
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
160 since XHCI needs to allocate a device context before it can even read the
163 These methods use a 'pipe' which is a collection of bit fields used to
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
173 are attached to a parent hub (or controller in the case of the root hub) and
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
216 with USB_DEVICE()). If it finds a match it binds that driver to create a new
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
222 done, we have a device with the correct uclass. At this point we want to
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)
230 intended to set up a child device ready to be used with its parent bus. For
231 USB this calls usb_child_pre_probe() which grabs the information that was
233 (which is struct usb_device, a real one this time). It then calls
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
244 Note that the first device is always a root hub, and this must be scanned to
245 find any devices. The above steps will have created a hub (UCLASS_USB_HUB),
248 For hubs, the hub uclass has a post_probe() method. This means that after
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
260 device ready for use. If it is a hub, it will scan that hub before it
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,
282 accessible for a child with dev_get_parent_priv(child))
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 -----------------------------
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
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";
368 This defines a single controller, containing a root hub (which is required).
369 The hub is emulated by a hub emulator, and the emulated hub has a single
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
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
392 embedded system. In fact anything other than a root hub is uncommon. Still
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
398 root hub at first, then only progress to the next 'level' when a device is
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