Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-17 10:18:38 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/core/Kconfig

353 lines
12 KiB
Text
Raw Normal View History

drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
menu "Generic Driver Options"
dm: add entries to Kconfig Create entries of CONFIG_DM, CONFIG_DM_SERIAL, CONFIG_DM_GPIO and CONFIG_DM_SPI. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
2014-10-23 13:26:09 +00:00
config DM
bool "Enable Driver Model"
help
dm: Expand and complete Kconfig in drivers/ Expand the help messages for each driver. Add missing Kconfig for I2C, SPI flash and thermal. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
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.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
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
spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN Some platforms have very limited SRAM to run SPL code, so there may not be the same amount space for a malloc pool before relocation in the SPL stage as the normal U-Boot stage. Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN, so the size of pre-relocation malloc pool can be configured memory space independently. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> [fixed up commit-message:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-07-24 09:43:34 +00:00
must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
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
spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN Some platforms have very limited SRAM to run SPL code, so there may not be the same amount space for a malloc pool before relocation in the SPL stage as the normal U-Boot stage. Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN, so the size of pre-relocation malloc pool can be configured memory space independently. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> [fixed up commit-message:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-07-24 09:43:34 +00:00
CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
dm: core: Allow driver model to be disabled for TPL Since TPL often needs to be very very small it may not make sense to enable driver model. Add an option for this. This changes brings the 'rock' board under the TPL limit with gcc 4.9. Signed-off-by: Simon Glass <sjg@chromium.org>
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
spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN Some platforms have very limited SRAM to run SPL code, so there may not be the same amount space for a malloc pool before relocation in the SPL stage as the normal U-Boot stage. Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN, so the size of pre-relocation malloc pool can be configured memory space independently. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> [fixed up commit-message:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-07-24 09:43:34 +00:00
must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
dm: core: Allow driver model to be disabled for TPL Since TPL often needs to be very very small it may not make sense to enable driver model. Add an option for this. This changes brings the 'rock' board under the TPL limit with gcc 4.9. Signed-off-by: Simon Glass <sjg@chromium.org>
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
spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN Some platforms have very limited SRAM to run SPL code, so there may not be the same amount space for a malloc pool before relocation in the SPL stage as the normal U-Boot stage. Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN, so the size of pre-relocation malloc pool can be configured memory space independently. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> [fixed up commit-message:] Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-07-24 09:43:34 +00:00
CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
dm: core: Allow driver model to be disabled for TPL Since TPL often needs to be very very small it may not make sense to enable driver model. Add an option for this. This changes brings the 'rock' board under the TPL limit with gcc 4.9. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-04-02 15:50:31 +00:00
Disable this for very small implementations.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
config DM_WARN
bool "Enable warnings in driver model"
kconfig: remove unneeded dependency on !SPL_BUILD Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-24 13:26:21 +00:00
depends on DM
default y
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
help
dm: core: Allow dm_warn() to be used in SPL At present this option is disabled in SPL, meaning that warnings are not displayed. It is sometimes useful to see warnings in SPL for debugging purposes. Add a new Kconfig option to permit this. Signed-off-by: Simon Glass <sjg@chromium.org>
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
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: core: Allow dm_warn() to be used in SPL At present this option is disabled in SPL, meaning that warnings are not displayed. It is sometimes useful to see warnings in SPL for debugging purposes. Add a new Kconfig option to permit this. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
dm: replace dm_dbg() with pr_debug() As we discussed before in ML, dm_dbg() causes undefined reference error if #define DEBUG is added to users, but not drivers/core/util.c We do not need this macro because we can use pr_debug() instead, and it is pretty easy to enable it for the DM core by using ccflags-y. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
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.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
config DM_DEVICE_REMOVE
bool "Support device removal"
kconfig: remove unneeded dependency on !SPL_BUILD Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-24 13:26:21 +00:00
depends on DM
default y
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
help
We can save some code space by dropping support for removing a
drivers: core: Add the option SPL_DM_DEVICE_REMOVE to the Kconfig It is currently not possible to include the support to remove devices in the SPL. This is however needed by platforms that re-select their dtb after DM is initialized; they need to remove all the previously bound devices before triggering a scan of the new DT. Add a Kconfig option to be able to include the support for device removal in the SPL. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Seeries-changes:3 - update commit message Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:53 +00:00
device.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
dm: usb: Document that mixing DM_DEVICE_REMOVE and DM_USB is a bad idea Document that mixing DM_DEVICE_REMOVE and DM_USB is a bad idea, and also why this is a bad idea. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
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.
event: Add events for device probe/remove Generate events when devices are probed or removed, allowing hooks to be added for these situations. This is controlled by the DM_EVENT config option. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-03-04 15:43:03 +00:00
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.
drivers: core: Add the option SPL_DM_DEVICE_REMOVE to the Kconfig It is currently not possible to include the support to remove devices in the SPL. This is however needed by platforms that re-select their dtb after DM is initialized; they need to remove all the previously bound devices before triggering a scan of the new DT. Add a Kconfig option to be able to include the support for device removal in the SPL. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Seeries-changes:3 - update commit message Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2018-12-07 13:50:53 +00:00
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.
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-06 04:41:36 +00:00
config DM_STDIO
bool "Support stdio registration"
kconfig: remove unneeded dependency on !SPL_BUILD Now CONFIG_SPL_BUILD is not defined in Kconfig, so "!depends on SPL_BUILD" and "if !SPL_BUILD" are redundant. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2015-02-24 13:26:21 +00:00
depends on DM
default y
dm: Add Kconfig options for driver model SPL support The SPL support cannot be enabled yet, but we can add the Kconfig options in preparation for this. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: core: Allow sequence alias support to be removed for SPL In many cases SPL only uses a single serial port and there is no need for alias sequence support. We will just use the serial port pointed to by stdout-path in the /chosen node. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-02-28 05:06:30 +00:00
config DM_SEQ_ALIAS
bool "Support numbered aliases in device tree"
depends on DM
default y
spl: dm: Add SPL_DM_SEQ_ALIAS config option The Device Model sequence alias feature is required by some Uclasses. Instead of disabling the feature for all SPL targets allow it to be configured. The config option is disabled by default to reduce code size for targets that are not interested or do not require this feature. Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Michal Simek <michal.simek@xilinx.com> Cc: Simon Glass <sjg@chromium.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Stefan Roese <sr@denx.de> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
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"
Kconfig: Varios: Fix more SPL, TPL dependencies Several options are presenting themselves on a various boards where the options are clearly not used. (ie, SPL/TPL options when SPL or TPL are not defined) This patch is not attempting to be a complete list of items, but more like low hanging fruit. In some instances, I wasn't sure of DM was required, so I simply made them SPL or TPL. This patch attempts to reduce some of the menuconfig noise by defining dependencies so they don't appear when not used. Signed-off-by: Adam Ford <aford173@gmail.com>
2019-08-24 18:50:34 +00:00
depends on SPL_DM
dm: core: Allow sequence alias support to be removed for SPL In many cases SPL only uses a single serial port and there is no need for alias sequence support. We will just use the serial port pointed to by stdout-path in the /chosen node. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: Make regmap and syscon optional Not all boards use garbage collection in their link step, so we should avoid adding options that rely on this for prevention of code bloat. Add separate Kconfig options for syscon and regmap uclasses. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-07-17 15:22:07 +00:00
dm: core: Inline a few ofnode functions in SPL A recent change to unify the flattree/livetree code introduced a small size increase in SPL on some boards. For example SPL code size for px30-core-ctouch2-px30 increased by 40 bytes. To address this we can take advantage of the fact that some of the ofnode functions are only called a few times in SPL, so it is worth inlining them. Add new Kconfig options to control this. These functions are not inlined for U-Boot proper, since this increases code size. Fixes: 2ebea5eaebf ("dm: core: Combine the flattree and livetree binding code") Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: Introduce DMA constraints into the core device model Calculating the DMA offset between a bus address space and CPU's every time we call phys_to_bus() and bus_to_phys() isn't ideal performance wise, as it implies traversing the device tree from the device's node up to the root. Since this information is static and available before the device's initialization, parse it before the probe call an provide the DMA offset in 'struct udevice' for the address translation code to use it. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
2021-01-12 12:55:24 +00:00
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.
dm: Make regmap and syscon optional Not all boards use garbage collection in their link step, so we should avoid adding options that rely on this for prevention of code bloat. Add separate Kconfig options for syscon and regmap uclasses. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
dm: core: Add SPL Kconfig for REGMAP and SYSCON Add SPL Kconfig for REGMAP and SYSCON, so REGMAP and SYSCON can remove from SPL stage. Signed-off-by: Lin Huang <hl@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-17 06:20:13 +00:00
config SPL_REGMAP
bool "Support register maps in SPL"
spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and SPL_SYSCON SPL_REGMAP and SPL_SYSCON were marked as depending on DM, when a stricter dependency of SPL_DM was possible. This commit makes the prereq more specific. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-06-28 23:37:10 +00:00
depends on SPL_DM
dm: core: Add SPL Kconfig for REGMAP and SYSCON Add SPL Kconfig for REGMAP and SYSCON, so REGMAP and SYSCON can remove from SPL stage. Signed-off-by: Lin Huang <hl@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
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.
spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL This change introduces TPL variants of the REGMAP and SYSCON config options (i.e. TPL_REGMAP and TPL_SYSCON in analogy to SPL_REGMAP and SPL_SYSCON) in preparation of a finer-grained feature selection for building feature-rich TPL variants. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
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.
dm: Make regmap and syscon optional Not all boards use garbage collection in their link step, so we should avoid adding options that rely on this for prevention of code bloat. Add separate Kconfig options for syscon and regmap uclasses. Signed-off-by: Simon Glass <sjg@chromium.org>
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
dm: core: Add SPL Kconfig for REGMAP and SYSCON Add SPL Kconfig for REGMAP and SYSCON, so REGMAP and SYSCON can remove from SPL stage. Signed-off-by: Lin Huang <hl@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-17 06:20:13 +00:00
config SPL_SYSCON
bool "Support system controllers in SPL"
spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and SPL_SYSCON SPL_REGMAP and SPL_SYSCON were marked as depending on DM, when a stricter dependency of SPL_DM was possible. This commit makes the prereq more specific. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-06-28 23:37:10 +00:00
depends on SPL_REGMAP
dm: core: Add SPL Kconfig for REGMAP and SYSCON Add SPL Kconfig for REGMAP and SYSCON, so REGMAP and SYSCON can remove from SPL stage. Signed-off-by: Lin Huang <hl@rock-chips.com> Acked-by: Simon Glass <sjg@chromium.org>
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.
spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL This change introduces TPL variants of the REGMAP and SYSCON config options (i.e. TPL_REGMAP and TPL_SYSCON in analogy to SPL_REGMAP and SPL_SYSCON) in preparation of a finer-grained feature selection for building feature-rich TPL variants. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
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.
devres: make Devres optional with CONFIG_DEVRES Currently, Devres requires additional 16 byte for each allocation, which is not so insignificant in some cases. Add CONFIG_DEVRES to make this framework optional. If the option is disabled, devres functions fall back to non-managed variants. For example, devres_alloc() to kzalloc(), devm_kmalloc() to kmalloc(), etc. Because devres_head is also surrounded by an ifdef conditional, there is no memory overhead when CONFIG_DEVRES is disabled. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
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
devres: add debug command to dump device resources This new command can dump all device resources associated to each device. The fields in every line shows: - The address of the resource - The size of the resource - The name of the release function - The stage in which the resource has been acquired (BIND/PROBE) Currently, there is no driver using devres, but if such drivers are implemented, the output of this command should look like this: => dm devres - root_driver - soc - extbus - serial@54006800 bfb541e8 (8 byte) devm_kmalloc_release BIND bfb54440 (4 byte) devm_kmalloc_release PROBE bfb54460 (4 byte) devm_kmalloc_release PROBE - serial@54006900 bfb54270 (8 byte) devm_kmalloc_release BIND - gpio@55000000 - i2c@58780000 bfb5bce8 (12 byte) devm_kmalloc_release PROBE bfb5bd10 (4 byte) devm_kmalloc_release PROBE - eeprom bfb54418 (12 byte) devm_kmalloc_release BIND Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-25 12:52:38 +00:00
bool "Managed device resources debugging functions"
devres: make Devres optional with CONFIG_DEVRES Currently, Devres requires additional 16 byte for each allocation, which is not so insignificant in some cases. Add CONFIG_DEVRES to make this framework optional. If the option is disabled, devres functions fall back to non-managed variants. For example, devres_alloc() to kzalloc(), devm_kmalloc() to kmalloc(), etc. Because devres_head is also surrounded by an ifdef conditional, there is no memory overhead when CONFIG_DEVRES is disabled. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Suggested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
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.
devres: add debug command to dump device resources This new command can dump all device resources associated to each device. The fields in every line shows: - The address of the resource - The size of the resource - The name of the release function - The stage in which the resource has been acquired (BIND/PROBE) Currently, there is no driver using devres, but if such drivers are implemented, the output of this command should look like this: => dm devres - root_driver - soc - extbus - serial@54006800 bfb541e8 (8 byte) devm_kmalloc_release BIND bfb54440 (4 byte) devm_kmalloc_release PROBE bfb54460 (4 byte) devm_kmalloc_release PROBE - serial@54006900 bfb54270 (8 byte) devm_kmalloc_release BIND - gpio@55000000 - i2c@58780000 bfb5bce8 (12 byte) devm_kmalloc_release PROBE bfb5bd10 (4 byte) devm_kmalloc_release PROBE - eeprom bfb54418 (12 byte) devm_kmalloc_release BIND Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org>
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.
drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
dm: core: Add Kconfig for simple bus driver Add Kconfig entries for the simple-bus driver, both for U-Boot and for SPL. The simple-bus is enabled by default in U-Boot and disabled by default in SPL to preserve the original behavior. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Modified to fit on top of Masahiro's $(SPL) setup: Signed-off-by: Simon Glass <sjg@chromium.org>
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
dm: core: Enable SPL_SIMPLE_BUS by default This option is needed for all SoCs which have nodes on bus. Without enabling this drivers are not found and probed. Issue was found on Zynq MMC probe. Enable this option by default. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-12-01 07:37:16 +00:00
default y
dm: core: Add Kconfig for simple bus driver Add Kconfig entries for the simple-bus driver, both for U-Boot and for SPL. The simple-bus is enabled by default in U-Boot and disabled by default in SPL to preserve the original behavior. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Modified to fit on top of Masahiro's $(SPL) setup: Signed-off-by: Simon Glass <sjg@chromium.org>
2015-08-02 23:15:48 +00:00
help
Supports the 'simple-bus' driver, which is used on some systems
in SPL.
dm: core: Correctly read <ranges> of simple-bus At present we decode simple bus <ranges> using the following assumption: - parent #address-cells 1 - child #address-cells 1 - child #size-cells 1 However this might not always be the case. Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and use fdt_read_ranges() to correctly decode it according to the actual parent and child #address-cells / #size-cells under a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE which can be turned on for any board that needs it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
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
test: dm: Add a test case for simple-bus <ranges> This adds a test case to verify reading <ranges> of a simple-bus is working as expected. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:15:03 +00:00
default y if SANDBOX
dm: core: Correctly read <ranges> of simple-bus At present we decode simple bus <ranges> using the following assumption: - parent #address-cells 1 - child #address-cells 1 - child #size-cells 1 However this might not always be the case. Update to use fdt_addr_t and fdt_size_t in 'struct simple_bus_plat', and use fdt_read_ranges() to correctly decode it according to the actual parent and child #address-cells / #size-cells under a Kconfig option CONFIG_SIMPLE_BUS_CORRECT_RANGE which can be turned on for any board that needs it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
2021-03-14 12:15:02 +00:00
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.
dm: Add support for simple-pm-bus This type of bus is used in Linux to designate buses which have power domains and/or clocks which need to be enabled before their child devices can be used. Because power domains are automatically enabled before probing in U-Boot, we just need to enable any clocks present. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
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.
dm: core: Enable optional use of fdt_translate_address() The current "simple" address translation simple_bus_translate() is not working on some platforms (e.g. MVEBU). As here more complex "ranges" properties are used in many nodes (multiple tuples etc). This patch enables the optional use of the common fdt_translate_address() function which handles this translation correctly. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
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().
config SPL_OF_TRANSLATE
dm: core: Fix Kconfig text to mention SPL in SPL_OF_TRANSLATE Add a remark about SPL to this Kconfig option. Otherwise its identitcal to the non-SPL version, which is confusing. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Michal Simek <michal.simek@xilinx.com>
2015-11-26 12:38:01 +00:00
bool "Translate addresses using fdt_translate_address in SPL"
dm: core: Enable optional use of fdt_translate_address() The current "simple" address translation simple_bus_translate() is not working on some platforms (e.g. MVEBU). As here more complex "ranges" properties are used in many nodes (multiple tuples etc). This patch enables the optional use of the common fdt_translate_address() function which handles this translation correctly. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-02 05:41:12 +00:00
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().
dm: core: Change platform specific translation-offset handling Testing has shown that the current DM implementation of a platform / board specific translation offset, as its needed for the SPL on MVEBU platforms is buggy. The translation offset is confingured too late, after the driver bind functions are run. This may result in incorrect address translations. With the current implementation its not possible to configure the offset earlier, as the DM code has not run at all. This patch now removed the set_/get_translation_offset() calls and moves the translation offset into the GD variable translation_offset. This variable will get used when CONFIG_TRANSLATION_OFFSET is enabled. This option is enabled only for MVEBU on ARM32 platforms, where its currenty needed and configured in the SPL. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pierre Bourdon <delroth@gmail.com> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Simon Glass <sjg@chromium.org> Cc: Heiko Schocher <hs@denx.de> Cc: Tom Rini <trini@konsulko.com> Tested-by: Pierre Bourdon <delroth@gmail.com> Tested-by: Baruch Siach <baruch@tkos.co.il>
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.
fdt: Support for ISA busses Support ISA busses in much the same way as Linux does. This allows for ISA bus addresses to be translated, and only if CONFIG_OF_ISA_BUS is selected in order to avoid including the code in builds which won't need it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Reviewed-by: Simon Glass <sjg@chromium.org>
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
drivers: Kconfig: spelling fixes Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-01-13 09:13:24 +00:00
being targeted, and whether or not it makes use of an ISA bus.
fdt: Support for ISA busses Support ISA busses in much the same way as Linux does. This allows for ISA bus addresses to be translated, and only if CONFIG_OF_ISA_BUS is selected in order to avoid including the code in builds which won't need it. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Reviewed-by: Simon Glass <sjg@chromium.org>
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.
dm: core: Add device-based 'read' functions to access DT It is common to read a device-tree property from the node associated with a device. Add convenience functions to do this so that drivers do not need to deal with accessing the ofnode from the device. These functions all start with 'dev_read_' to provide consistent naming for all functions which read information from a device's device tree node. These are inlined when using the flat DT to save code size. The live tree implementation is added in a later commit. Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-19 02:09:03 +00:00
config DM_DEV_READ_INLINE
bool
default y if !OF_LIVE
dm: core: Add basic ACPI support ACPI (Advanced Configuration and Power Interface) is a standard for specifying information about a platform. It is a little like device tree but the bindings are part of the specification and it supports an interpreted bytecode language. Driver model does not use ACPI for U-Boot's configuration, but it is convenient to have it support generation of ACPI tables for passing to Linux, etc. As a starting point, add an optional set of ACPI operations to each device. Initially only a single operation is available, to obtain the ACPI name for the device. More operations are added later. Enable ACPI for sandbox to ensure build coverage and so that we can add tests. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-04-09 16:27:38 +00:00
config ACPIGEN
bool "Support ACPI table generation in driver model"
acpi: Enable ACPI table generation by default on x86 This should ideally be used by all x86 boards in U-Boot. Enable it by default. If some boards don't use it, the cost is small. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-17 03:22:39 +00:00
default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
Use LIB_UUID with ACPIGEN and FS_BTRFS Since the ACPI-generation code makes use of UUIDs we typically need to enabled UUID support for it to build. Add a new Kconfig condition. Use it for BTRFS also. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-07-02 18:36:15 +00:00
select LIB_UUID
dm: core: Add basic ACPI support ACPI (Advanced Configuration and Power Interface) is a standard for specifying information about a platform. It is a little like device tree but the bindings are part of the specification and it supports an interpreted bytecode language. Driver model does not use ACPI for U-Boot's configuration, but it is convenient to have it support generation of ACPI tables for passing to Linux, etc. As a starting point, add an optional set of ACPI operations to each device. Initially only a single operation is available, to obtain the ACPI name for the device. More operations are added later. Enable ACPI for sandbox to ensure build coverage and so that we can add tests. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
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.
Kconfig: Move BOUNCE_BUFFER under driver options This option does not belong at the top level. Move it under generic driver options. Signed-off-by: Simon Glass <sjg@chromium.org>
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.
drivers: hierarchize drivers Kconfig menu The menuconfig for drivers are getting more and more cluttered and unreadable because too many entries are displayed in a single flat menu. Use hierarchic menu for each category. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org> [trini: Update to apply again in a few places, drop USB hunk] Signed-off-by: Tom Rini <trini@konsulko.com>
2015-07-25 17:46:26 +00:00
endmenu
Reference in a new issue Copy permalink