1menu "Generic Driver Options"
2
3config DM
4	def_bool y
5	help
6	  This config option enables Driver Model. This brings in the core
7	  support, including scanning of platform data on start-up. If
8	  CONFIG_OF_CONTROL is enabled, the device tree will be scanned also
9	  when available.
10
11config SPL_DM
12	bool "Enable Driver Model for SPL"
13	depends on DM && SPL
14	help
15	  Enable driver model in SPL. You will need to provide a
16	  suitable malloc() implementation. If you are not using the
17	  full malloc() enabled by CFG_SPL_SYS_MALLOC_START,
18	  consider using CONFIG_SPL_SYS_MALLOC_SIMPLE. In that case you
19	  must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
20	  In most cases driver model will only allocate a few uclasses
21	  and devices in SPL, so 1KB should be enough. See
22	  CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
23
24config TPL_DM
25	bool "Enable Driver Model for TPL"
26	depends on DM && TPL
27	help
28	  Enable driver model in TPL. You will need to provide a
29	  suitable malloc() implementation. If you are not using the
30	  full malloc() enabled by CFG_TPL_SYS_MALLOC_START,
31	  consider using CONFIG_TPL_SYS_MALLOC_SIMPLE. In that case you
32	  must provide CONFIG_TPL_SYS_MALLOC_F_LEN to set the size.
33	  In most cases driver model will only allocate a few uclasses
34	  and devices in TPL, so 1KB should be enough. See
35	  CONFIG_TPL_SYS_MALLOC_F_LEN for more details on how to enable it.
36	  Disable this for very small implementations.
37
38config VPL_DM
39	bool "Enable Driver Model for VPL"
40	depends on DM && VPL
41	default y if SPL_DM
42	help
43	  Enable driver model in VPL. You will need to provide a
44	  suitable malloc() implementation. If you are not using the
45	  full malloc() enabled by CFG_TPL_SYS_MALLOC_START,
46	  consider using CONFIG_TPL_SYS_MALLOC_SIMPLE.
47
48config DM_WARN
49	bool "Enable warnings in driver model"
50	depends on DM
51	help
52	  Enable this to see warnings related to driver model.
53
54	  Warnings may help with debugging, such as when expected devices do
55	  not bind correctly. If the option is disabled, dm_warn() is compiled
56	  out - it will do nothing when called.
57
58config SPL_DM_WARN
59	bool "Enable warnings in driver model in SPL"
60	depends on SPL_DM
61	help
62	  Enable this to see warnings related to driver model in SPL
63
64	  The dm_warn() function can use up quite a bit of space for its
65	  strings. By default this is disabled for SPL builds to save space.
66
67	  Warnings may help with debugging, such as when expected devices do
68	  not bind correctly. If the option is disabled, dm_warn() is compiled
69	  out - it will do nothing when called.
70
71config DM_DEBUG
72	bool "Enable debug messages in driver model core"
73	depends on DM
74	help
75	  Say Y here if you want to compile in debug messages in DM core.
76
77config DM_STATS
78	bool "Collect and show driver model stats"
79	depends on DM
80	default y if SANDBOX
81	help
82	  Enable this to collect and display memory statistics about driver
83	  model. This can help to figure out where all the memory is going and
84	  to find optimisations.
85
86	  To display the memory stats, use the 'dm mem' command.
87
88config SPL_DM_STATS
89	bool "Collect and show driver model stats in SPL"
90	depends on SPL_DM
91	help
92	  Enable this to collect and display memory statistics about driver
93	  model. This can help to figure out where all the memory is going and
94	  to find optimisations.
95
96	  The stats are displayed just before SPL boots to the next phase.
97
98config DM_DEVICE_REMOVE
99	bool "Support device removal"
100	depends on DM
101	default y
102	help
103	  We can save some code space by dropping support for removing a
104	  device.
105
106	  Note that this may have undesirable results in the USB subsystem as
107	  it causes unplugged devices to linger around in the dm-tree, and it
108	  causes USB host controllers to not be stopped when booting the OS.
109
110config DM_EVENT
111	bool
112	depends on DM
113	select EVENT
114	help
115	  This enables support for generating events related to driver model
116	  operations, such as probing or removing a device. Subsystems can
117	  register a 'spy' function that is called when the event occurs. Such
118	  subsystems must select this option.
119
120config SPL_DM_DEVICE_REMOVE
121	bool "Support device removal in SPL"
122	depends on SPL_DM
123	help
124	  We can save some code space by dropping support for removing a
125	  device. This is not normally required in SPL, so by default this
126	  option is disabled for SPL.
127
128config DM_STDIO
129	bool "Support stdio registration"
130	depends on DM
131	default y
132	help
133	  Normally serial drivers register with stdio so that they can be used
134	  as normal output devices. In SPL we don't normally use stdio, so
135	  we can omit this feature.
136
137config DM_SEQ_ALIAS
138	bool "Support numbered aliases in device tree"
139	depends on DM
140	default y
141	help
142	  Most boards will have a '/aliases' node containing the path to
143	  numbered devices (e.g. serial0 = &serial0). This feature can be
144	  disabled if it is not required.
145
146config SPL_DM_SEQ_ALIAS
147	bool "Support numbered aliases in device tree in SPL"
148	depends on SPL_DM
149	select SPL_STRTO
150	help
151	  Most boards will have a '/aliases' node containing the path to
152	  numbered devices (e.g. serial0 = &serial0). This feature can be
153	  disabled if it is not required, to save code space in SPL.
154
155config TPL_DM_SEQ_ALIAS
156	bool "Support numbered aliases in device tree in TPL"
157	depends on TPL_DM
158	help
159	  Most boards will have a '/aliases' node containing the path to
160	  numbered devices (e.g. serial0 = &serial0). This feature can be
161	  disabled if it is not required, to save code space in SPL.
162
163config VPL_DM_SEQ_ALIAS
164	bool "Support numbered aliases in device tree in VPL"
165	depends on VPL_DM
166	default y
167	help
168	  Most boards will have a '/aliases' node containing the path to
169	  numbered devices (e.g. serial0 = &serial0). This feature can be
170	  disabled if it is not required, to save code space in VPL.
171
172config SPL_DM_INLINE_OFNODE
173	bool "Inline some ofnode functions which are seldom used in SPL"
174	depends on SPL_DM
175	default y
176	help
177	  This applies to several ofnode functions (see ofnode.h) which are
178	  seldom used. Inlining them can help reduce code size.
179
180config TPL_DM_INLINE_OFNODE
181	bool "Inline some ofnode functions which are seldom used in TPL"
182	depends on TPL_DM
183	default y
184	help
185	  This applies to several ofnode functions (see ofnode.h) which are
186	  seldom used. Inlining them can help reduce code size.
187
188config DM_DMA
189	bool "Support per-device DMA constraints"
190	depends on DM
191	help
192	  Enable this to extract per-device DMA constraints, only supported on
193	  device-tree systems for now. This is needed in order translate
194	  addresses on systems where different buses have different views of
195	  the physical address space.
196
197config REGMAP
198	bool "Support register maps"
199	depends on DM
200	help
201	  Hardware peripherals tend to have one or more sets of registers
202	  which can be accessed to control the hardware. A register map
203	  models this with a simple read/write interface. It can in principle
204	  support any bus type (I2C, SPI) but so far this only supports
205	  direct memory access.
206
207config SPL_REGMAP
208	bool "Support register maps in SPL"
209	depends on SPL_DM
210	help
211	  Hardware peripherals tend to have one or more sets of registers
212	  which can be accessed to control the hardware. A register map
213	  models this with a simple read/write interface. It can in principle
214	  support any bus type (I2C, SPI) but so far this only supports
215	  direct memory access.
216
217config TPL_REGMAP
218	bool "Support register maps in TPL"
219	depends on TPL_DM
220	help
221	  Hardware peripherals tend to have one or more sets of registers
222	  which can be accessed to control the hardware. A register map
223	  models this with a simple read/write interface. It can in principle
224	  support any bus type (I2C, SPI) but so far this only supports
225	  direct memory access.
226
227config VPL_REGMAP
228	bool "Support register maps in VPL"
229	depends on VPL_DM
230	help
231	  Hardware peripherals tend to have one or more sets of registers
232	  which can be accessed to control the hardware. A register map
233	  models this with a simple read/write interface. It can in principle
234	  support any bus type (I2C, SPI) but so far this only supports
235	  direct memory access.
236
237config SYSCON
238	bool "Support system controllers"
239	depends on REGMAP
240	help
241	  Many SoCs have a number of system controllers which are dealt with
242	  as a group by a single driver. Some common functionality is provided
243	  by this uclass, including accessing registers via regmap and
244	  assigning a unique number to each.
245
246config SPL_SYSCON
247	bool "Support system controllers in SPL"
248	depends on SPL_REGMAP
249	help
250	  Many SoCs have a number of system controllers which are dealt with
251	  as a group by a single driver. Some common functionality is provided
252	  by this uclass, including accessing registers via regmap and
253	  assigning a unique number to each.
254
255config TPL_SYSCON
256	bool "Support system controllers in TPL"
257	depends on TPL_REGMAP
258	help
259	  Many SoCs have a number of system controllers which are dealt with
260	  as a group by a single driver. Some common functionality is provided
261	  by this uclass, including accessing registers via regmap and
262	  assigning a unique number to each.
263
264config VPL_SYSCON
265	bool "Support system controllers in VPL"
266	depends on VPL_REGMAP
267	help
268	  Many SoCs have a number of system controllers which are dealt with
269	  as a group by a single driver. Some common functionality is provided
270	  by this uclass, including accessing registers via regmap and
271	  assigning a unique number to each.
272
273config DEVRES
274	bool "Managed device resources"
275	depends on DM
276	help
277	  This option enables the Managed device resources core support.
278	  Device resources managed by the devres framework are automatically
279	  released whether initialization fails half-way or the device gets
280	  detached.
281
282	  If this option is disabled, devres functions fall back to
283	  non-managed variants.  For example, devres_alloc() to kzalloc(),
284	  devm_kmalloc() to kmalloc(), etc.
285
286config DEBUG_DEVRES
287	bool "Managed device resources debugging functions"
288	depends on DEVRES
289	help
290	  If this option is enabled, devres debug messages are printed.
291	  Also, a function is available to dump a list of device resources.
292	  Select this if you are having a problem with devres or want to
293	  debug resource management for a managed device.
294
295	  If you are unsure about this, Say N here.
296
297config SIMPLE_BUS
298	bool "Support simple-bus driver"
299	depends on DM && OF_CONTROL
300	default y
301	help
302	  Supports the 'simple-bus' driver, which is used on some systems.
303
304config SPL_SIMPLE_BUS
305	bool "Support simple-bus driver in SPL"
306	depends on SPL_DM && SPL_OF_CONTROL
307	default y
308	help
309	  Supports the 'simple-bus' driver, which is used on some systems
310	  in SPL.
311
312config TPL_SIMPLE_BUS
313	bool "Support simple-bus driver in TPL"
314	depends on TPL_DM && TPL_OF_CONTROL
315	help
316	  Supports the 'simple-bus' driver, which is used on some systems
317	  in TPL.
318
319config SIMPLE_BUS_CORRECT_RANGE
320	bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells"
321	depends on SIMPLE_BUS
322	default y if SANDBOX
323	help
324	  Decoding the 'simple-bus' <range> by honoring the #address-cells
325	  and #size-cells of parent/child bus. If unset, #address-cells of
326	  parent bus is assumed to be 1, #address-cells and #size-cells of
327	  child bus is also assumed to be 1, to save some spaces of using
328	  an advanced API to decode the <range>, which benefits SPL image
329	  builds that have size limits.
330
331	  If you are unsure about this, Say N here.
332
333config SIMPLE_PM_BUS
334	bool "Support simple-pm-bus driver"
335	depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
336	help
337	  Supports the 'simple-pm-bus' driver, which is used for busses that
338	  have power domains and/or clocks which need to be enabled before use.
339
340config OF_TRANSLATE
341	bool "Translate addresses using fdt_translate_address"
342	depends on DM && OF_CONTROL
343	default y
344	help
345	  If this option is enabled, the reg property will be translated
346	  using the fdt_translate_address() function. This is necessary
347	  on some platforms (e.g. MVEBU) using complex "ranges"
348	  properties in many nodes. As this translation is not handled
349	  correctly in the default simple_bus_translate() function.
350
351	  If this option is not enabled, simple_bus_translate() will be
352	  used for the address translation. This function is faster and
353	  smaller in size than fdt_translate_address().
354
355config SPL_OF_TRANSLATE
356	bool "Translate addresses using fdt_translate_address in SPL"
357	depends on SPL_DM && SPL_OF_CONTROL
358	help
359	  If this option is enabled, the reg property will be translated
360	  using the fdt_translate_address() function. This is necessary
361	  on some platforms (e.g. MVEBU) using complex "ranges"
362	  properties in many nodes. As this translation is not handled
363	  correctly in the default simple_bus_translate() function.
364
365	  If this option is not enabled, simple_bus_translate() will be
366	  used for the address translation. This function is faster and
367	  smaller in size than fdt_translate_address().
368
369config TPL_OF_TRANSLATE
370	bool "Translate addresses using fdt_translate_address in TPL"
371	depends on TPL_DM && TPL_OF_CONTROL
372	help
373	  If this option is enabled, the reg property will be translated
374	  using the fdt_translate_address() function. This is necessary
375	  on some platforms (e.g. MVEBU) using complex "ranges"
376	  properties in many nodes. As this translation is not handled
377	  correctly in the default simple_bus_translate() function.
378
379	  If this option is not enabled, simple_bus_translate() will be
380	  used for the address translation. This function is faster and
381	  smaller in size than fdt_translate_address()
382
383config VPL_OF_TRANSLATE
384	bool "Translate addresses using fdt_translate_address in SPL"
385	depends on SPL_DM && VPL_OF_CONTROL
386	help
387	  If this option is enabled, the reg property will be translated
388	  using the fdt_translate_address() function. This is necessary
389	  on some platforms (e.g. MVEBU) using complex "ranges"
390	  properties in many nodes. As this translation is not handled
391	  correctly in the default simple_bus_translate() function.
392
393	  If this option is not enabled, simple_bus_translate() will be
394	  used for the address translation. This function is faster and
395	  smaller in size than fdt_translate_address().
396
397config TRANSLATION_OFFSET
398	bool "Platforms specific translation offset"
399	depends on DM && OF_CONTROL
400	help
401	  Some platforms need a special address translation. Those
402	  platforms (e.g. mvebu in SPL) can configure a translation
403	  offset by enabling this option and setting the translation_offset
404	  variable in the GD in their platform- / board-specific code.
405
406config OF_ISA_BUS
407	bool
408	depends on OF_TRANSLATE
409	help
410	  Is this option is enabled then support for the ISA bus will
411	  be included for addresses read from DT. This is something that
412	  should be known to be required or not based upon the board
413	  being targeted, and whether or not it makes use of an ISA bus.
414
415	  The bus is matched based upon its node name equalling "isa". The
416	  busses #address-cells should equal 2, with the first cell being
417	  used to hold flags & flag 0x1 indicating that the address range
418	  should be accessed using I/O port in/out accessors. The second
419	  cell holds the offset into ISA bus address space. The #size-cells
420	  property should equal 1, and of course holds the size of the
421	  address range used by a device.
422
423	  If this option is not enabled then support for the ISA bus is
424	  not included and any such busses used in DT will be treated as
425	  typical simple-bus compatible busses. This will lead to
426	  mistranslation of device addresses, so ensure that this is
427	  enabled if your board does include an ISA bus.
428
429config DM_DEV_READ_INLINE
430	bool
431	default y if !OF_LIVE
432
433config OFNODE_MULTI_TREE
434	bool "Allow the ofnode interface to access any tree"
435	default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE
436	help
437	  Normally U-Boot makes use of its control FDT, the one used to bind
438	  devices and provide options. In some cases, U-Boot must also process
439	  a separate FDT, e.g. one provided by the operating system, which
440	  needs additions to the /chosen node.
441
442	  This works fine with live tree (OF_LIVE), but with flat tree the
443	  offset provided in ofnode is only useful with the control FDT. This
444	  option adds a 'tree ID' to the offset, so that multiple trees can
445	  be used. Call oftree_from_fdt() to register a new tree.
446
447config OFNODE_MULTI_TREE_MAX
448	int "Maximum number of FDTs"
449	range 2 8
450	depends on OFNODE_MULTI_TREE
451	default 4
452	help
453	  Sets the maximum number of device trees which can be used with the
454	  ofnode interface when using flat trees (OF_LIVE). This is only
455	  available in U-Boot proper and only after relocation.
456
457config ACPIGEN
458	bool "Support ACPI table generation in driver model"
459	depends on ACPI
460	default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
461	select LIB_UUID
462	help
463	  This option enables generation of ACPI tables using driver-model
464	  devices. It adds a new operation struct to each driver, to support
465	  things like generating device-specific tables and returning the ACPI
466	  name of a device.
467
468config BOUNCE_BUFFER
469	bool "Include bounce buffer API"
470	help
471	  Some peripherals support DMA from a subset of physically
472	  addressable memory only.  To support such peripherals, the
473	  bounce buffer API uses a temporary buffer: it copies data
474	  to/from DMA regions while managing cache operations.
475
476	  A second possible use of bounce buffers is their ability to
477	  provide aligned buffers for DMA operations.
478
479endmenu
480