mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
85 lines
2.8 KiB
85 lines
2.8 KiB
Common properties |
|
================= |
|
|
|
Endianness |
|
---------- |
|
|
|
The Devicetree Specification does not define any properties related to hardware |
|
byte swapping, but endianness issues show up frequently in porting drivers to |
|
different machine types. This document attempts to provide a consistent |
|
way of handling byte swapping across drivers. |
|
|
|
Optional properties: |
|
- big-endian: Boolean; force big endian register accesses |
|
unconditionally (e.g. ioread32be/iowrite32be). Use this if you |
|
know the peripheral always needs to be accessed in big endian (BE) mode. |
|
- little-endian: Boolean; force little endian register accesses |
|
unconditionally (e.g. readl/writel). Use this if you know the |
|
peripheral always needs to be accessed in little endian (LE) mode. |
|
- native-endian: Boolean; always use register accesses matched to the |
|
endianness of the kernel binary (e.g. LE vmlinux -> readl/writel, |
|
BE vmlinux -> ioread32be/iowrite32be). In this case no byte swaps |
|
will ever be performed. Use this if the hardware "self-adjusts" |
|
register endianness based on the CPU's configured endianness. |
|
|
|
If a binding supports these properties, then the binding should also |
|
specify the default behavior if none of these properties are present. |
|
In such cases, little-endian is the preferred default, but it is not |
|
a requirement. Some implementations assume that little-endian is |
|
the default, because most existing (PCI-based) drivers implicitly |
|
default to LE for their MMIO accesses. |
|
|
|
Examples: |
|
Scenario 1 : CPU in LE mode & device in LE mode. |
|
dev: dev@40031000 { |
|
compatible = "name"; |
|
reg = <0x40031000 0x1000>; |
|
... |
|
native-endian; |
|
}; |
|
|
|
Scenario 2 : CPU in LE mode & device in BE mode. |
|
dev: dev@40031000 { |
|
compatible = "name"; |
|
reg = <0x40031000 0x1000>; |
|
... |
|
big-endian; |
|
}; |
|
|
|
Scenario 3 : CPU in BE mode & device in BE mode. |
|
dev: dev@40031000 { |
|
compatible = "name"; |
|
reg = <0x40031000 0x1000>; |
|
... |
|
native-endian; |
|
}; |
|
|
|
Scenario 4 : CPU in BE mode & device in LE mode. |
|
dev: dev@40031000 { |
|
compatible = "name"; |
|
reg = <0x40031000 0x1000>; |
|
... |
|
little-endian; |
|
}; |
|
|
|
Daisy-chained devices |
|
--------------------- |
|
|
|
Many serially-attached GPIO and IIO devices are daisy-chainable. To the |
|
host controller, a daisy-chain appears as a single device, but the number |
|
of inputs and outputs it provides is the sum of inputs and outputs provided |
|
by all of its devices. The driver needs to know how many devices the |
|
daisy-chain comprises to determine the amount of data exchanged, how many |
|
inputs and outputs to register and so on. |
|
|
|
Optional properties: |
|
- #daisy-chained-devices: Number of devices in the daisy-chain (default is 1). |
|
|
|
Example: |
|
gpio@0 { |
|
compatible = "name"; |
|
reg = <0>; |
|
gpio-controller; |
|
#gpio-cells = <2>; |
|
#daisy-chained-devices = <3>; |
|
};
|
|
|