u-boot/drivers/core/Kconfig

219 lines
7.8 KiB
Text
Raw Normal View History

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_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_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_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_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
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.
This will cause dm_warn() to be compiled out - it will do nothing
when called.
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. This is not normally required in SPL, so by default this
option is disabled for SPL.
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_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 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 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 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.
devres: introduce Devres (Managed Device Resource) framework In U-Boot's driver model, memory is basically allocated and freed in the core framework. So, low level drivers generally only have to specify the size of needed memory with .priv_auto_alloc_size, .platdata_auto_alloc_size, etc. Nevertheless, some drivers still need to allocate/free memory on their own in case they cannot statically know the necessary memory size. So, I believe it is reasonable enough to port Devres into U-boot. Devres, which originates in Linux, manages device resources for each device and automatically releases them on driver detach. With devres, device resources are guaranteed to be freed whether initialization fails half-way or the device gets detached. The basic idea is totally the same to that of Linux, but I tweaked it a bit so that it fits in U-Boot's driver model. In U-Boot, drivers are activated in two steps: binding and probing. Binding puts a driver and a device together. It is just data manipulation on the system memory, so nothing has happened on the hardware device at this moment. When the device is really used, it is probed. Probing initializes the real hardware device to make it really ready for use. So, the resources acquired during the probing process must be freed when the device is removed. Likewise, what has been allocated in binding should be released when the device is unbound. The struct devres has a member "probe" to remember when the resource was allocated. CONFIG_DEBUG_DEVRES is also supported for easier debugging. If enabled, debug messages are printed each time a resource is allocated/freed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-25 12:52:35 +00:00
config SPL_SYSCON
bool "Support system controllers in SPL"
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 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.
devres: introduce Devres (Managed Device Resource) framework In U-Boot's driver model, memory is basically allocated and freed in the core framework. So, low level drivers generally only have to specify the size of needed memory with .priv_auto_alloc_size, .platdata_auto_alloc_size, etc. Nevertheless, some drivers still need to allocate/free memory on their own in case they cannot statically know the necessary memory size. So, I believe it is reasonable enough to port Devres into U-boot. Devres, which originates in Linux, manages device resources for each device and automatically releases them on driver detach. With devres, device resources are guaranteed to be freed whether initialization fails half-way or the device gets detached. The basic idea is totally the same to that of Linux, but I tweaked it a bit so that it fits in U-Boot's driver model. In U-Boot, drivers are activated in two steps: binding and probing. Binding puts a driver and a device together. It is just data manipulation on the system memory, so nothing has happened on the hardware device at this moment. When the device is really used, it is probed. Probing initializes the real hardware device to make it really ready for use. So, the resources acquired during the probing process must be freed when the device is removed. Likewise, what has been allocated in binding should be released when the device is unbound. The struct devres has a member "probe" to remember when the resource was allocated. CONFIG_DEBUG_DEVRES is also supported for easier debugging. If enabled, debug messages are printed each time a resource is allocated/freed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-25 12:52:35 +00:00
config DEBUG_DEVRES
bool "Managed device resources debugging functions"
depends on DEVRES
devres: introduce Devres (Managed Device Resource) framework In U-Boot's driver model, memory is basically allocated and freed in the core framework. So, low level drivers generally only have to specify the size of needed memory with .priv_auto_alloc_size, .platdata_auto_alloc_size, etc. Nevertheless, some drivers still need to allocate/free memory on their own in case they cannot statically know the necessary memory size. So, I believe it is reasonable enough to port Devres into U-boot. Devres, which originates in Linux, manages device resources for each device and automatically releases them on driver detach. With devres, device resources are guaranteed to be freed whether initialization fails half-way or the device gets detached. The basic idea is totally the same to that of Linux, but I tweaked it a bit so that it fits in U-Boot's driver model. In U-Boot, drivers are activated in two steps: binding and probing. Binding puts a driver and a device together. It is just data manipulation on the system memory, so nothing has happened on the hardware device at this moment. When the device is really used, it is probed. Probing initializes the real hardware device to make it really ready for use. So, the resources acquired during the probing process must be freed when the device is removed. Likewise, what has been allocated in binding should be released when the device is unbound. The struct devres has a member "probe" to remember when the resource was allocated. CONFIG_DEBUG_DEVRES is also supported for easier debugging. If enabled, debug messages are printed each time a resource is allocated/freed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-25 12:52:35 +00:00
help
If this option is enabled, devres debug messages are printed.
Also, a function is available to dump a list of device resources.
devres: introduce Devres (Managed Device Resource) framework In U-Boot's driver model, memory is basically allocated and freed in the core framework. So, low level drivers generally only have to specify the size of needed memory with .priv_auto_alloc_size, .platdata_auto_alloc_size, etc. Nevertheless, some drivers still need to allocate/free memory on their own in case they cannot statically know the necessary memory size. So, I believe it is reasonable enough to port Devres into U-boot. Devres, which originates in Linux, manages device resources for each device and automatically releases them on driver detach. With devres, device resources are guaranteed to be freed whether initialization fails half-way or the device gets detached. The basic idea is totally the same to that of Linux, but I tweaked it a bit so that it fits in U-Boot's driver model. In U-Boot, drivers are activated in two steps: binding and probing. Binding puts a driver and a device together. It is just data manipulation on the system memory, so nothing has happened on the hardware device at this moment. When the device is really used, it is probed. Probing initializes the real hardware device to make it really ready for use. So, the resources acquired during the probing process must be freed when the device is removed. Likewise, what has been allocated in binding should be released when the device is unbound. The struct devres has a member "probe" to remember when the resource was allocated. CONFIG_DEBUG_DEVRES is also supported for easier debugging. If enabled, debug messages are printed each time a resource is allocated/freed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-25 12:52:35 +00:00
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 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 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 targetted, 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.
endmenu