xref: /freebsd/sys/contrib/device-tree/Bindings/common-properties.txt (revision c66ec88fed842fbaad62c30d510644ceb7bd2d71)
1*c66ec88fSEmmanuel VadotCommon properties
2*c66ec88fSEmmanuel Vadot=================
3*c66ec88fSEmmanuel Vadot
4*c66ec88fSEmmanuel VadotEndianness
5*c66ec88fSEmmanuel Vadot----------
6*c66ec88fSEmmanuel Vadot
7*c66ec88fSEmmanuel VadotThe Devicetree Specification does not define any properties related to hardware
8*c66ec88fSEmmanuel Vadotbyte swapping, but endianness issues show up frequently in porting drivers to
9*c66ec88fSEmmanuel Vadotdifferent machine types.  This document attempts to provide a consistent
10*c66ec88fSEmmanuel Vadotway of handling byte swapping across drivers.
11*c66ec88fSEmmanuel Vadot
12*c66ec88fSEmmanuel VadotOptional properties:
13*c66ec88fSEmmanuel Vadot - big-endian: Boolean; force big endian register accesses
14*c66ec88fSEmmanuel Vadot   unconditionally (e.g. ioread32be/iowrite32be).  Use this if you
15*c66ec88fSEmmanuel Vadot   know the peripheral always needs to be accessed in big endian (BE) mode.
16*c66ec88fSEmmanuel Vadot - little-endian: Boolean; force little endian register accesses
17*c66ec88fSEmmanuel Vadot   unconditionally (e.g. readl/writel).  Use this if you know the
18*c66ec88fSEmmanuel Vadot   peripheral always needs to be accessed in little endian (LE) mode.
19*c66ec88fSEmmanuel Vadot - native-endian: Boolean; always use register accesses matched to the
20*c66ec88fSEmmanuel Vadot   endianness of the kernel binary (e.g. LE vmlinux -> readl/writel,
21*c66ec88fSEmmanuel Vadot   BE vmlinux -> ioread32be/iowrite32be).  In this case no byte swaps
22*c66ec88fSEmmanuel Vadot   will ever be performed.  Use this if the hardware "self-adjusts"
23*c66ec88fSEmmanuel Vadot   register endianness based on the CPU's configured endianness.
24*c66ec88fSEmmanuel Vadot
25*c66ec88fSEmmanuel VadotIf a binding supports these properties, then the binding should also
26*c66ec88fSEmmanuel Vadotspecify the default behavior if none of these properties are present.
27*c66ec88fSEmmanuel VadotIn such cases, little-endian is the preferred default, but it is not
28*c66ec88fSEmmanuel Vadota requirement.  Some implementations assume that little-endian is
29*c66ec88fSEmmanuel Vadotthe default, because most existing (PCI-based) drivers implicitly
30*c66ec88fSEmmanuel Vadotdefault to LE for their MMIO accesses.
31*c66ec88fSEmmanuel Vadot
32*c66ec88fSEmmanuel VadotExamples:
33*c66ec88fSEmmanuel VadotScenario 1 : CPU in LE mode & device in LE mode.
34*c66ec88fSEmmanuel Vadotdev: dev@40031000 {
35*c66ec88fSEmmanuel Vadot	      compatible = "name";
36*c66ec88fSEmmanuel Vadot	      reg = <0x40031000 0x1000>;
37*c66ec88fSEmmanuel Vadot	      ...
38*c66ec88fSEmmanuel Vadot	      native-endian;
39*c66ec88fSEmmanuel Vadot};
40*c66ec88fSEmmanuel Vadot
41*c66ec88fSEmmanuel VadotScenario 2 : CPU in LE mode & device in BE mode.
42*c66ec88fSEmmanuel Vadotdev: dev@40031000 {
43*c66ec88fSEmmanuel Vadot	      compatible = "name";
44*c66ec88fSEmmanuel Vadot	      reg = <0x40031000 0x1000>;
45*c66ec88fSEmmanuel Vadot	      ...
46*c66ec88fSEmmanuel Vadot	      big-endian;
47*c66ec88fSEmmanuel Vadot};
48*c66ec88fSEmmanuel Vadot
49*c66ec88fSEmmanuel VadotScenario 3 : CPU in BE mode & device in BE mode.
50*c66ec88fSEmmanuel Vadotdev: dev@40031000 {
51*c66ec88fSEmmanuel Vadot	      compatible = "name";
52*c66ec88fSEmmanuel Vadot	      reg = <0x40031000 0x1000>;
53*c66ec88fSEmmanuel Vadot	      ...
54*c66ec88fSEmmanuel Vadot	      native-endian;
55*c66ec88fSEmmanuel Vadot};
56*c66ec88fSEmmanuel Vadot
57*c66ec88fSEmmanuel VadotScenario 4 : CPU in BE mode & device in LE mode.
58*c66ec88fSEmmanuel Vadotdev: dev@40031000 {
59*c66ec88fSEmmanuel Vadot	      compatible = "name";
60*c66ec88fSEmmanuel Vadot	      reg = <0x40031000 0x1000>;
61*c66ec88fSEmmanuel Vadot	      ...
62*c66ec88fSEmmanuel Vadot	      little-endian;
63*c66ec88fSEmmanuel Vadot};
64*c66ec88fSEmmanuel Vadot
65*c66ec88fSEmmanuel VadotDaisy-chained devices
66*c66ec88fSEmmanuel Vadot---------------------
67*c66ec88fSEmmanuel Vadot
68*c66ec88fSEmmanuel VadotMany serially-attached GPIO and IIO devices are daisy-chainable.  To the
69*c66ec88fSEmmanuel Vadothost controller, a daisy-chain appears as a single device, but the number
70*c66ec88fSEmmanuel Vadotof inputs and outputs it provides is the sum of inputs and outputs provided
71*c66ec88fSEmmanuel Vadotby all of its devices.  The driver needs to know how many devices the
72*c66ec88fSEmmanuel Vadotdaisy-chain comprises to determine the amount of data exchanged, how many
73*c66ec88fSEmmanuel Vadotinputs and outputs to register and so on.
74*c66ec88fSEmmanuel Vadot
75*c66ec88fSEmmanuel VadotOptional properties:
76*c66ec88fSEmmanuel Vadot - #daisy-chained-devices: Number of devices in the daisy-chain (default is 1).
77*c66ec88fSEmmanuel Vadot
78*c66ec88fSEmmanuel VadotExample:
79*c66ec88fSEmmanuel Vadotgpio@0 {
80*c66ec88fSEmmanuel Vadot	      compatible = "name";
81*c66ec88fSEmmanuel Vadot	      reg = <0>;
82*c66ec88fSEmmanuel Vadot	      gpio-controller;
83*c66ec88fSEmmanuel Vadot	      #gpio-cells = <2>;
84*c66ec88fSEmmanuel Vadot	      #daisy-chained-devices = <3>;
85*c66ec88fSEmmanuel Vadot};
86