dm: Remove old driver model documentation

This documentation pertains to the planned implementation of driver model
in U-Boot for each subsystem, but it has not been superseded. It is
probably better to have this documentation in the source code for each
subsystem where possible, so that docbook will pick it up. Where this does
not make sense, new documentation can be placed in some suitable file in
doc/driver-model.

Signed-off-by: Simon Glass <sjg@chromium.org>

1 files changed, 0 insertions, 94 deletions

diff --git a/doc/driver-model/UDM-usb.txt b/doc/driver-model/UDM-usb.txt
deleted file mode 100644
index 5ce85b5..0000000
--- a/doc/driver-model/UDM-usb.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-The U-Boot Driver Model Project
-===============================
-USB analysis
-============
-Marek Vasut <marek.vasut@gmail.com>
-2012-02-16
-
-I) Overview
------------
-
-  1) The USB Host driver
-  ----------------------
-  There are basically four or five USB host drivers. All such drivers currently
-  provide at least the following fuctions:
-
-    usb_lowlevel_init() ... Do the initialization of the USB controller hardware
-    usb_lowlevel_stop() ... Do the shutdown of the USB controller hardware
-
-    usb_event_poll() ...... Poll interrupt from USB device, often used by KBD
-
-    submit_control_msg() .. Submit message via Control endpoint
-    submit_int_msg() ...... Submit message via Interrupt endpoint
-    submit_bulk_msg() ..... Submit message via Bulk endpoint
-
-
-    This allows for the host driver to be easily abstracted.
-
-  2) The USB hierarchy
-  --------------------
-
-  In the current implementation, the USB Host driver provides operations to
-  communicate via the USB bus. This is realised by providing access to a USB
-  root port to which an USB root hub is attached. The USB bus is scanned and for
-  each newly found device, a struct usb_device is allocated. See common/usb.c
-  and include/usb.h for details.
-
-II) Approach
-------------
-
-  1) The USB Host driver
-  ----------------------
-
-  Converting the host driver will follow the classic driver model consideration.
-  Though, the host driver will have to call a function that registers a root
-  port with the USB core in it's probe() function, let's call this function
-
-    usb_register_root_port(&ops);
-
-  This will allow the USB core to track all available root ports. The ops
-  parameter will contain structure describing operations supported by the root
-  port:
-
-  struct usb_port_ops {
-    void   (*usb_event_poll)();
-    int    (*submit_control_msg)();
-    int    (*submit_int_msg)();
-    int    (*submit_bulk_msg)();
-  }
-
-  2) The USB hierarchy and hub drivers
-  ------------------------------------
-
-  Converting the USB heirarchy should be fairy simple, considering the already
-  dynamic nature of the implementation. The current usb_hub_device structure
-  will have to be converted to a struct instance. Every such instance will
-  contain components of struct usb_device and struct usb_hub_device in it's
-  private data, providing only accessors in order to properly encapsulate the
-  driver.
-
-  By registering the root port, the USB framework will instantiate a USB hub
-  driver, which is always present, the root hub. The root hub and any subsequent
-  hub instance is represented by struct instance and it's private data contain
-  amongst others common bits from struct usb_device.
-
-  Note the USB hub driver is partly defying the usual method of registering a
-  set of callbacks to a particular core driver. Instead, a static set of
-  functions is defined and the USB hub instance is passed to those. This creates
-  certain restrictions as of how the USB hub driver looks, but considering the
-  specification for USB hub is given and a different type of USB hub won't ever
-  exist, this approach is ok:
-
-  - Report how many ports does this hub have:
-      uint get_nr_ports(struct instance *hub);
-  - Get pointer to device connected to a port:
-      struct instance *(*get_child)(struct instance *hub, int port);
-  - Instantiate and configure device on port:
-      struct instance *(*enum_dev_on_port)(struct instance *hub, int port);
-
-  3) USB device drivers
-  ---------------------
-
-  The USB device driver, in turn, will have to register various ops structures
-  with certain cores. For example, USB disc driver will have to register it's
-  ops with core handling USB discs etc.