diff options
Diffstat (limited to 'roms/u-boot/drivers/core/Kconfig')
| -rw-r--r-- | roms/u-boot/drivers/core/Kconfig | 345 |
1 files changed, 345 insertions, 0 deletions
diff --git a/roms/u-boot/drivers/core/Kconfig b/roms/u-boot/drivers/core/Kconfig new file mode 100644 index 000000000..d618e1637 --- /dev/null +++ b/roms/u-boot/drivers/core/Kconfig @@ -0,0 +1,345 @@ +menu "Generic Driver Options" + +config DM + bool "Enable Driver Model" + help + This config option enables Driver Model. This brings in the core + support, including scanning of platform data on start-up. If + CONFIG_OF_CONTROL is enabled, the device tree will be scanned also + when available. + +config SPL_DM + bool "Enable Driver Model for SPL" + depends on DM && SPL + help + Enable driver model in SPL. You will need to provide a + suitable malloc() implementation. If you are not using the + full malloc() enabled by CONFIG_SYS_SPL_MALLOC_START, + consider using CONFIG_SYS_MALLOC_SIMPLE. In that case you + must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size. + In most cases driver model will only allocate a few uclasses + and devices in SPL, so 1KB should be enable. See + CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it. + +config TPL_DM + bool "Enable Driver Model for TPL" + depends on DM && TPL + help + Enable driver model in TPL. You will need to provide a + suitable malloc() implementation. If you are not using the + full malloc() enabled by CONFIG_SYS_SPL_MALLOC_START, + consider using CONFIG_SYS_MALLOC_SIMPLE. In that case you + must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size. + In most cases driver model will only allocate a few uclasses + and devices in SPL, so 1KB should be enough. See + CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it. + Disable this for very small implementations. + +config DM_WARN + bool "Enable warnings in driver model" + depends on DM + default y + help + Enable this to see warnings related to driver model. + + Warnings may help with debugging, such as when expected devices do + not bind correctly. If the option is disabled, dm_warn() is compiled + out - it will do nothing when called. + +config SPL_DM_WARN + bool "Enable warnings in driver model wuth SPL" + depends on SPL_DM + help + Enable this to see warnings related to driver model in SPL + + The dm_warn() function can use up quite a bit of space for its + strings. By default this is disabled for SPL builds to save space. + + Warnings may help with debugging, such as when expected devices do + not bind correctly. If the option is disabled, dm_warn() is compiled + out - it will do nothing when called. + +config DM_DEBUG + bool "Enable debug messages in driver model core" + depends on DM + help + Say Y here if you want to compile in debug messages in DM core. + +config DM_DEVICE_REMOVE + bool "Support device removal" + depends on DM + default y + help + We can save some code space by dropping support for removing a + device. + + Note that this may have undesirable results in the USB subsystem as + it causes unplugged devices to linger around in the dm-tree, and it + causes USB host controllers to not be stopped when booting the OS. + +config SPL_DM_DEVICE_REMOVE + bool "Support device removal in SPL" + depends on SPL_DM + default n + help + We can save some code space by dropping support for removing a + device. This is not normally required in SPL, so by default this + option is disabled for SPL. + +config DM_STDIO + bool "Support stdio registration" + depends on DM + default y + help + Normally serial drivers register with stdio so that they can be used + as normal output devices. In SPL we don't normally use stdio, so + we can omit this feature. + +config DM_SEQ_ALIAS + bool "Support numbered aliases in device tree" + depends on DM + default y + help + Most boards will have a '/aliases' node containing the path to + numbered devices (e.g. serial0 = &serial0). This feature can be + disabled if it is not required. + +config SPL_DM_SEQ_ALIAS + bool "Support numbered aliases in device tree in SPL" + depends on SPL_DM + default n + help + Most boards will have a '/aliases' node containing the path to + numbered devices (e.g. serial0 = &serial0). This feature can be + disabled if it is not required, to save code space in SPL. + +config SPL_DM_INLINE_OFNODE + bool "Inline some ofnode functions which are seldom used in SPL" + depends on SPL_DM + default y + help + This applies to several ofnode functions (see ofnode.h) which are + seldom used. Inlining them can help reduce code size. + +config TPL_DM_INLINE_OFNODE + bool "Inline some ofnode functions which are seldom used in TPL" + depends on TPL_DM + default y + help + This applies to several ofnode functions (see ofnode.h) which are + seldom used. Inlining them can help reduce code size. + +config DM_DMA + bool "Support per-device DMA constraints" + depends on DM + default n + help + Enable this to extract per-device DMA constraints, only supported on + device-tree systems for now. This is needed in order translate + addresses on systems where different buses have different views of + the physical address space. + +config REGMAP + bool "Support register maps" + depends on DM + help + Hardware peripherals tend to have one or more sets of registers + which can be accessed to control the hardware. A register map + models this with a simple read/write interface. It can in principle + support any bus type (I2C, SPI) but so far this only supports + direct memory access. + +config SPL_REGMAP + bool "Support register maps in SPL" + depends on SPL_DM + help + Hardware peripherals tend to have one or more sets of registers + which can be accessed to control the hardware. A register map + models this with a simple read/write interface. It can in principle + support any bus type (I2C, SPI) but so far this only supports + direct memory access. + +config TPL_REGMAP + bool "Support register maps in TPL" + depends on TPL_DM + help + Hardware peripherals tend to have one or more sets of registers + which can be accessed to control the hardware. A register map + models this with a simple read/write interface. It can in principle + support any bus type (I2C, SPI) but so far this only supports + direct memory access. + +config SYSCON + bool "Support system controllers" + depends on REGMAP + help + Many SoCs have a number of system controllers which are dealt with + as a group by a single driver. Some common functionality is provided + by this uclass, including accessing registers via regmap and + assigning a unique number to each. + +config SPL_SYSCON + bool "Support system controllers in SPL" + depends on SPL_REGMAP + help + Many SoCs have a number of system controllers which are dealt with + as a group by a single driver. Some common functionality is provided + by this uclass, including accessing registers via regmap and + assigning a unique number to each. + +config TPL_SYSCON + bool "Support system controllers in TPL" + depends on TPL_REGMAP + help + Many SoCs have a number of system controllers which are dealt with + as a group by a single driver. Some common functionality is provided + by this uclass, including accessing registers via regmap and + assigning a unique number to each. + +config DEVRES + bool "Managed device resources" + depends on DM + help + This option enables the Managed device resources core support. + Device resources managed by the devres framework are automatically + released whether initialization fails half-way or the device gets + detached. + + If this option is disabled, devres functions fall back to + non-managed variants. For example, devres_alloc() to kzalloc(), + devm_kmalloc() to kmalloc(), etc. + +config DEBUG_DEVRES + bool "Managed device resources debugging functions" + depends on DEVRES + help + If this option is enabled, devres debug messages are printed. + Also, a function is available to dump a list of device resources. + Select this if you are having a problem with devres or want to + debug resource management for a managed device. + + If you are unsure about this, Say N here. + +config SIMPLE_BUS + bool "Support simple-bus driver" + depends on DM && OF_CONTROL + default y + help + Supports the 'simple-bus' driver, which is used on some systems. + +config SPL_SIMPLE_BUS + bool "Support simple-bus driver in SPL" + depends on SPL_DM && SPL_OF_CONTROL + default y + help + Supports the 'simple-bus' driver, which is used on some systems + in SPL. + +config SIMPLE_BUS_CORRECT_RANGE + bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells" + depends on SIMPLE_BUS + default y if SANDBOX + help + Decoding the 'simple-bus' <range> by honoring the #address-cells + and #size-cells of parent/child bus. If unset, #address-cells of + parent bus is assumed to be 1, #address-cells and #size-cells of + child bus is also assumed to be 1, to save some spaces of using + an advanced API to decode the <range>, which benefits SPL image + builds that have size limits. + + If you are unsure about this, Say N here. + +config SIMPLE_PM_BUS + bool "Support simple-pm-bus driver" + depends on DM && OF_CONTROL && CLK && POWER_DOMAIN + help + Supports the 'simple-pm-bus' driver, which is used for busses that + have power domains and/or clocks which need to be enabled before use. + +config OF_TRANSLATE + bool "Translate addresses using fdt_translate_address" + depends on DM && OF_CONTROL + default y + help + If this option is enabled, the reg property will be translated + using the fdt_translate_address() function. This is necessary + on some platforms (e.g. MVEBU) using complex "ranges" + properties in many nodes. As this translation is not handled + correctly in the default simple_bus_translate() function. + + If this option is not enabled, simple_bus_translate() will be + used for the address translation. This function is faster and + smaller in size than fdt_translate_address(). + +config SPL_OF_TRANSLATE + bool "Translate addresses using fdt_translate_address in SPL" + depends on SPL_DM && SPL_OF_CONTROL + default n + help + If this option is enabled, the reg property will be translated + using the fdt_translate_address() function. This is necessary + on some platforms (e.g. MVEBU) using complex "ranges" + properties in many nodes. As this translation is not handled + correctly in the default simple_bus_translate() function. + + If this option is not enabled, simple_bus_translate() will be + used for the address translation. This function is faster and + smaller in size than fdt_translate_address(). + +config TRANSLATION_OFFSET + bool "Platforms specific translation offset" + depends on DM && OF_CONTROL + help + Some platforms need a special address translation. Those + platforms (e.g. mvebu in SPL) can configure a translation + offset by enabling this option and setting the translation_offset + variable in the GD in their platform- / board-specific code. + +config OF_ISA_BUS + bool + depends on OF_TRANSLATE + help + Is this option is enabled then support for the ISA bus will + be included for addresses read from DT. This is something that + should be known to be required or not based upon the board + being targeted, and whether or not it makes use of an ISA bus. + + The bus is matched based upon its node name equalling "isa". The + busses #address-cells should equal 2, with the first cell being + used to hold flags & flag 0x1 indicating that the address range + should be accessed using I/O port in/out accessors. The second + cell holds the offset into ISA bus address space. The #size-cells + property should equal 1, and of course holds the size of the + address range used by a device. + + If this option is not enabled then support for the ISA bus is + not included and any such busses used in DT will be treated as + typical simple-bus compatible busses. This will lead to + mistranslation of device addresses, so ensure that this is + enabled if your board does include an ISA bus. + +config DM_DEV_READ_INLINE + bool + default y if !OF_LIVE + +config ACPIGEN + bool "Support ACPI table generation in driver model" + default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU) + help + This option enables generation of ACPI tables using driver-model + devices. It adds a new operation struct to each driver, to support + things like generating device-specific tables and returning the ACPI + name of a device. + +config BOUNCE_BUFFER + bool "Include bounce buffer API" + help + Some peripherals support DMA from a subset of physically + addressable memory only. To support such peripherals, the + bounce buffer API uses a temporary buffer: it copies data + to/from DMA regions while managing cache operations. + + A second possible use of bounce buffers is their ability to + provide aligned buffers for DMA operations. + +endmenu |