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, 126 deletions

diff --git a/doc/driver-model/UDM-cores.txt b/doc/driver-model/UDM-cores.txt
deleted file mode 100644
index 6032333..0000000
--- a/doc/driver-model/UDM-cores.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-The U-Boot Driver Model Project
-===============================
-Driver cores API document
-=========================
-
-Pavel Herrmann <morpheus.ibis@gmail.com>
-
-1) Overview
------------
-  Driver cores will be used as a wrapper for devices of the same type, and as
-  an abstraction for device driver APIs. For each driver API (which roughly
-  correspond to device types), there will be one driver core. Each driver core
-  will implement three APIs - a driver API (which will be the same as API of
-  drivers the core wraps around), a core API (which will be implemented by all
-  cores) and a command API (core-specific API which will be exposed to
-  commands).
-
-  A) Command API
-    The command API will provide access to shared functionality for a specific
-    device, which is currently located mostly in commands. Commands will be
-    rewritten to be more lightweight by using this API. As this API will be
-    different for each core, it is out of scope of this document.
-
-  B) Driver API
-    The driver API will act as a wrapper around actual device drivers,
-    providing a single entrypoint for device access. All functions in this API
-    have an instance* argument (probably called "this" or "i"), which will be
-    examined by the core, and a correct function for the specified driver will
-    get called.
-
-    If the core gets called with a group instance pointer (as discussed in
-    design), it will automatically select the instance that is associated
-    with this core, and use it as target of the call. if the group contains
-    multiple instances of a single type, the caller must explicitly use an
-    accessor to select the correct instance.
-
-    This accessor will look like:
-      struct instance *get_instance_from_group(struct instance *group, int i)
-
-    When called with a non-group instance, it will simply return the instance.
-
-  C) Core API
-    The core API will be implemented by all cores, and will provide
-    functionality for getting driver instances from non-driver code. This API
-    will consist of following functions:
-
-      int get_count(struct instance *core);
-      struct instance* get_instance(struct instance *core, int index);
-      int init(struct instance *core);
-      int bind(struct instance *core, struct instance *dev, void *ops,
-	       void *hint);
-      int unbind(struct instance *core, instance *dev);
-      int replace(struct instance *core, struct_instance *new_dev,
-		  struct instance *old_dev);
-      int destroy(struct instance *core);
-      int reloc(struct instance *new_core, struct instance *old_core);
-
-      The 'hint' parameter of bind() serves for additional data a driver can
-      pass to the core, to help it create the correct internal state for this
-      instance. the replace() function will get called during instance
-      relocation, and will replace the old instance with the new one, keeping
-      the internal state untouched.
-
-
-2) Lifetime of a driver core
-----------------------------
-  Driver cores will be initialized at runtime, to limit memory footprint in
-  early-init stage, when we have to fit into ~1KB of memory. All active cores
-  will be stored in a tree structure (referenced as "Core tree") in global data,
-  which provides good tradeoff between size and access time.
-  Every core will have a number constant associated with it, which will be used
-  to find the instance in Core tree, and to refer to the core in all calls
-  working with the Core tree.
-  The Core Tree should be implemented using B-tree (or a similar structure)
-  to guarantee acceptable time overhead in all cases.
-
-  Code for working with the core (i2c in this example) follows:
-
-    core_init(CORE_I2C);
-      This will check whether we already have a i2c core, and if not it creates
-      a new instance and adds it into the Core tree. This will not be exported,
-      all code should depend on get_core_instance to init the core when
-      necessary.
-
-    get_core_instance(CORE_I2C);
-      This is an accessor into the Core tree, which will return the instance
-      of i2c core, creating it if necessary
-
-    core_bind(CORE_I2C, instance, driver_ops);
-      This will get called in bind() function of a driver, and will add the
-      instance into cores internal list of devices. If the core is not found, it
-      will get created.
-
-    driver_activate(instance *inst);
-      This call will recursively activate all devices necessary for using the
-      specified device. the code could be simplified as:
-	{
-	if (is_activated(inst))
-	  return;
-	driver_activate(inst->bus);
-	get_driver(inst)->probe(inst);
-	}
-
-      The case with multiple parents will need to be handled here as well.
-      get_driver is an accessor to available drivers, which will get struct
-      driver based on a name in the instance.
-
-    i2c_write(instance *inst, ...);
-      An actual call to some method of the driver. This code will look like:
-	{
-	driver_activate(inst);
-	struct instance *core = get_core_instance(CORE_I2C);
-	device_ops = get_ops(inst);
-	device_ops->write(...);
-	}
-
-      get_ops will not be an exported function, it will be internal and specific
-      to the core, as it needs to know how are the ops stored, and what type
-      they are.
-
-  Please note that above examples represent the algorithm, not the actual code,
-  as they are missing checks for validity of return values.
-
-  core_init() function will get called the first time the core is requested,
-  either by core_link() or core_get_instance(). This way, the cores will get
-  created only when they are necessary, which will reduce our memory footprint.