Documentation / devicetree / bindings / fsi


Based on kernel version 6.12.4. Page generated on 2024-12-12 21:01 EST.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156
FSI bus & engine generic device tree bindings
=============================================

The FSI bus is probe-able, so the OS is able to enumerate FSI slaves, and
engines within those slaves. However, we have a facility to match devicetree
nodes to probed engines. This allows for fsi engines to expose non-probeable
busses, which are then exposed by the device tree. For example, an FSI engine
that is an I2C master - the I2C bus can be described by the device tree under
the engine's device tree node.

FSI masters may require their own DT nodes (to describe the master HW itself);
that requirement is defined by the master's implementation, and is described by
the fsi-master-* binding specifications.

Under the masters' nodes, we can describe the bus topology using nodes to
represent the FSI slaves and their slave engines. As a basic outline:

  fsi-master {
      /* top-level of FSI bus topology, bound to an FSI master driver and
       * exposes an FSI bus */

      fsi-slave@<link,id> {
          /* this node defines the FSI slave device, and is handled
           * entirely with FSI core code */

          fsi-slave-engine@<addr> {
              /* this node defines the engine endpoint & address range, which
               * is bound to the relevant fsi device driver */
               ...
          };

          fsi-slave-engine@<addr> {
              ...
          };

      };
  };

Note that since the bus is probe-able, some (or all) of the topology may
not be described; this binding only provides an optional facility for
adding subordinate device tree nodes as children of FSI engines.

FSI masters
-----------

FSI master nodes declare themselves as such with the "fsi-master" compatible
value. It's likely that an implementation-specific compatible value will
be needed as well, for example:

    compatible = "fsi-master-gpio", "fsi-master";

Since the master nodes describe the top-level of the FSI topology, they also
need to declare the FSI-standard addressing scheme. This requires two cells for
addresses (link index and slave ID), and no size:

    #address-cells = <2>;
    #size-cells = <0>;

An optional boolean property can be added to indicate that a particular master
should not scan for connected devices at initialization time.  This is
necessary in cases where a scan could cause arbitration issues with other
masters that may be present on the bus.

    no-scan-on-init;

FSI slaves
----------

Slaves are identified by a (link-index, slave-id) pair, so require two cells
for an address identifier. Since these are not a range, no size cells are
required. For an example, a slave on link 1, with ID 2, could be represented
as:

    cfam@1,2 {
        reg = <1 2>;
	[...];
    }

Each slave provides an address-space, under which the engines are accessible.
That address space has a maximum of 23 bits, so we use one cell to represent
addresses and sizes in the slave address space:

    #address-cells = <1>;
    #size-cells = <1>;

Optionally, a slave can provide a global unique chip ID which is used to
identify the physical location of the chip in a system specific way

    chip-id = <0>;

FSI engines (devices)
---------------------

Engines are identified by their address under the slaves' address spaces. We
use a single cell for address and size. Engine nodes represent the endpoint
FSI device, and are passed to those FSI device drivers' ->probe() functions.

For example, for a slave using a single 0x400-byte page starting at address
0xc00:

    engine@c00 {
        reg = <0xc00 0x400>;
    };


Full example
------------

Here's an example that illustrates:
 - an FSI master
   - connected to an FSI slave
     - that contains an engine that is an I2C master
       - connected to an I2C EEPROM

The FSI master may be connected to additional slaves, and slaves may have
additional engines, but they don't necessarily need to be describe in the
device tree if no extra platform information is required.

    /* The GPIO-based FSI master node, describing the top level of the
     * FSI bus
     */
    gpio-fsi {
        compatible = "fsi-master-gpio", "fsi-master";
        #address-cells = <2>;
        #size-cells = <0>;

        /* A FSI slave (aka. CFAM) at link 0, ID 0. */
        cfam@0,0 {
            reg = <0 0>;
            #address-cells = <1>;
            #size-cells = <1>;
	    chip-id = <0>;

            /* FSI engine at 0xc00, using a single page. In this example,
             * it's an I2C master controller, so subnodes describe the
             * I2C bus.
             */
            i2c-controller@c00 {
                reg = <0xc00 0x400>;

                /* Engine-specific data. In this case, we're describing an
                 * I2C bus, so we're conforming to the generic I2C binding
                 */
                compatible = "some-vendor,fsi-i2c-controller";
                #address-cells = <1>;
                #size-cells = <1>;

                /* I2C endpoint device: an Atmel EEPROM */
                eeprom@50 {
                    compatible = "atmel,24c256";
                    reg = <0x50>;
                    pagesize = <64>;
                };
            };
        };
    };