About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / devicetree / bindings / bus / mvebu-mbus.txt




Custom Search

Based on kernel version 3.16. Page generated on 2014-08-06 21:36 EST.

1	
2	* Marvell MBus
3	
4	Required properties:
5	
6	- compatible:	 Should be set to one of the following:
7			 marvell,armada370-mbus
8			 marvell,armadaxp-mbus
9			 marvell,armada370-mbus
10			 marvell,armadaxp-mbus
11			 marvell,kirkwood-mbus
12			 marvell,dove-mbus
13			 marvell,orion5x-88f5281-mbus
14			 marvell,orion5x-88f5182-mbus
15			 marvell,orion5x-88f5181-mbus
16			 marvell,orion5x-88f6183-mbus
17			 marvell,mv78xx0-mbus
18	
19	- address-cells: Must be '2'. The first cell for the MBus ID encoding,
20	                 the second cell for the address offset within the window.
21	
22	- size-cells:    Must be '1'.
23	
24	- ranges:        Must be set up to provide a proper translation for each child.
25		         See the examples below.
26	
27	- controller:    Contains a single phandle referring to the MBus controller
28	                 node. This allows to specify the node that contains the
29			 registers that control the MBus, which is typically contained
30			 within the internal register window (see below).
31	
32	Optional properties:
33	
34	- pcie-mem-aperture:	This optional property contains the aperture for
35				the memory region of the PCIe driver.
36				If it's defined, it must encode the base address and
37				size for the address decoding windows allocated for
38				the PCIe memory region.
39	
40	- pcie-io-aperture:	Just as explained for the above property, this
41				optional property contains the aperture for the
42				I/O region of the PCIe driver.
43	
44	* Marvell MBus controller
45	
46	Required properties:
47	
48	- compatible:	Should be set to "marvell,mbus-controller".
49	
50	- reg:          Device's register space.
51			Two entries are expected (see the examples below):
52			the first one controls the devices decoding window and
53			the second one controls the SDRAM decoding window.
54	
55	Example:
56	
57		soc {
58			compatible = "marvell,armada370-mbus", "simple-bus";
59			#address-cells = <2>;
60			#size-cells = <1>;
61			controller = <&mbusc>;
62			pcie-mem-aperture = <0xe0000000 0x8000000>;
63			pcie-io-aperture  = <0xe8000000 0x100000>;
64	
65			internal-regs {
66				compatible = "simple-bus";
67	
68				mbusc: mbus-controller@20000 {
69					compatible = "marvell,mbus-controller";
70					reg = <0x20000 0x100>, <0x20180 0x20>;
71				};
72	
73				/* more children ...*/
74			};
75		};
76	
77	** MBus address decoding window specification
78	
79	The MBus children address space is comprised of two cells: the first one for
80	the window ID and the second one for the offset within the window.
81	In order to allow to describe valid and non-valid window entries, the
82	following encoding is used:
83	
84	  0xSIAA0000 0x00oooooo
85	
86	Where:
87	
88	  S = 0x0 for a MBus valid window
89	  S = 0xf for a non-valid window (see below)
90	
91	If S = 0x0, then:
92	
93	   I = 4-bit window target ID
94	  AA = windpw attribute
95	
96	If S = 0xf, then:
97	
98	   I = don't care
99	   AA = 1 for internal register
100	
101	Following the above encoding, for each ranges entry for a MBus valid window
102	(S = 0x0), an address decoding window is allocated. On the other side,
103	entries for translation that do not correspond to valid windows (S = 0xf)
104	are skipped.
105	
106		soc {
107			compatible = "marvell,armada370-mbus", "simple-bus";
108			#address-cells = <2>;
109			#size-cells = <1>;
110			controller = <&mbusc>;
111	
112			ranges = <0xf0010000 0 0 0xd0000000 0x100000
113				  0x01e00000 0 0 0xfff00000 0x100000>;
114	
115			bootrom {
116				compatible = "marvell,bootrom";
117				reg = <0x01e00000 0 0x100000>;
118			};
119	
120			/* other children */
121			...
122	
123			internal-regs {
124				compatible = "simple-bus";
125				ranges = <0 0xf0010000 0 0x100000>;
126	
127				mbusc: mbus-controller@20000 {
128					compatible = "marvell,mbus-controller";
129					reg = <0x20000 0x100>, <0x20180 0x20>;
130				};
131	
132				/* more children ...*/
133			};
134		};
135	
136	In the shown example, the translation entry in the 'ranges' property is what
137	makes the MBus driver create a static decoding window for the corresponding
138	given child device. Note that the binding does not require child nodes to be
139	present. Of course, child nodes are needed to probe the devices.
140	
141	Since each window is identified by its target ID and attribute ID there's
142	a special macro that can be use to simplify the translation entries:
143	
144	#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
145	
146	Using this macro, the above example would be:
147	
148		soc {
149			compatible = "marvell,armada370-mbus", "simple-bus";
150			#address-cells = <2>;
151			#size-cells = <1>;
152			controller = <&mbusc>;
153	
154			ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
155				   MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
156	
157			bootrom {
158				compatible = "marvell,bootrom";
159				reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
160			};
161	
162			/* other children */
163			...
164	
165			internal-regs {
166				compatible = "simple-bus";
167				#address-cells = <1>;
168				#size-cells = <1>;
169				ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
170	
171				mbusc: mbus-controller@20000 {
172					compatible = "marvell,mbus-controller";
173					reg = <0x20000 0x100>, <0x20180 0x20>;
174				};
175	
176				/* other children */
177				...
178			};
179		};
180	
181	
182	** About the window base address
183	
184	Remember the MBus controller allows a great deal of flexibility for choosing
185	the decoding window base address. When planning the device tree layout it's
186	possible to choose any address as the base address, provided of course there's
187	a region large enough available, and with the required alignment.
188	
189	Yet in other words: there's nothing preventing us from setting a base address
190	of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
191	unused.
192	
193	** Window allocation policy
194	
195	The mbus-node ranges property defines a set of mbus windows that are expected
196	to be set by the operating system and that are guaranteed to be free of overlaps
197	with one another or with the system memory ranges.
198	
199	Each entry in the property refers to exactly one window. If the operating system
200	chooses to use a different set of mbus windows, it must ensure that any address
201	translations performed from downstream devices are adapted accordingly.
202	
203	The operating system may insert additional mbus windows that do not conflict
204	with the ones listed in the ranges, e.g. for mapping PCIe devices.
205	As a special case, the internal register window must be set up by the boot
206	loader at the address listed in the ranges property, since access to that region
207	is needed to set up the other windows.
208	
209	** Example
210	
211	See the example below, where a more complete device tree is shown:
212	
213		soc {
214			compatible = "marvell,armadaxp-mbus", "simple-bus";
215			controller = <&mbusc>;
216	
217			ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000   /* internal-regs */
218				  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
219				  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
220	
221			bootrom {
222				compatible = "marvell,bootrom";
223				reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
224			};
225	
226			devbus-bootcs {
227				status = "okay";
228				ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
229	
230				/* NOR */
231				nor {
232					compatible = "cfi-flash";
233					reg = <0 0x8000000>;
234					bank-width = <2>;
235				};
236			};
237	
238			pcie-controller {
239				compatible = "marvell,armada-xp-pcie";
240				status = "okay";
241				device_type = "pci";
242	
243				#address-cells = <3>;
244				#size-cells = <2>;
245	
246				ranges =
247				       <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
248					0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000   /* Port 2.0 registers */
249					0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000   /* Port 0.1 registers */
250					0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000   /* Port 0.2 registers */
251					0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000   /* Port 0.3 registers */
252					0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
253					0x81000800 0 0          MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
254	
255	
256				pcie@1,0 {
257					/* Port 0, Lane 0 */
258					status = "okay";
259				};
260			};
261	
262			internal-regs {
263				compatible = "simple-bus";
264				#address-cells = <1>;
265				#size-cells = <1>;
266				ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
267	
268				mbusc: mbus-controller@20000 {
269					reg = <0x20000 0x100>, <0x20180 0x20>;
270				};
271	
272				interrupt-controller@20000 {
273				      reg = <0x20a00 0x2d0>, <0x21070 0x58>;
274				};
275			};
276		};
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.