diff options
author | David S. Miller <davem@davemloft.net> | 2014-10-02 14:25:43 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2014-10-02 14:25:43 -0400 |
commit | 739e4a758e0e2930f4bcdddd244254bae8dd7499 (patch) | |
tree | 0179d038669ad55591ae05a90b210d7090edf56e /Documentation | |
parent | d068b02cfdfc27f5962ec82ec5568b706f599edc (diff) | |
parent | 50dddff3cb9af328dd42bafe3437c7f47e8b38a9 (diff) |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Conflicts:
drivers/net/usb/r8152.c
net/netfilter/nfnetlink.c
Both r8152 and nfnetlink conflicts were simple overlapping changes.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/cgroups/cpusets.txt | 6 | ||||
-rw-r--r-- | Documentation/devicetree/bindings/staging/imx-drm/ldb.txt | 15 | ||||
-rw-r--r-- | Documentation/devicetree/of_selftest.txt | 211 |
3 files changed, 227 insertions, 5 deletions
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 7740038d82bc..3c94ff3f9693 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt | |||
@@ -345,14 +345,14 @@ the named feature on. | |||
345 | The implementation is simple. | 345 | The implementation is simple. |
346 | 346 | ||
347 | Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag | 347 | Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag |
348 | PF_SPREAD_PAGE for each task that is in that cpuset or subsequently | 348 | PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently |
349 | joins that cpuset. The page allocation calls for the page cache | 349 | joins that cpuset. The page allocation calls for the page cache |
350 | is modified to perform an inline check for this PF_SPREAD_PAGE task | 350 | is modified to perform an inline check for this PFA_SPREAD_PAGE task |
351 | flag, and if set, a call to a new routine cpuset_mem_spread_node() | 351 | flag, and if set, a call to a new routine cpuset_mem_spread_node() |
352 | returns the node to prefer for the allocation. | 352 | returns the node to prefer for the allocation. |
353 | 353 | ||
354 | Similarly, setting 'cpuset.memory_spread_slab' turns on the flag | 354 | Similarly, setting 'cpuset.memory_spread_slab' turns on the flag |
355 | PF_SPREAD_SLAB, and appropriately marked slab caches will allocate | 355 | PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate |
356 | pages from the node returned by cpuset_mem_spread_node(). | 356 | pages from the node returned by cpuset_mem_spread_node(). |
357 | 357 | ||
358 | The cpuset_mem_spread_node() routine is also simple. It uses the | 358 | The cpuset_mem_spread_node() routine is also simple. It uses the |
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt index 578a1fca366e..443bcb6134d5 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt | |||
@@ -56,6 +56,9 @@ Required properties: | |||
56 | - fsl,data-width : should be <18> or <24> | 56 | - fsl,data-width : should be <18> or <24> |
57 | - port: A port node with endpoint definitions as defined in | 57 | - port: A port node with endpoint definitions as defined in |
58 | Documentation/devicetree/bindings/media/video-interfaces.txt. | 58 | Documentation/devicetree/bindings/media/video-interfaces.txt. |
59 | On i.MX5, the internal two-input-multiplexer is used. | ||
60 | Due to hardware limitations, only one port (port@[0,1]) | ||
61 | can be used for each channel (lvds-channel@[0,1], respectively) | ||
59 | On i.MX6, there should be four ports (port@[0-3]) that correspond | 62 | On i.MX6, there should be four ports (port@[0-3]) that correspond |
60 | to the four LVDS multiplexer inputs. | 63 | to the four LVDS multiplexer inputs. |
61 | 64 | ||
@@ -78,6 +81,8 @@ ldb: ldb@53fa8008 { | |||
78 | "di0", "di1"; | 81 | "di0", "di1"; |
79 | 82 | ||
80 | lvds-channel@0 { | 83 | lvds-channel@0 { |
84 | #address-cells = <1>; | ||
85 | #size-cells = <0>; | ||
81 | reg = <0>; | 86 | reg = <0>; |
82 | fsl,data-mapping = "spwg"; | 87 | fsl,data-mapping = "spwg"; |
83 | fsl,data-width = <24>; | 88 | fsl,data-width = <24>; |
@@ -86,7 +91,9 @@ ldb: ldb@53fa8008 { | |||
86 | /* ... */ | 91 | /* ... */ |
87 | }; | 92 | }; |
88 | 93 | ||
89 | port { | 94 | port@0 { |
95 | reg = <0>; | ||
96 | |||
90 | lvds0_in: endpoint { | 97 | lvds0_in: endpoint { |
91 | remote-endpoint = <&ipu_di0_lvds0>; | 98 | remote-endpoint = <&ipu_di0_lvds0>; |
92 | }; | 99 | }; |
@@ -94,6 +101,8 @@ ldb: ldb@53fa8008 { | |||
94 | }; | 101 | }; |
95 | 102 | ||
96 | lvds-channel@1 { | 103 | lvds-channel@1 { |
104 | #address-cells = <1>; | ||
105 | #size-cells = <0>; | ||
97 | reg = <1>; | 106 | reg = <1>; |
98 | fsl,data-mapping = "spwg"; | 107 | fsl,data-mapping = "spwg"; |
99 | fsl,data-width = <24>; | 108 | fsl,data-width = <24>; |
@@ -102,7 +111,9 @@ ldb: ldb@53fa8008 { | |||
102 | /* ... */ | 111 | /* ... */ |
103 | }; | 112 | }; |
104 | 113 | ||
105 | port { | 114 | port@1 { |
115 | reg = <1>; | ||
116 | |||
106 | lvds1_in: endpoint { | 117 | lvds1_in: endpoint { |
107 | remote-endpoint = <&ipu_di1_lvds1>; | 118 | remote-endpoint = <&ipu_di1_lvds1>; |
108 | }; | 119 | }; |
diff --git a/Documentation/devicetree/of_selftest.txt b/Documentation/devicetree/of_selftest.txt new file mode 100644 index 000000000000..3a2f54d07fc5 --- /dev/null +++ b/Documentation/devicetree/of_selftest.txt | |||
@@ -0,0 +1,211 @@ | |||
1 | Open Firmware Device Tree Selftest | ||
2 | ---------------------------------- | ||
3 | |||
4 | Author: Gaurav Minocha <gaurav.minocha.os@gmail.com> | ||
5 | |||
6 | 1. Introduction | ||
7 | |||
8 | This document explains how the test data required for executing OF selftest | ||
9 | is attached to the live tree dynamically, independent of the machine's | ||
10 | architecture. | ||
11 | |||
12 | It is recommended to read the following documents before moving ahead. | ||
13 | |||
14 | [1] Documentation/devicetree/usage-model.txt | ||
15 | [2] http://www.devicetree.org/Device_Tree_Usage | ||
16 | |||
17 | OF Selftest has been designed to test the interface (include/linux/of.h) | ||
18 | provided to device driver developers to fetch the device information..etc. | ||
19 | from the unflattened device tree data structure. This interface is used by | ||
20 | most of the device drivers in various use cases. | ||
21 | |||
22 | |||
23 | 2. Test-data | ||
24 | |||
25 | The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains | ||
26 | the test data required for executing the unit tests automated in | ||
27 | drivers/of/selftests.c. Currently, following Device Tree Source Include files | ||
28 | (.dtsi) are included in testcase.dts: | ||
29 | |||
30 | drivers/of/testcase-data/tests-interrupts.dtsi | ||
31 | drivers/of/testcase-data/tests-platform.dtsi | ||
32 | drivers/of/testcase-data/tests-phandle.dtsi | ||
33 | drivers/of/testcase-data/tests-match.dtsi | ||
34 | |||
35 | When the kernel is build with OF_SELFTEST enabled, then the following make rule | ||
36 | |||
37 | $(obj)/%.dtb: $(src)/%.dts FORCE | ||
38 | $(call if_changed_dep, dtc) | ||
39 | |||
40 | is used to compile the DT source file (testcase.dts) into a binary blob | ||
41 | (testcase.dtb), also referred as flattened DT. | ||
42 | |||
43 | After that, using the following rule the binary blob above is wrapped as an | ||
44 | assembly file (testcase.dtb.S). | ||
45 | |||
46 | $(obj)/%.dtb.S: $(obj)/%.dtb | ||
47 | $(call cmd, dt_S_dtb) | ||
48 | |||
49 | The assembly file is compiled into an object file (testcase.dtb.o), and is | ||
50 | linked into the kernel image. | ||
51 | |||
52 | |||
53 | 2.1. Adding the test data | ||
54 | |||
55 | Un-flattened device tree structure: | ||
56 | |||
57 | Un-flattened device tree consists of connected device_node(s) in form of a tree | ||
58 | structure described below. | ||
59 | |||
60 | // following struct members are used to construct the tree | ||
61 | struct device_node { | ||
62 | ... | ||
63 | struct device_node *parent; | ||
64 | struct device_node *child; | ||
65 | struct device_node *sibling; | ||
66 | struct device_node *allnext; /* next in list of all nodes */ | ||
67 | ... | ||
68 | }; | ||
69 | |||
70 | Figure 1, describes a generic structure of machine’s un-flattened device tree | ||
71 | considering only child and sibling pointers. There exists another pointer, | ||
72 | *parent, that is used to traverse the tree in the reverse direction. So, at | ||
73 | a particular level the child node and all the sibling nodes will have a parent | ||
74 | pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4’s | ||
75 | parent points to root node) | ||
76 | |||
77 | root (‘/’) | ||
78 | | | ||
79 | child1 -> sibling2 -> sibling3 -> sibling4 -> null | ||
80 | | | | | | ||
81 | | | | null | ||
82 | | | | | ||
83 | | | child31 -> sibling32 -> null | ||
84 | | | | | | ||
85 | | | null null | ||
86 | | | | ||
87 | | child21 -> sibling22 -> sibling23 -> null | ||
88 | | | | | | ||
89 | | null null null | ||
90 | | | ||
91 | child11 -> sibling12 -> sibling13 -> sibling14 -> null | ||
92 | | | | | | ||
93 | | | | null | ||
94 | | | | | ||
95 | null null child131 -> null | ||
96 | | | ||
97 | null | ||
98 | |||
99 | Figure 1: Generic structure of un-flattened device tree | ||
100 | |||
101 | |||
102 | *allnext: it is used to link all the nodes of DT into a list. So, for the | ||
103 | above tree the list would be as follows: | ||
104 | |||
105 | root->child1->child11->sibling12->sibling13->child131->sibling14->sibling2-> | ||
106 | child21->sibling22->sibling23->sibling3->child31->sibling32->sibling4->null | ||
107 | |||
108 | Before executing OF selftest, it is required to attach the test data to | ||
109 | machine's device tree (if present). So, when selftest_data_add() is called, | ||
110 | at first it reads the flattened device tree data linked into the kernel image | ||
111 | via the following kernel symbols: | ||
112 | |||
113 | __dtb_testcases_begin - address marking the start of test data blob | ||
114 | __dtb_testcases_end - address marking the end of test data blob | ||
115 | |||
116 | Secondly, it calls of_fdt_unflatten_device_tree() to unflatten the flattened | ||
117 | blob. And finally, if the machine’s device tree (i.e live tree) is present, | ||
118 | then it attaches the unflattened test data tree to the live tree, else it | ||
119 | attaches itself as a live device tree. | ||
120 | |||
121 | attach_node_and_children() uses of_attach_node() to attach the nodes into the | ||
122 | live tree as explained below. To explain the same, the test data tree described | ||
123 | in Figure 2 is attached to the live tree described in Figure 1. | ||
124 | |||
125 | root (‘/’) | ||
126 | | | ||
127 | testcase-data | ||
128 | | | ||
129 | test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null | ||
130 | | | | | | ||
131 | test-child01 null null null | ||
132 | |||
133 | |||
134 | allnext list: | ||
135 | |||
136 | root->testcase-data->test-child0->test-child01->test-sibling1->test-sibling2 | ||
137 | ->test-sibling3->null | ||
138 | |||
139 | Figure 2: Example test data tree to be attached to live tree. | ||
140 | |||
141 | According to the scenario above, the live tree is already present so it isn’t | ||
142 | required to attach the root(‘/’) node. All other nodes are attached by calling | ||
143 | of_attach_node() on each node. | ||
144 | |||
145 | In the function of_attach_node(), the new node is attached as the child of the | ||
146 | given parent in live tree. But, if parent already has a child then the new node | ||
147 | replaces the current child and turns it into its sibling. So, when the testcase | ||
148 | data node is attached to the live tree above (Figure 1), the final structure is | ||
149 | as shown in Figure 3. | ||
150 | |||
151 | root (‘/’) | ||
152 | | | ||
153 | testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null | ||
154 | | | | | | | ||
155 | (...) | | | null | ||
156 | | | child31 -> sibling32 -> null | ||
157 | | | | | | ||
158 | | | null null | ||
159 | | | | ||
160 | | child21 -> sibling22 -> sibling23 -> null | ||
161 | | | | | | ||
162 | | null null null | ||
163 | | | ||
164 | child11 -> sibling12 -> sibling13 -> sibling14 -> null | ||
165 | | | | | | ||
166 | null null | null | ||
167 | | | ||
168 | child131 -> null | ||
169 | | | ||
170 | null | ||
171 | ----------------------------------------------------------------------- | ||
172 | |||
173 | root (‘/’) | ||
174 | | | ||
175 | testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null | ||
176 | | | | | | | ||
177 | | (...) (...) (...) null | ||
178 | | | ||
179 | test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null | ||
180 | | | | | | ||
181 | null null null test-child01 | ||
182 | |||
183 | |||
184 | Figure 3: Live device tree structure after attaching the testcase-data. | ||
185 | |||
186 | |||
187 | Astute readers would have noticed that test-child0 node becomes the last | ||
188 | sibling compared to the earlier structure (Figure 2). After attaching first | ||
189 | test-child0 the test-sibling1 is attached that pushes the child node | ||
190 | (i.e. test-child0) to become a sibling and makes itself a child node, | ||
191 | as mentioned above. | ||
192 | |||
193 | If a duplicate node is found (i.e. if a node with same full_name property is | ||
194 | already present in the live tree), then the node isn’t attached rather its | ||
195 | properties are updated to the live tree’s node by calling the function | ||
196 | update_node_properties(). | ||
197 | |||
198 | |||
199 | 2.2. Removing the test data | ||
200 | |||
201 | Once the test case execution is complete, selftest_data_remove is called in | ||
202 | order to remove the device nodes attached initially (first the leaf nodes are | ||
203 | detached and then moving up the parent nodes are removed, and eventually the | ||
204 | whole tree). selftest_data_remove() calls detach_node_and_children() that uses | ||
205 | of_detach_node() to detach the nodes from the live device tree. | ||
206 | |||
207 | To detach a node, of_detach_node() first updates all_next linked list, by | ||
208 | attaching the previous node’s allnext to current node’s allnext pointer. And | ||
209 | then, it either updates the child pointer of given node’s parent to its | ||
210 | sibling or attaches the previous sibling to the given node’s sibling, as | ||
211 | appropriate. That is it :) | ||