| Tom Rini | 53633a8 | 2024-02-29 12:33:36 -0500 | [diff] [blame] | 1 | Common properties |
| 2 | ================= |
| 3 | |
| 4 | Endianness |
| 5 | ---------- |
| 6 | |
| 7 | The Devicetree Specification does not define any properties related to hardware |
| 8 | byte swapping, but endianness issues show up frequently in porting drivers to |
| 9 | different machine types. This document attempts to provide a consistent |
| 10 | way of handling byte swapping across drivers. |
| 11 | |
| 12 | Optional properties: |
| 13 | - big-endian: Boolean; force big endian register accesses |
| 14 | unconditionally (e.g. ioread32be/iowrite32be). Use this if you |
| 15 | know the peripheral always needs to be accessed in big endian (BE) mode. |
| 16 | - little-endian: Boolean; force little endian register accesses |
| 17 | unconditionally (e.g. readl/writel). Use this if you know the |
| 18 | peripheral always needs to be accessed in little endian (LE) mode. |
| 19 | - native-endian: Boolean; always use register accesses matched to the |
| 20 | endianness of the kernel binary (e.g. LE vmlinux -> readl/writel, |
| 21 | BE vmlinux -> ioread32be/iowrite32be). In this case no byte swaps |
| 22 | will ever be performed. Use this if the hardware "self-adjusts" |
| 23 | register endianness based on the CPU's configured endianness. |
| 24 | |
| 25 | If a binding supports these properties, then the binding should also |
| 26 | specify the default behavior if none of these properties are present. |
| 27 | In such cases, little-endian is the preferred default, but it is not |
| 28 | a requirement. Some implementations assume that little-endian is |
| 29 | the default, because most existing (PCI-based) drivers implicitly |
| 30 | default to LE for their MMIO accesses. |
| 31 | |
| 32 | Examples: |
| 33 | Scenario 1 : CPU in LE mode & device in LE mode. |
| 34 | dev: dev@40031000 { |
| 35 | compatible = "name"; |
| 36 | reg = <0x40031000 0x1000>; |
| 37 | ... |
| 38 | native-endian; |
| 39 | }; |
| 40 | |
| 41 | Scenario 2 : CPU in LE mode & device in BE mode. |
| 42 | dev: dev@40031000 { |
| 43 | compatible = "name"; |
| 44 | reg = <0x40031000 0x1000>; |
| 45 | ... |
| 46 | big-endian; |
| 47 | }; |
| 48 | |
| 49 | Scenario 3 : CPU in BE mode & device in BE mode. |
| 50 | dev: dev@40031000 { |
| 51 | compatible = "name"; |
| 52 | reg = <0x40031000 0x1000>; |
| 53 | ... |
| 54 | native-endian; |
| 55 | }; |
| 56 | |
| 57 | Scenario 4 : CPU in BE mode & device in LE mode. |
| 58 | dev: dev@40031000 { |
| 59 | compatible = "name"; |
| 60 | reg = <0x40031000 0x1000>; |
| 61 | ... |
| 62 | little-endian; |
| 63 | }; |
| 64 | |
| 65 | Daisy-chained devices |
| 66 | --------------------- |
| 67 | |
| 68 | Many serially-attached GPIO and IIO devices are daisy-chainable. To the |
| 69 | host controller, a daisy-chain appears as a single device, but the number |
| 70 | of inputs and outputs it provides is the sum of inputs and outputs provided |
| 71 | by all of its devices. The driver needs to know how many devices the |
| 72 | daisy-chain comprises to determine the amount of data exchanged, how many |
| 73 | inputs and outputs to register and so on. |
| 74 | |
| 75 | Optional properties: |
| 76 | - #daisy-chained-devices: Number of devices in the daisy-chain (default is 1). |
| 77 | |
| 78 | Example: |
| 79 | gpio@0 { |
| 80 | compatible = "name"; |
| 81 | reg = <0>; |
| 82 | gpio-controller; |
| 83 | #gpio-cells = <2>; |
| 84 | #daisy-chained-devices = <3>; |
| 85 | }; |