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"
52 Enable this to see warnings related to driver model.
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.
59 bool "Enable warnings in driver model wuth SPL"
62 Enable this to see warnings related to driver model in SPL
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.
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.
72 bool "Enable debug messages in driver model core"
75 Say Y here if you want to compile in debug messages in DM core.
78 bool "Collect and show driver model stats"
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.
86 To display the memory stats, use the 'dm mem' command.
89 bool "Collect and show driver model stats in SPL"
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.
96 The stats are displayed just before SPL boots to the next phase.
98 config DM_DEVICE_REMOVE
99 bool "Support device removal"
103 We can save some code space by dropping support for removing a
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.
115 This enables support for generating events related to driver model
116 operations, such as prbing 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.
120 config SPL_DM_DEVICE_REMOVE
121 bool "Support device removal in SPL"
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.
129 bool "Support stdio registration"
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.
138 bool "Support numbered aliases in device tree"
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.
146 config SPL_DM_SEQ_ALIAS
147 bool "Support numbered aliases in device tree in SPL"
150 Most boards will have a '/aliases' node containing the path to
151 numbered devices (e.g. serial0 = &serial0). This feature can be
152 disabled if it is not required, to save code space in SPL.
154 config VPL_DM_SEQ_ALIAS
155 bool "Support numbered aliases in device tree in VPL"
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 VPL.
163 config SPL_DM_INLINE_OFNODE
164 bool "Inline some ofnode functions which are seldom used in SPL"
168 This applies to several ofnode functions (see ofnode.h) which are
169 seldom used. Inlining them can help reduce code size.
171 config TPL_DM_INLINE_OFNODE
172 bool "Inline some ofnode functions which are seldom used in TPL"
176 This applies to several ofnode functions (see ofnode.h) which are
177 seldom used. Inlining them can help reduce code size.
180 bool "Support per-device DMA constraints"
183 Enable this to extract per-device DMA constraints, only supported on
184 device-tree systems for now. This is needed in order translate
185 addresses on systems where different buses have different views of
186 the physical address space.
189 bool "Support register maps"
192 Hardware peripherals tend to have one or more sets of registers
193 which can be accessed to control the hardware. A register map
194 models this with a simple read/write interface. It can in principle
195 support any bus type (I2C, SPI) but so far this only supports
196 direct memory access.
199 bool "Support register maps in SPL"
202 Hardware peripherals tend to have one or more sets of registers
203 which can be accessed to control the hardware. A register map
204 models this with a simple read/write interface. It can in principle
205 support any bus type (I2C, SPI) but so far this only supports
206 direct memory access.
209 bool "Support register maps in TPL"
212 Hardware peripherals tend to have one or more sets of registers
213 which can be accessed to control the hardware. A register map
214 models this with a simple read/write interface. It can in principle
215 support any bus type (I2C, SPI) but so far this only supports
216 direct memory access.
219 bool "Support register maps in VPL"
222 Hardware peripherals tend to have one or more sets of registers
223 which can be accessed to control the hardware. A register map
224 models this with a simple read/write interface. It can in principle
225 support any bus type (I2C, SPI) but so far this only supports
226 direct memory access.
229 bool "Support system controllers"
232 Many SoCs have a number of system controllers which are dealt with
233 as a group by a single driver. Some common functionality is provided
234 by this uclass, including accessing registers via regmap and
235 assigning a unique number to each.
238 bool "Support system controllers in SPL"
239 depends on SPL_REGMAP
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.
247 bool "Support system controllers in TPL"
248 depends on TPL_REGMAP
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.
256 bool "Support system controllers in VPL"
257 depends on VPL_REGMAP
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.
265 bool "Managed device resources"
268 This option enables the Managed device resources core support.
269 Device resources managed by the devres framework are automatically
270 released whether initialization fails half-way or the device gets
273 If this option is disabled, devres functions fall back to
274 non-managed variants. For example, devres_alloc() to kzalloc(),
275 devm_kmalloc() to kmalloc(), etc.
278 bool "Managed device resources debugging functions"
281 If this option is enabled, devres debug messages are printed.
282 Also, a function is available to dump a list of device resources.
283 Select this if you are having a problem with devres or want to
284 debug resource management for a managed device.
286 If you are unsure about this, Say N here.
289 bool "Support simple-bus driver"
290 depends on DM && OF_CONTROL
293 Supports the 'simple-bus' driver, which is used on some systems.
295 config SPL_SIMPLE_BUS
296 bool "Support simple-bus driver in SPL"
297 depends on SPL_DM && SPL_OF_CONTROL
300 Supports the 'simple-bus' driver, which is used on some systems
303 config TPL_SIMPLE_BUS
304 bool "Support simple-bus driver in TPL"
305 depends on TPL_DM && TPL_OF_CONTROL
307 Supports the 'simple-bus' driver, which is used on some systems
310 config SIMPLE_BUS_CORRECT_RANGE
311 bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells"
312 depends on SIMPLE_BUS
315 Decoding the 'simple-bus' <range> by honoring the #address-cells
316 and #size-cells of parent/child bus. If unset, #address-cells of
317 parent bus is assumed to be 1, #address-cells and #size-cells of
318 child bus is also assumed to be 1, to save some spaces of using
319 an advanced API to decode the <range>, which benefits SPL image
320 builds that have size limits.
322 If you are unsure about this, Say N here.
325 bool "Support simple-pm-bus driver"
326 depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
328 Supports the 'simple-pm-bus' driver, which is used for busses that
329 have power domains and/or clocks which need to be enabled before use.
332 bool "Translate addresses using fdt_translate_address"
333 depends on DM && OF_CONTROL
336 If this option is enabled, the reg property will be translated
337 using the fdt_translate_address() function. This is necessary
338 on some platforms (e.g. MVEBU) using complex "ranges"
339 properties in many nodes. As this translation is not handled
340 correctly in the default simple_bus_translate() function.
342 If this option is not enabled, simple_bus_translate() will be
343 used for the address translation. This function is faster and
344 smaller in size than fdt_translate_address().
346 config SPL_OF_TRANSLATE
347 bool "Translate addresses using fdt_translate_address in SPL"
348 depends on SPL_DM && SPL_OF_CONTROL
350 If this option is enabled, the reg property will be translated
351 using the fdt_translate_address() function. This is necessary
352 on some platforms (e.g. MVEBU) using complex "ranges"
353 properties in many nodes. As this translation is not handled
354 correctly in the default simple_bus_translate() function.
356 If this option is not enabled, simple_bus_translate() will be
357 used for the address translation. This function is faster and
358 smaller in size than fdt_translate_address().
360 config TPL_OF_TRANSLATE
361 bool "Translate addresses using fdt_translate_address in TPL"
362 depends on TPL_DM && TPL_OF_CONTROL
364 If this option is enabled, the reg property will be translated
365 using the fdt_translate_address() function. This is necessary
366 on some platforms (e.g. MVEBU) using complex "ranges"
367 properties in many nodes. As this translation is not handled
368 correctly in the default simple_bus_translate() function.
370 If this option is not enabled, simple_bus_translate() will be
371 used for the address translation. This function is faster and
372 smaller in size than fdt_translate_address()
374 config VPL_OF_TRANSLATE
375 bool "Translate addresses using fdt_translate_address in SPL"
376 depends on SPL_DM && VPL_OF_CONTROL
378 If this option is enabled, the reg property will be translated
379 using the fdt_translate_address() function. This is necessary
380 on some platforms (e.g. MVEBU) using complex "ranges"
381 properties in many nodes. As this translation is not handled
382 correctly in the default simple_bus_translate() function.
384 If this option is not enabled, simple_bus_translate() will be
385 used for the address translation. This function is faster and
386 smaller in size than fdt_translate_address().
388 config TRANSLATION_OFFSET
389 bool "Platforms specific translation offset"
390 depends on DM && OF_CONTROL
392 Some platforms need a special address translation. Those
393 platforms (e.g. mvebu in SPL) can configure a translation
394 offset by enabling this option and setting the translation_offset
395 variable in the GD in their platform- / board-specific code.
399 depends on OF_TRANSLATE
401 Is this option is enabled then support for the ISA bus will
402 be included for addresses read from DT. This is something that
403 should be known to be required or not based upon the board
404 being targeted, and whether or not it makes use of an ISA bus.
406 The bus is matched based upon its node name equalling "isa". The
407 busses #address-cells should equal 2, with the first cell being
408 used to hold flags & flag 0x1 indicating that the address range
409 should be accessed using I/O port in/out accessors. The second
410 cell holds the offset into ISA bus address space. The #size-cells
411 property should equal 1, and of course holds the size of the
412 address range used by a device.
414 If this option is not enabled then support for the ISA bus is
415 not included and any such busses used in DT will be treated as
416 typical simple-bus compatible busses. This will lead to
417 mistranslation of device addresses, so ensure that this is
418 enabled if your board does include an ISA bus.
420 config DM_DEV_READ_INLINE
422 default y if !OF_LIVE
424 config OFNODE_MULTI_TREE
425 bool "Allow the ofnode interface to access any tree"
426 default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE
428 Normally U-Boot makes use of its control FDT, the one used to bind
429 devices and provide options. In some cases, U-Boot must also process
430 a separate FDT, e.g. one provided by the operating system, which
431 needs additions to the /chosen node.
433 This works fine with live tree (OF_LIVE), but with flat tree the
434 offset provided in ofnode is only useful with the control FDT. This
435 option adds a 'tree ID' to the offset, so that multiple trees can
436 be used. Call oftree_from_fdt() to register a new tree.
438 config OFNODE_MULTI_TREE_MAX
439 int "Maximum number of FDTs"
441 depends on OFNODE_MULTI_TREE
444 Sets the maximum number of device trees which can be used with the
445 ofnode interface when using flat trees (OF_LIVE). This is only
446 available in U-Boot proper and only after relocation.
449 bool "Support ACPI table generation in driver model"
451 default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
454 This option enables generation of ACPI tables using driver-model
455 devices. It adds a new operation struct to each driver, to support
456 things like generating device-specific tables and returning the ACPI
460 bool "Include bounce buffer API"
462 Some peripherals support DMA from a subset of physically
463 addressable memory only. To support such peripherals, the
464 bounce buffer API uses a temporary buffer: it copies data
465 to/from DMA regions while managing cache operations.
467 A second possible use of bounce buffers is their ability to
468 provide aligned buffers for DMA operations.