2015-07-25 17:46:26 +00:00
|
|
|
menu "Generic Driver Options"
|
|
|
|
|
|
2014-10-23 13:26:09 +00:00
|
|
|
config DM
|
|
|
|
|
bool "Enable Driver Model"
|
|
|
|
|
help
|
2015-02-06 04:41:35 +00:00
|
|
|
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.
|
2015-02-06 04:41:36 +00:00
|
|
|
|
|
|
|
|
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
|
2017-07-24 09:43:34 +00:00
|
|
|
must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
|
2015-02-06 04:41:36 +00:00
|
|
|
In most cases driver model will only allocate a few uclasses
|
|
|
|
|
and devices in SPL, so 1KB should be enable. See
|
2017-07-24 09:43:34 +00:00
|
|
|
CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
|
2015-02-06 04:41:36 +00:00
|
|
|
|
2017-04-02 15:50:31 +00:00
|
|
|
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
|
2017-07-24 09:43:34 +00:00
|
|
|
must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
|
2017-04-02 15:50:31 +00:00
|
|
|
In most cases driver model will only allocate a few uclasses
|
|
|
|
|
and devices in SPL, so 1KB should be enough. See
|
2017-07-24 09:43:34 +00:00
|
|
|
CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
|
2017-04-02 15:50:31 +00:00
|
|
|
Disable this for very small implementations.
|
|
|
|
|
|
2015-02-06 04:41:36 +00:00
|
|
|
config DM_WARN
|
|
|
|
|
bool "Enable warnings in driver model"
|
2015-02-24 13:26:21 +00:00
|
|
|
depends on DM
|
|
|
|
|
default y
|
2015-02-06 04:41:36 +00:00
|
|
|
help
|
2020-10-03 17:31:26 +00:00
|
|
|
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
|
|
|
|
|
|
2015-02-06 04:41:36 +00:00
|
|
|
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.
|
2020-10-03 17:31:26 +00:00
|
|
|
|
|
|
|
|
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.
|
2015-02-06 04:41:36 +00:00
|
|
|
|
2017-09-29 03:31:20 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-02-06 04:41:36 +00:00
|
|
|
config DM_DEVICE_REMOVE
|
|
|
|
|
bool "Support device removal"
|
2015-02-24 13:26:21 +00:00
|
|
|
depends on DM
|
|
|
|
|
default y
|
2015-02-06 04:41:36 +00:00
|
|
|
help
|
|
|
|
|
We can save some code space by dropping support for removing a
|
2018-12-07 13:50:53 +00:00
|
|
|
device.
|
2015-02-06 04:41:36 +00:00
|
|
|
|
2015-07-01 18:52:59 +00:00
|
|
|
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.
|
|
|
|
|
|
2018-12-07 13:50:53 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-02-06 04:41:36 +00:00
|
|
|
config DM_STDIO
|
|
|
|
|
bool "Support stdio registration"
|
2015-02-24 13:26:21 +00:00
|
|
|
depends on DM
|
|
|
|
|
default y
|
2015-02-06 04:41:36 +00:00
|
|
|
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.
|
2015-02-28 05:06:30 +00:00
|
|
|
|
|
|
|
|
config DM_SEQ_ALIAS
|
|
|
|
|
bool "Support numbered aliases in device tree"
|
|
|
|
|
depends on DM
|
|
|
|
|
default y
|
2016-01-07 17:00:45 +00:00
|
|
|
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"
|
2019-08-24 18:50:34 +00:00
|
|
|
depends on SPL_DM
|
2016-01-07 17:00:45 +00:00
|
|
|
default n
|
2015-02-28 05:06:30 +00:00
|
|
|
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.
|
2015-07-17 15:22:07 +00:00
|
|
|
|
2020-12-17 00:25:06 +00:00
|
|
|
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.
|
|
|
|
|
|
2021-01-12 12:55:24 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-07-17 15:22:07 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-11-17 06:20:13 +00:00
|
|
|
config SPL_REGMAP
|
|
|
|
|
bool "Support register maps in SPL"
|
2017-06-28 23:37:10 +00:00
|
|
|
depends on SPL_DM
|
2015-11-17 06:20:13 +00:00
|
|
|
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.
|
|
|
|
|
|
2017-06-28 23:38:49 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-07-17 15:22:07 +00:00
|
|
|
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
|
|
|
|
2015-11-17 06:20:13 +00:00
|
|
|
config SPL_SYSCON
|
|
|
|
|
bool "Support system controllers in SPL"
|
2017-06-28 23:37:10 +00:00
|
|
|
depends on SPL_REGMAP
|
2015-11-17 06:20:13 +00:00
|
|
|
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.
|
|
|
|
|
|
2017-06-28 23:38:49 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-07-25 12:52:37 +00:00
|
|
|
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
|
2015-07-25 12:52:38 +00:00
|
|
|
bool "Managed device resources debugging functions"
|
2015-07-25 12:52:37 +00:00
|
|
|
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.
|
2015-07-25 12:52:38 +00:00
|
|
|
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.
|
2015-07-25 17:46:26 +00:00
|
|
|
|
2015-08-02 23:15:48 +00:00
|
|
|
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
|
2015-12-01 07:37:16 +00:00
|
|
|
default y
|
2015-08-02 23:15:48 +00:00
|
|
|
help
|
|
|
|
|
Supports the 'simple-bus' driver, which is used on some systems
|
|
|
|
|
in SPL.
|
|
|
|
|
|
2021-03-14 12:15:02 +00:00
|
|
|
config SIMPLE_BUS_CORRECT_RANGE
|
|
|
|
|
bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells"
|
|
|
|
|
depends on SIMPLE_BUS
|
|
|
|
|
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.
|
|
|
|
|
|
2020-06-24 10:41:12 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-09-02 05:41:12 +00:00
|
|
|
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().
|
|
|
|
|
|
fdt: translate address if #size-cells = <0>
The __of_translate_address routine translates an address from the
device tree into a CPU physical address. A note in the description of
the routine explains that the crossing of any level with
since inherited from IBM. This does not happen for Texas Instruments, or
at least for the beaglebone device tree. Without this patch, in fact,
the translation into physical addresses of the registers contained in the
am33xx-clocks.dtsi nodes would not be possible. They all have a parent
with #size-cells = <0>.
The CONFIG_OF_TRANSLATE_ZERO_SIZE_CELLS symbol makes translation
possible even in the case of crossing levels with #size-cells = <0>.
The patch acts conservatively on address translation, except for
removing a check within the of_translate_one function in the
drivers/core/of_addr.c file:
+
ranges = of_get_property(parent, rprop, &rlen);
- if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
- debug("no ranges; cannot translate\n");
- return 1;
- }
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
debug("empty ranges; 1:1 translation\n");
There are two reasons:
1 The function of_empty_ranges_quirk always returns false, invalidating
the following if statement in case of null ranges. Therefore one of
the two checks is useless.
2 The implementation of the of_translate_one function found in the
common/fdt_support.c file has removed this check while keeping the one
about the 1:1 translation.
The patch adds a test and modifies a check for the correctness of an
address in the case of enabling translation also for zero size cells.
The added test checks translations of addresses generated by nodes of
a device tree similar to those you can find in the files am33xx.dtsi
and am33xx-clocks.dtsi for which the patch was created.
The patch was also tested on a beaglebone black board. The addresses
generated for the registers of the loaded drivers are those specified
by the AM335x reference manual.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Tested-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-29 23:16:21 +00:00
|
|
|
config OF_TRANSLATE_ZERO_SIZE_CELLS
|
|
|
|
|
bool "Enable translation for zero size cells"
|
|
|
|
|
depends on OF_TRANSLATE
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
The routine used to translate an FDT address into a physical CPU
|
|
|
|
|
address was developed by IBM. It considers that crossing any level
|
|
|
|
|
with #size-cells = <0> makes translation impossible, even if it is
|
|
|
|
|
not the way it was specified.
|
|
|
|
|
Enabling this option makes translation possible even in the case
|
|
|
|
|
of crossing levels with #size-cells = <0>.
|
|
|
|
|
|
2015-09-02 05:41:12 +00:00
|
|
|
config SPL_OF_TRANSLATE
|
2015-11-26 12:38:01 +00:00
|
|
|
bool "Translate addresses using fdt_translate_address in SPL"
|
2015-09-02 05:41:12 +00:00
|
|
|
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().
|
|
|
|
|
|
2019-04-12 14:42:28 +00:00
|
|
|
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.
|
|
|
|
|
|
2016-05-17 06:43:24 +00:00
|
|
|
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
|
2019-01-13 09:13:24 +00:00
|
|
|
being targeted, and whether or not it makes use of an ISA bus.
|
2016-05-17 06:43:24 +00:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2017-05-19 02:09:03 +00:00
|
|
|
config DM_DEV_READ_INLINE
|
|
|
|
|
bool
|
|
|
|
|
default y if !OF_LIVE
|
|
|
|
|
|
2020-04-09 16:27:38 +00:00
|
|
|
config ACPIGEN
|
|
|
|
|
bool "Support ACPI table generation in driver model"
|
2020-07-17 03:22:39 +00:00
|
|
|
default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
|
2020-04-09 16:27:38 +00:00
|
|
|
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.
|
|
|
|
|
|
2020-09-11 02:21:25 +00:00
|
|
|
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.
|
|
|
|
|
|
2015-07-25 17:46:26 +00:00
|
|
|
endmenu
|
