Documentation/devicetree/bindings/fsi/fsi.txt

   1 FSI bus & engine generic device tree bindings
   2 =============================================
   3
   4 The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and
   5 engines within those slaves. However, we have a facility to match devicetree
   6 nodes to probed engines. This allows for fsi engines to expose non-probeable
   7 busses, which are then exposed by the device tree. For example, an FSI engine
   8 that is an I2C master - the I2C bus can be described by the device tree under
   9 the engine's device tree node.
  10
  11 FSI masters may require their own DT nodes (to describe the master HW itself);
  12 that requirement is defined by the master's implementation, and is described by
  13 the fsi-master-* binding specifications.
  14
  15 Under the masters' nodes, we can describe the bus topology using nodes to
  16 represent the FSI slaves and their slave engines. As a basic outline:
  17
  18   fsi-master {
  19       /* top-level of FSI bus topology, bound to an FSI master driver and
  20        * exposes an FSI bus */
  21
  22       fsi-slave@<link,id> {
  23           /* this node defines the FSI slave device, and is handled
  24            * entirely with FSI core code */
  25
  26           fsi-slave-engine@<addr> {
  27               /* this node defines the engine endpoint & address range, which
  28                * is bound to the relevant fsi device driver */
  29                ...
  30           };
  31
  32           fsi-slave-engine@<addr> {
  33               ...
  34           };
  35
  36       };
  37   };
  38
  39 Note that since the bus is probe-able, some (or all) of the topology may
  40 not be described; this binding only provides an optional facility for
  41 adding subordinate device tree nodes as children of FSI engines.
  42
  43 FSI masters
  44 -----------
  45
  46 FSI master nodes declare themselves as such with the "fsi-master" compatible
  47 value. It's likely that an implementation-specific compatible value will
  48 be needed as well, for example:
  49
  50     compatible = "fsi-master-gpio", "fsi-master";
  51
  52 Since the master nodes describe the top-level of the FSI topology, they also
  53 need to declare the FSI-standard addressing scheme. This requires two cells for
  54 addresses (link index and slave ID), and no size:
  55
  56     #address-cells = <2>;
  57     #size-cells = <0>;
  58
  59 An optional boolean property can be added to indicate that a particular master
  60 should not scan for connected devices at initialization time.  This is
  61 necessary in cases where a scan could cause arbitration issues with other
  62 masters that may be present on the bus.
  63
  64     no-scan-on-init;
  65
  66 FSI slaves
  67 ----------
  68
  69 Slaves are identified by a (link-index, slave-id) pair, so require two cells
  70 for an address identifier. Since these are not a range, no size cells are
  71 required. For an example, a slave on link 1, with ID 2, could be represented
  72 as:
  73
  74     cfam@1,2 {
  75         reg = <1 2>;
  76         [...];
  77     }
  78
  79 Each slave provides an address-space, under which the engines are accessible.
  80 That address space has a maximum of 23 bits, so we use one cell to represent
  81 addresses and sizes in the slave address space:
  82
  83     #address-cells = <1>;
  84     #size-cells = <1>;
  85
  86 Optionally, a slave can provide a global unique chip ID which is used to
  87 identify the physical location of the chip in a system specific way
  88
  89     chip-id = <0>;
  90
  91 FSI engines (devices)
  92 ---------------------
  93
  94 Engines are identified by their address under the slaves' address spaces. We
  95 use a single cell for address and size. Engine nodes represent the endpoint
  96 FSI device, and are passed to those FSI device drivers' ->probe() functions.
  97
  98 For example, for a slave using a single 0x400-byte page starting at address
  99 0xc00:
 100
 101     engine@c00 {
 102         reg = <0xc00 0x400>;
 103     };
 104
 105
 106 Full example
 107 ------------
 108
 109 Here's an example that illustrates:
 110  - an FSI master
 111    - connected to an FSI slave
 112      - that contains an engine that is an I2C master
 113        - connected to an I2C EEPROM
 114
 115 The FSI master may be connected to additional slaves, and slaves may have
 116 additional engines, but they don't necessarily need to be describe in the
 117 device tree if no extra platform information is required.
 118
 119     /* The GPIO-based FSI master node, describing the top level of the
 120      * FSI bus
 121      */
 122     gpio-fsi {
 123         compatible = "fsi-master-gpio", "fsi-master";
 124         #address-cells = <2>;
 125         #size-cells = <0>;
 126
 127         /* A FSI slave (aka. CFAM) at link 0, ID 0. */
 128         cfam@0,0 {
 129             reg = <0 0>;
 130             #address-cells = <1>;
 131             #size-cells = <1>;
 132             chip-id = <0>;
 133
 134             /* FSI engine at 0xc00, using a single page. In this example,
 135              * it's an I2C master controller, so subnodes describe the
 136              * I2C bus.
 137              */
 138             i2c-controller@c00 {
 139                 reg = <0xc00 0x400>;
 140
 141                 /* Engine-specific data. In this case, we're describing an
 142                  * I2C bus, so we're conforming to the generic I2C binding
 143                  */
 144                 compatible = "some-vendor,fsi-i2c-controller";
 145                 #address-cells = <1>;
 146                 #size-cells = <1>;
 147
 148                 /* I2C endpoint device: an Atmel EEPROM */
 149                 eeprom@50 {
 150                     compatible = "atmel,24c256";
 151                     reg = <0x50>;
 152                     pagesize = <64>;
 153                 };
 154             };
 155         };
 156     };