doc: driver-model: Convert usb-info.txt to reST

Convert plain text documentation to reStructuredText format and add
it to Sphinx TOC tree. No essential content change.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

doc/driver-model/index.rst

@@ -18,3 +18,4 @@ Driver Model
    remoteproc-framework
    serial-howto
    spi-howto
+   usb-info

doc/driver-model/usb-info.rst

@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
 How USB works with driver model
 ===============================
 
@@ -24,6 +26,8 @@ Support for EHCI and XHCI
 So far OHCI is not supported. Both EHCI and XHCI drivers should be declared
 as drivers in the USB uclass. For example:
 
+.. code-block:: c
+
 	static const struct udevice_id ehci_usb_ids[] = {
 		{ .compatible = "nvidia,tegra20-ehci", .data = USB_CTLR_T20 },
 		{ .compatible = "nvidia,tegra30-ehci", .data = USB_CTLR_T30 },
@@ -80,7 +84,7 @@ Data structures
 
 The following primary data structures are in use:
 
-- struct usb_device
+- struct usb_device:
 	This holds information about a device on the bus. All devices have
 	this structure, even the root hub. The controller itself does not
 	have this structure. You can access it for a device 'dev' with
@@ -89,19 +93,19 @@ The following primary data structures are in use:
 	handles that). Once the device is set up, you can find the device
 	descriptor and current configuration descriptor in this structure.
 
-- struct usb_platdata
+- struct usb_platdata:
 	This holds platform data for a controller. So far this is only used
 	as a work-around for controllers which can act as USB devices in OTG
 	mode, since the gadget framework does not use driver model.
 
-- struct usb_dev_platdata
+- struct usb_dev_platdata:
 	This holds platform data for a device. You can access it for a
 	device 'dev' with dev_get_parent_platdata(dev). It holds the device
 	address and speed - anything that can be determined before the device
 	driver is actually set up. When probing the bus this structure is
 	used to provide essential information to the device driver.
 
-- struct usb_bus_priv
+- struct usb_bus_priv:
 	This is private information for each controller, maintained by the
 	controller uclass. It is mostly used to keep track of the next
 	device address to use.
@@ -199,8 +203,8 @@ Device initialisation happens roughly like this:
 - Then usb_scan_bus() is called. This calls usb_scan_device() to scan the
   (only) device that is attached to the controller - a root hub
 - usb_scan_device() sets up a fake struct usb_device and calls
-usb_setup_device(), passing the port number to be scanned, in this case port
-0
+  usb_setup_device(), passing the port number to be scanned, in this case
+  port 0
 - usb_setup_device() first calls usb_prepare_device() to set the device
   address, then usb_select_config() to select the first configuration
 - at this point the device is enumerated but we do not have a real struct
@@ -213,8 +217,8 @@ scanned the bus and so the device was created before
 - if usb_find_child() does not find an existing device, we call
   usb_find_and_bind_driver() which tries to bind one
 - usb_find_and_bind_driver() searches all available USB drivers (declared
-with USB_DEVICE()). If it finds a match it binds that driver to create a new
-device.
+  with USB_DEVICE()). If it finds a match it binds that driver to create a
+  new device.
 - If it does not, it binds a generic driver. A generic driver is good enough
   to allow access to the device (sending it packets, etc.) but all
   functionality will need to be implemented outside the driver model.
@@ -290,6 +294,8 @@ Example - Mass Storage
 As an example of a USB device driver, see usb_storage.c. It uses its own
 uclass and declares itself as follows:
 
+.. code-block:: c
+
 	U_BOOT_DRIVER(usb_mass_storage) = {
 		.name	= "usb_mass_storage",
 		.id	= UCLASS_MASS_STORAGE,
@@ -347,6 +353,8 @@ stack to be tested without real hardware being needed.
 
 Here is an example device tree fragment:
 
+.. code-block:: none
+
 	usb@1 {
 		compatible = "sandbox,usb";
 		hub {
@@ -369,7 +377,7 @@ This defines a single controller, containing a root hub (which is required).
 The hub is emulated by a hub emulator, and the emulated hub has a single
 flash stick to emulate on one of its ports.
 
-When 'usb start' is used, the following 'dm tree' output will be available:
+When 'usb start' is used, the following 'dm tree' output will be available::
 
    usb         [ + ]    `-- usb@1
    usb_hub     [ + ]        `-- hub
@@ -410,6 +418,6 @@ Other things that need doing:
 - Implement USB PHYs in driver model
 - Work out a clever way to provide lazy init for USB devices
 
---
-Simon Glass <sjg@chromium.org>
-23-Mar-15
+
+.. Simon Glass <sjg@chromium.org>
+.. 23-Mar-15