doc/driver-model/UDM-fpga.txt

   1 The U-Boot Driver Model Project
   2 ===============================
   3 I/O system analysis
   4 ===================
   5 Marek Vasut <marek.vasut@gmail.com>
   6 2012-02-21
   7
   8 I) Overview
   9 -----------
  10
  11 The current FPGA implementation is handled by command "fpga". This command in
  12 turn calls the following functions:
  13
  14 fpga_info()
  15 fpga_load()
  16 fpga_dump()
  17
  18 These functions are implemented by what appears to be FPGA multiplexer, located
  19 in drivers/fpga/fpga.c . This code determines which device to operate with
  20 depending on the device ID.
  21
  22 The fpga_info() function is multiplexer of the functions providing information
  23 about the particular FPGA device. These functions are implemented in the drivers
  24 for the particular FPGA device:
  25
  26 xilinx_info()
  27 altera_info()
  28 lattice_info()
  29
  30 Similar approach is used for fpga_load(), which multiplexes "xilinx_load()",
  31 "altera_load()" and "lattice_load()" and is used to load firmware into the FPGA
  32 device.
  33
  34 The fpga_dump() function, which prints the contents of the FPGA device, is no
  35 different either, by multiplexing "xilinx_dump()", "altera_dump()" and
  36 "lattice_dump()" functions.
  37
  38 Finally, each new FPGA device is registered by calling "fpga_add()" function.
  39 This function takes two arguments, the second one being particularly important,
  40 because it's basically what will become platform_data. Currently, it's data that
  41 are passed to the driver from the board/platform code.
  42
  43 II) Approach
  44 ------------
  45
  46 The path to conversion of the FPGA subsystem will be very straightforward, since
  47 the FPGA subsystem is already quite dynamic. Multiple things will need to be
  48 modified though.
  49
  50 First is the registration of the new FPGA device towards the FPGA core. This
  51 will be achieved by calling:
  52
  53   fpga_device_register(struct instance *i, const struct fpga_ops *ops);
  54
  55 The particularly interesting part is the struct fpga_ops, which contains
  56 operations supported by the FPGA device. These are basically the already used
  57 calls in the current implementation:
  58
  59 struct fpga_ops {
  60   int info(struct instance *i);
  61   int load(struct instance *i, const char *buf, size_t size);
  62   int dump(struct instance *i, const char *buf, size_t size);
  63 }
  64
  65 The other piece that'll have to be modified is how the devices are tracked.
  66 It'll be necessary to introduce a linked list of devices within the FPGA core
  67 instead of tracking them by ID number.
  68
  69 Next, the "Xilinx_desc", "Lattice_desc" and "Altera_desc" structures will have
  70 to be moved to driver's private_data. Finally, structures passed from the board
  71 and/or platform files, like "Xilinx_Virtex2_Slave_SelectMap_fns" would be passed
  72 via platform_data to the driver.
  73
  74 III) Analysis of in-tree drivers
  75 --------------------------------
  76
  77   1) Altera driver
  78   ----------------
  79   The driver is realized using the following files:
  80
  81     drivers/fpga/altera.c
  82     drivers/fpga/ACEX1K.c
  83     drivers/fpga/cyclon2.c
  84     drivers/fpga/stratixII.c
  85
  86   All of the sub-drivers implement basically the same info-load-dump interface
  87   and there's no expected problem during the conversion. The driver itself will
  88   be realised by altera.c and all the sub-drivers will be linked in. The
  89   distinction will be done by passing different platform data.
  90
  91   2) Lattice driver
  92   -----------------
  93   The driver is realized using the following files:
  94
  95     drivers/fpga/lattice.c
  96     drivers/fpga/ivm_core.c
  97
  98   This driver also implements the standard interface, but to realise the
  99   operations with the FPGA device, uses functions from "ivm_core.c" file. This
 100   file implements the main communications logic and has to be linked in together
 101   with "lattice.c". No problem converting is expected here.
 102
 103   3) Xilinx driver
 104   ----------------
 105   The driver is realized using the following files:
 106
 107     drivers/fpga/xilinx.c
 108     drivers/fpga/spartan2.c
 109     drivers/fpga/spartan3.c
 110     drivers/fpga/virtex2.c
 111
 112   This set of sub-drivers is special by defining a big set of macros in
 113   "include/spartan3.h" and similar files. These macros would need to be either
 114   rewritten or replaced. Otherwise, there are no problems expected during the
 115   conversion process.