123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156 |
- 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>;
- };
- };
- };
- };
|