1 menu "Generic Driver Options"
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
12 bool "Enable Driver Model for SPL"
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.
25 bool "Enable Driver Model for TPL"
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.
39 bool "Enable Driver Model for VPL"
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.
49 bool "Enable warnings in driver model"
53 Enable this to see warnings related to driver model.
55 Warnings may help with debugging, such as when expected devices do
56 not bind correctly. If the option is disabled, dm_warn() is compiled
57 out - it will do nothing when called.
60 bool "Enable warnings in driver model wuth SPL"
63 Enable this to see warnings related to driver model in SPL
65 The dm_warn() function can use up quite a bit of space for its
66 strings. By default this is disabled for SPL builds to save space.
68 Warnings may help with debugging, such as when expected devices do
69 not bind correctly. If the option is disabled, dm_warn() is compiled
70 out - it will do nothing when called.
73 bool "Enable debug messages in driver model core"
76 Say Y here if you want to compile in debug messages in DM core.
79 bool "Collect and show driver model stats"
83 Enable this to collect and display memory statistics about driver
84 model. This can help to figure out where all the memory is going and
85 to find optimisations.
87 To display the memory stats, use the 'dm mem' command.
90 bool "Collect and show driver model stats in SPL"
93 Enable this to collect and display memory statistics about driver
94 model. This can help to figure out where all the memory is going and
95 to find optimisations.
97 The stats are displayed just before SPL boots to the next phase.
99 config DM_DEVICE_REMOVE
100 bool "Support device removal"
104 We can save some code space by dropping support for removing a
107 Note that this may have undesirable results in the USB subsystem as
108 it causes unplugged devices to linger around in the dm-tree, and it
109 causes USB host controllers to not be stopped when booting the OS.
116 This enables support for generating events related to driver model
117 operations, such as prbing or removing a device. Subsystems can
118 register a 'spy' function that is called when the event occurs. Such
119 subsystems must select this option.
121 config SPL_DM_DEVICE_REMOVE
122 bool "Support device removal in SPL"
125 We can save some code space by dropping support for removing a
126 device. This is not normally required in SPL, so by default this
127 option is disabled for SPL.
130 bool "Support stdio registration"
134 Normally serial drivers register with stdio so that they can be used
135 as normal output devices. In SPL we don't normally use stdio, so
136 we can omit this feature.
139 bool "Support numbered aliases in device tree"
143 Most boards will have a '/aliases' node containing the path to
144 numbered devices (e.g. serial0 = &serial0). This feature can be
145 disabled if it is not required.
147 config SPL_DM_SEQ_ALIAS
148 bool "Support numbered aliases in device tree in SPL"
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.
155 config VPL_DM_SEQ_ALIAS
156 bool "Support numbered aliases in device tree in VPL"
160 Most boards will have a '/aliases' node containing the path to
161 numbered devices (e.g. serial0 = &serial0). This feature can be
162 disabled if it is not required, to save code space in VPL.
164 config SPL_DM_INLINE_OFNODE
165 bool "Inline some ofnode functions which are seldom used in SPL"
169 This applies to several ofnode functions (see ofnode.h) which are
170 seldom used. Inlining them can help reduce code size.
172 config TPL_DM_INLINE_OFNODE
173 bool "Inline some ofnode functions which are seldom used in TPL"
177 This applies to several ofnode functions (see ofnode.h) which are
178 seldom used. Inlining them can help reduce code size.
181 bool "Support per-device DMA constraints"
184 Enable this to extract per-device DMA constraints, only supported on
185 device-tree systems for now. This is needed in order translate
186 addresses on systems where different buses have different views of
187 the physical address space.
190 bool "Support register maps"
193 Hardware peripherals tend to have one or more sets of registers
194 which can be accessed to control the hardware. A register map
195 models this with a simple read/write interface. It can in principle
196 support any bus type (I2C, SPI) but so far this only supports
197 direct memory access.
200 bool "Support register maps in SPL"
203 Hardware peripherals tend to have one or more sets of registers
204 which can be accessed to control the hardware. A register map
205 models this with a simple read/write interface. It can in principle
206 support any bus type (I2C, SPI) but so far this only supports
207 direct memory access.
210 bool "Support register maps in TPL"
213 Hardware peripherals tend to have one or more sets of registers
214 which can be accessed to control the hardware. A register map
215 models this with a simple read/write interface. It can in principle
216 support any bus type (I2C, SPI) but so far this only supports
217 direct memory access.
220 bool "Support register maps in VPL"
223 Hardware peripherals tend to have one or more sets of registers
224 which can be accessed to control the hardware. A register map
225 models this with a simple read/write interface. It can in principle
226 support any bus type (I2C, SPI) but so far this only supports
227 direct memory access.
230 bool "Support system controllers"
233 Many SoCs have a number of system controllers which are dealt with
234 as a group by a single driver. Some common functionality is provided
235 by this uclass, including accessing registers via regmap and
236 assigning a unique number to each.
239 bool "Support system controllers in SPL"
240 depends on SPL_REGMAP
242 Many SoCs have a number of system controllers which are dealt with
243 as a group by a single driver. Some common functionality is provided
244 by this uclass, including accessing registers via regmap and
245 assigning a unique number to each.
248 bool "Support system controllers in TPL"
249 depends on TPL_REGMAP
251 Many SoCs have a number of system controllers which are dealt with
252 as a group by a single driver. Some common functionality is provided
253 by this uclass, including accessing registers via regmap and
254 assigning a unique number to each.
257 bool "Support system controllers in VPL"
258 depends on VPL_REGMAP
260 Many SoCs have a number of system controllers which are dealt with
261 as a group by a single driver. Some common functionality is provided
262 by this uclass, including accessing registers via regmap and
263 assigning a unique number to each.
266 bool "Managed device resources"
269 This option enables the Managed device resources core support.
270 Device resources managed by the devres framework are automatically
271 released whether initialization fails half-way or the device gets
274 If this option is disabled, devres functions fall back to
275 non-managed variants. For example, devres_alloc() to kzalloc(),
276 devm_kmalloc() to kmalloc(), etc.
279 bool "Managed device resources debugging functions"
282 If this option is enabled, devres debug messages are printed.
283 Also, a function is available to dump a list of device resources.
284 Select this if you are having a problem with devres or want to
285 debug resource management for a managed device.
287 If you are unsure about this, Say N here.
290 bool "Support simple-bus driver"
291 depends on DM && OF_CONTROL
294 Supports the 'simple-bus' driver, which is used on some systems.
296 config SPL_SIMPLE_BUS
297 bool "Support simple-bus driver in SPL"
298 depends on SPL_DM && SPL_OF_CONTROL
301 Supports the 'simple-bus' driver, which is used on some systems
304 config TPL_SIMPLE_BUS
305 bool "Support simple-bus driver in TPL"
306 depends on TPL_DM && TPL_OF_CONTROL
308 Supports the 'simple-bus' driver, which is used on some systems
311 config SIMPLE_BUS_CORRECT_RANGE
312 bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells"
313 depends on SIMPLE_BUS
316 Decoding the 'simple-bus' <range> by honoring the #address-cells
317 and #size-cells of parent/child bus. If unset, #address-cells of
318 parent bus is assumed to be 1, #address-cells and #size-cells of
319 child bus is also assumed to be 1, to save some spaces of using
320 an advanced API to decode the <range>, which benefits SPL image
321 builds that have size limits.
323 If you are unsure about this, Say N here.
326 bool "Support simple-pm-bus driver"
327 depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
329 Supports the 'simple-pm-bus' driver, which is used for busses that
330 have power domains and/or clocks which need to be enabled before use.
333 bool "Translate addresses using fdt_translate_address"
334 depends on DM && OF_CONTROL
337 If this option is enabled, the reg property will be translated
338 using the fdt_translate_address() function. This is necessary
339 on some platforms (e.g. MVEBU) using complex "ranges"
340 properties in many nodes. As this translation is not handled
341 correctly in the default simple_bus_translate() function.
343 If this option is not enabled, simple_bus_translate() will be
344 used for the address translation. This function is faster and
345 smaller in size than fdt_translate_address().
347 config SPL_OF_TRANSLATE
348 bool "Translate addresses using fdt_translate_address in SPL"
349 depends on SPL_DM && SPL_OF_CONTROL
351 If this option is enabled, the reg property will be translated
352 using the fdt_translate_address() function. This is necessary
353 on some platforms (e.g. MVEBU) using complex "ranges"
354 properties in many nodes. As this translation is not handled
355 correctly in the default simple_bus_translate() function.
357 If this option is not enabled, simple_bus_translate() will be
358 used for the address translation. This function is faster and
359 smaller in size than fdt_translate_address().
361 config TPL_OF_TRANSLATE
362 bool "Translate addresses using fdt_translate_address in TPL"
363 depends on TPL_DM && TPL_OF_CONTROL
365 If this option is enabled, the reg property will be translated
366 using the fdt_translate_address() function. This is necessary
367 on some platforms (e.g. MVEBU) using complex "ranges"
368 properties in many nodes. As this translation is not handled
369 correctly in the default simple_bus_translate() function.
371 If this option is not enabled, simple_bus_translate() will be
372 used for the address translation. This function is faster and
373 smaller in size than fdt_translate_address()
375 config VPL_OF_TRANSLATE
376 bool "Translate addresses using fdt_translate_address in SPL"
377 depends on SPL_DM && VPL_OF_CONTROL
379 If this option is enabled, the reg property will be translated
380 using the fdt_translate_address() function. This is necessary
381 on some platforms (e.g. MVEBU) using complex "ranges"
382 properties in many nodes. As this translation is not handled
383 correctly in the default simple_bus_translate() function.
385 If this option is not enabled, simple_bus_translate() will be
386 used for the address translation. This function is faster and
387 smaller in size than fdt_translate_address().
389 config TRANSLATION_OFFSET
390 bool "Platforms specific translation offset"
391 depends on DM && OF_CONTROL
393 Some platforms need a special address translation. Those
394 platforms (e.g. mvebu in SPL) can configure a translation
395 offset by enabling this option and setting the translation_offset
396 variable in the GD in their platform- / board-specific code.
400 depends on OF_TRANSLATE
402 Is this option is enabled then support for the ISA bus will
403 be included for addresses read from DT. This is something that
404 should be known to be required or not based upon the board
405 being targeted, and whether or not it makes use of an ISA bus.
407 The bus is matched based upon its node name equalling "isa". The
408 busses #address-cells should equal 2, with the first cell being
409 used to hold flags & flag 0x1 indicating that the address range
410 should be accessed using I/O port in/out accessors. The second
411 cell holds the offset into ISA bus address space. The #size-cells
412 property should equal 1, and of course holds the size of the
413 address range used by a device.
415 If this option is not enabled then support for the ISA bus is
416 not included and any such busses used in DT will be treated as
417 typical simple-bus compatible busses. This will lead to
418 mistranslation of device addresses, so ensure that this is
419 enabled if your board does include an ISA bus.
421 config DM_DEV_READ_INLINE
423 default y if !OF_LIVE
425 config OFNODE_MULTI_TREE
426 bool "Allow the ofnode interface to access any tree"
427 default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE
429 Normally U-Boot makes use of its control FDT, the one used to bind
430 devices and provide options. In some cases, U-Boot must also process
431 a separate FDT, e.g. one provided by the operating system, which
432 needs additions to the /chosen node.
434 This works fine with live tree (OF_LIVE), but with flat tree the
435 offset provided in ofnode is only useful with the control FDT. This
436 option adds a 'tree ID' to the offset, so that multiple trees can
437 be used. Call oftree_from_fdt() to register a new tree.
439 config OFNODE_MULTI_TREE_MAX
440 int "Maximum number of FDTs"
442 depends on OFNODE_MULTI_TREE
445 Sets the maximum number of device trees which can be used with the
446 ofnode interface when using flat trees (OF_LIVE). This is only
447 available in U-Boot proper and only after relocation.
450 bool "Support ACPI table generation in driver model"
452 default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
455 This option enables generation of ACPI tables using driver-model
456 devices. It adds a new operation struct to each driver, to support
457 things like generating device-specific tables and returning the ACPI
461 bool "Include bounce buffer API"
463 Some peripherals support DMA from a subset of physically
464 addressable memory only. To support such peripherals, the
465 bounce buffer API uses a temporary buffer: it copies data
466 to/from DMA regions while managing cache operations.
468 A second possible use of bounce buffers is their ability to
469 provide aligned buffers for DMA operations.