drivers/core/Kconfig

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 VPL_DM
	bool "Enable Driver Model for VPL"
	depends on DM && VPL
	default y if SPL_DM
	help
	  Enable driver model in VPL. 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.

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 DM_EVENT
	bool "Support events with driver model"
	depends on DM
	imply EVENT
	default y if SANDBOX
	help
	  This enables support for generating events related to driver model
	  operations, such as prbing or removing a device. Subsystems can
	  register a 'spy' function that is called when the event occurs.

config SPL_DM_DEVICE_REMOVE
	bool "Support device removal in SPL"
	depends on SPL_DM
	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
	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 VPL_DM_SEQ_ALIAS
	bool "Support numbered aliases in device tree in VPL"
	depends on VPL_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, to save code space in VPL.

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
	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 VPL_REGMAP
	bool "Support register maps in VPL"
	depends on VPL_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 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 VPL_SYSCON
	bool "Support system controllers in VPL"
	depends on VPL_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
	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 VPL_OF_TRANSLATE
	bool "Translate addresses using fdt_translate_address in SPL"
	depends on SPL_DM && VPL_OF_CONTROL
	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)
	select LIB_UUID
	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