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

diff --git a/doc/driver-model/UDM-fpga.txt b/doc/driver-model/UDM-fpga.txt
deleted file mode 100644
index 4f9df940ed..0000000000
--- a/doc/driver-model/UDM-fpga.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-The U-Boot Driver Model Project
-===============================
-I/O system analysis
-===================
-Marek Vasut <marek.vasut@gmail.com>
-2012-02-21
-
-I) Overview
------------
-
-The current FPGA implementation is handled by command "fpga". This command in
-turn calls the following functions:
-
-fpga_info()
-fpga_load()
-fpga_dump()
-
-These functions are implemented by what appears to be FPGA multiplexer, located
-in drivers/fpga/fpga.c . This code determines which device to operate with
-depending on the device ID.
-
-The fpga_info() function is multiplexer of the functions providing information
-about the particular FPGA device. These functions are implemented in the drivers
-for the particular FPGA device:
-
-xilinx_info()
-altera_info()
-lattice_info()
-
-Similar approach is used for fpga_load(), which multiplexes "xilinx_load()",
-"altera_load()" and "lattice_load()" and is used to load firmware into the FPGA
-device.
-
-The fpga_dump() function, which prints the contents of the FPGA device, is no
-different either, by multiplexing "xilinx_dump()", "altera_dump()" and
-"lattice_dump()" functions.
-
-Finally, each new FPGA device is registered by calling "fpga_add()" function.
-This function takes two arguments, the second one being particularly important,
-because it's basically what will become platform_data. Currently, it's data that
-are passed to the driver from the board/platform code.
-
-II) Approach
-------------
-
-The path to conversion of the FPGA subsystem will be very straightforward, since
-the FPGA subsystem is already quite dynamic. Multiple things will need to be
-modified though.
-
-First is the registration of the new FPGA device towards the FPGA core. This
-will be achieved by calling:
-
-  fpga_device_register(struct instance *i, const struct fpga_ops *ops);
-
-The particularly interesting part is the struct fpga_ops, which contains
-operations supported by the FPGA device. These are basically the already used
-calls in the current implementation:
-
-struct fpga_ops {
-  int info(struct instance *i);
-  int load(struct instance *i, const char *buf, size_t size);
-  int dump(struct instance *i, const char *buf, size_t size);
-}
-
-The other piece that'll have to be modified is how the devices are tracked.
-It'll be necessary to introduce a linked list of devices within the FPGA core
-instead of tracking them by ID number.
-
-Next, the "Xilinx_desc", "Lattice_desc" and "Altera_desc" structures will have
-to be moved to driver's private_data. Finally, structures passed from the board
-and/or platform files, like "Xilinx_Virtex2_Slave_SelectMap_fns" would be passed
-via platform_data to the driver.
-
-III) Analysis of in-tree drivers
---------------------------------
-
-  1) Altera driver
-  ----------------
-  The driver is realized using the following files:
-
-    drivers/fpga/altera.c
-    drivers/fpga/ACEX1K.c
-    drivers/fpga/cyclon2.c
-    drivers/fpga/stratixII.c
-
-  All of the sub-drivers implement basically the same info-load-dump interface
-  and there's no expected problem during the conversion. The driver itself will
-  be realised by altera.c and all the sub-drivers will be linked in. The
-  distinction will be done by passing different platform data.
-
-  2) Lattice driver
-  -----------------
-  The driver is realized using the following files:
-
-    drivers/fpga/lattice.c
-    drivers/fpga/ivm_core.c
-
-  This driver also implements the standard interface, but to realise the
-  operations with the FPGA device, uses functions from "ivm_core.c" file. This
-  file implements the main communications logic and has to be linked in together
-  with "lattice.c". No problem converting is expected here.
-
-  3) Xilinx driver
-  ----------------
-  The driver is realized using the following files:
-
-    drivers/fpga/xilinx.c
-    drivers/fpga/spartan2.c
-    drivers/fpga/spartan3.c
-    drivers/fpga/virtex2.c
-
-  This set of sub-drivers is special by defining a big set of macros in
-  "include/spartan3.h" and similar files. These macros would need to be either
-  rewritten or replaced. Otherwise, there are no problems expected during the
-  conversion process.