forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linu…
…x/kernel/git/glikely/linux Pull devicetree changes from Grant Likely: "Lots of activity in the devicetree code for v3.18. Most of it is related to getting all of the overlay support code in place, but there are other important things in there. Highlights: - OF_RECONFIG notifiers for SPI, I2C and Platform devices. Those subsystems can now respond to live changes to the device tree. - CONFIG_OF_OVERLAY method for applying live changes to the device tree - Removal of the of_allnodes list. This used to be used to iterate over all the nodes in the device tree, but it is unnecessary because the same thing can be done by iterating over the list of child pointers. Getting rid of of_allnodes saves some memory and avoids the possibility of of_allnodes being sorted differently from the child lists. - Support for retrieving original DTB blob via sysfs. Needed by kexec. - More unittests - Documentation and minor bug fixes" * tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux: (42 commits) of: Delete unnecessary check before calling "of_node_put()" of: Drop ->next pointer from struct device_node spi: Check for spi_of_notifier when CONFIG_OF_DYNAMIC=y of: support passing console options with stdout-path of: add optional options parameter to of_find_node_by_path() of: Add bindings for chosen node, stdout-path of: Remove unneeded and incorrect MODULE_DEVICE_TABLE ARM: dt: fix up PL011 device tree bindings of: base, fix of_property_read_string_helper kernel-doc of: remove select of non-existant OF_DEVICE config symbol spi/of: Add OF notifier handler spi/of: Create new device registration method and accessors i2c/of: Add OF_RECONFIG notifier handler i2c/of: Factor out Devicetree registration code of/overlay: Add overlay unittests of/overlay: Introduce DT overlay support of/reconfig: Add OF_DYNAMIC notifier for platform_bus_type of/reconfig: Always use the same structure for notifiers of/reconfig: Add debug output for OF_RECONFIG notifiers of/reconfig: Add empty stubs for the of_reconfig methods ...
- Loading branch information
Showing
39 changed files
with
2,560 additions
and
523 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
The chosen node | ||
--------------- | ||
|
||
The chosen node does not represent a real device, but serves as a place | ||
for passing data between firmware and the operating system, like boot | ||
arguments. Data in the chosen node does not represent the hardware. | ||
|
||
|
||
stdout-path property | ||
-------------------- | ||
|
||
Device trees may specify the device to be used for boot console output | ||
with a stdout-path property under /chosen, as described in ePAPR, e.g. | ||
|
||
/ { | ||
chosen { | ||
stdout-path = "/serial@f00:115200"; | ||
}; | ||
|
||
serial@f00 { | ||
compatible = "vendor,some-uart"; | ||
reg = <0xf00 0x10>; | ||
}; | ||
}; | ||
|
||
If the character ":" is present in the value, this terminates the path. | ||
The meaning of any characters following the ":" is device-specific, and | ||
must be specified in the relevant binding documentation. | ||
|
||
For UART devices, the preferred binding is a string in the form: | ||
|
||
<baud>{<parity>{<bits>{<flow>}}} | ||
|
||
where | ||
|
||
baud - baud rate in decimal | ||
parity - 'n' (none), 'o', (odd) or 'e' (even) | ||
bits - number of data bits | ||
flow - 'r' (rts) | ||
|
||
For example: 115200n8r | ||
|
||
Implementation note: Linux will look for the property "linux,stdout-path" or | ||
on PowerPC "stdout" if "stdout-path" is not found. However, the | ||
"linux,stdout-path" and "stdout" properties are deprecated. New platforms | ||
should only use the "stdout-path" property. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
* OF selftest platform device | ||
|
||
** selftest | ||
|
||
Required properties: | ||
- compatible: must be "selftest" | ||
|
||
All other properties are optional. | ||
|
||
Example: | ||
selftest { | ||
compatible = "selftest"; | ||
status = "okay"; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,133 @@ | ||
Device Tree Overlay Notes | ||
------------------------- | ||
|
||
This document describes the implementation of the in-kernel | ||
device tree overlay functionality residing in drivers/of/overlay.c and is a | ||
companion document to Documentation/devicetree/dt-object-internal.txt[1] & | ||
Documentation/devicetree/dynamic-resolution-notes.txt[2] | ||
|
||
How overlays work | ||
----------------- | ||
|
||
A Device Tree's overlay purpose is to modify the kernel's live tree, and | ||
have the modification affecting the state of the the kernel in a way that | ||
is reflecting the changes. | ||
Since the kernel mainly deals with devices, any new device node that result | ||
in an active device should have it created while if the device node is either | ||
disabled or removed all together, the affected device should be deregistered. | ||
|
||
Lets take an example where we have a foo board with the following base tree | ||
which is taken from [1]. | ||
|
||
---- foo.dts ----------------------------------------------------------------- | ||
/* FOO platform */ | ||
/ { | ||
compatible = "corp,foo"; | ||
|
||
/* shared resources */ | ||
res: res { | ||
}; | ||
|
||
/* On chip peripherals */ | ||
ocp: ocp { | ||
/* peripherals that are always instantiated */ | ||
peripheral1 { ... }; | ||
} | ||
}; | ||
---- foo.dts ----------------------------------------------------------------- | ||
|
||
The overlay bar.dts, when loaded (and resolved as described in [2]) should | ||
|
||
---- bar.dts ----------------------------------------------------------------- | ||
/plugin/; /* allow undefined label references and record them */ | ||
/ { | ||
.... /* various properties for loader use; i.e. part id etc. */ | ||
fragment@0 { | ||
target = <&ocp>; | ||
__overlay__ { | ||
/* bar peripheral */ | ||
bar { | ||
compatible = "corp,bar"; | ||
... /* various properties and child nodes */ | ||
} | ||
}; | ||
}; | ||
}; | ||
---- bar.dts ----------------------------------------------------------------- | ||
|
||
result in foo+bar.dts | ||
|
||
---- foo+bar.dts ------------------------------------------------------------- | ||
/* FOO platform + bar peripheral */ | ||
/ { | ||
compatible = "corp,foo"; | ||
|
||
/* shared resources */ | ||
res: res { | ||
}; | ||
|
||
/* On chip peripherals */ | ||
ocp: ocp { | ||
/* peripherals that are always instantiated */ | ||
peripheral1 { ... }; | ||
|
||
/* bar peripheral */ | ||
bar { | ||
compatible = "corp,bar"; | ||
... /* various properties and child nodes */ | ||
} | ||
} | ||
}; | ||
---- foo+bar.dts ------------------------------------------------------------- | ||
|
||
As a result of the the overlay, a new device node (bar) has been created | ||
so a bar platform device will be registered and if a matching device driver | ||
is loaded the device will be created as expected. | ||
|
||
Overlay in-kernel API | ||
-------------------------------- | ||
|
||
The API is quite easy to use. | ||
|
||
1. Call of_overlay_create() to create and apply an overlay. The return value | ||
is a cookie identifying this overlay. | ||
|
||
2. Call of_overlay_destroy() to remove and cleanup the overlay previously | ||
created via the call to of_overlay_create(). Removal of an overlay that | ||
is stacked by another will not be permitted. | ||
|
||
Finally, if you need to remove all overlays in one-go, just call | ||
of_overlay_destroy_all() which will remove every single one in the correct | ||
order. | ||
|
||
Overlay DTS Format | ||
------------------ | ||
|
||
The DTS of an overlay should have the following format: | ||
|
||
{ | ||
/* ignored properties by the overlay */ | ||
|
||
fragment@0 { /* first child node */ | ||
|
||
target=<phandle>; /* phandle target of the overlay */ | ||
or | ||
target-path="/path"; /* target path of the overlay */ | ||
|
||
__overlay__ { | ||
property-a; /* add property-a to the target */ | ||
node-a { /* add to an existing, or create a node-a */ | ||
... | ||
}; | ||
}; | ||
} | ||
fragment@1 { /* second child node */ | ||
... | ||
}; | ||
/* more fragments follow */ | ||
} | ||
|
||
Using the non-phandle based target method allows one to use a base DT which does | ||
not contain a __symbols__ node, i.e. it was not compiled with the -@ option. | ||
The __symbols__ node is only required for the target=<phandle> method, since it | ||
contains the information required to map from a phandle to a tree location. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.