mirror of
https://github.com/Evolution-X-Devices/kernel_xiaomi_sm8450-devicetrees
synced 2026-02-01 08:51:30 +00:00
b0e5152a74
Add devicetree bindings snapshot to the devicetree project.
This snapshot is taken as of the
'commit 5fba1b18cfc72e264e5f3ce49020ed322aa6ac9f ("Merge 5.6-rc3
into android-mainline")' of the kernel project.
Change-Id: Ia087ab2b7d4a2616ea446a69683a8b5b821d0448
86 lines
2.8 KiB
Plaintext
86 lines
2.8 KiB
Plaintext
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>;
|
|
};
|