drivers/core/Kconfig

   1 menu "Generic Driver Options"
   2
   3 config DM
   4         bool "Enable Driver Model"
   5         help
   6           This config option enables Driver Model. This brings in the core
   7           support, including scanning of platform data on start-up. If
   8           CONFIG_OF_CONTROL is enabled, the device tree will be scanned also
   9           when available.
  10
  11 config SPL_DM
  12         bool "Enable Driver Model for SPL"
  13         depends on DM && SPL
  14         help
  15           Enable driver model in SPL. You will need to provide a
  16           suitable malloc() implementation. If you are not using the
  17           full malloc() enabled by CONFIG_SYS_SPL_MALLOC_START,
  18           consider using CONFIG_SYS_MALLOC_SIMPLE. In that case you
  19           must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
  20           In most cases driver model will only allocate a few uclasses
  21           and devices in SPL, so 1KB should be enable. See
  22           CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
  23
  24 config TPL_DM
  25         bool "Enable Driver Model for TPL"
  26         depends on DM && TPL
  27         help
  28           Enable driver model in TPL. You will need to provide a
  29           suitable malloc() implementation. If you are not using the
  30           full malloc() enabled by CONFIG_SYS_SPL_MALLOC_START,
  31           consider using CONFIG_SYS_MALLOC_SIMPLE. In that case you
  32           must provide CONFIG_SPL_SYS_MALLOC_F_LEN to set the size.
  33           In most cases driver model will only allocate a few uclasses
  34           and devices in SPL, so 1KB should be enough. See
  35           CONFIG_SPL_SYS_MALLOC_F_LEN for more details on how to enable it.
  36           Disable this for very small implementations.
  37
  38 config DM_WARN
  39         bool "Enable warnings in driver model"
  40         depends on DM
  41         default y
  42         help
  43           Enable this to see warnings related to driver model.
  44
  45           Warnings may help with debugging, such as when expected devices do
  46           not bind correctly. If the option is disabled, dm_warn() is compiled
  47           out - it will do nothing when called.
  48
  49 config SPL_DM_WARN
  50         bool "Enable warnings in driver model wuth SPL"
  51         depends on SPL_DM
  52         help
  53           Enable this to see warnings related to driver model in SPL
  54
  55           The dm_warn() function can use up quite a bit of space for its
  56           strings. By default this is disabled for SPL builds to save space.
  57
  58           Warnings may help with debugging, such as when expected devices do
  59           not bind correctly. If the option is disabled, dm_warn() is compiled
  60           out - it will do nothing when called.
  61
  62 config DM_DEBUG
  63         bool "Enable debug messages in driver model core"
  64         depends on DM
  65         help
  66           Say Y here if you want to compile in debug messages in DM core.
  67
  68 config DM_DEVICE_REMOVE
  69         bool "Support device removal"
  70         depends on DM
  71         default y
  72         help
  73           We can save some code space by dropping support for removing a
  74           device.
  75
  76           Note that this may have undesirable results in the USB subsystem as
  77           it causes unplugged devices to linger around in the dm-tree, and it
  78           causes USB host controllers to not be stopped when booting the OS.
  79
  80 config SPL_DM_DEVICE_REMOVE
  81         bool "Support device removal in SPL"
  82         depends on SPL_DM
  83         default n
  84         help
  85           We can save some code space by dropping support for removing a
  86           device. This is not normally required in SPL, so by default this
  87           option is disabled for SPL.
  88
  89 config DM_STDIO
  90         bool "Support stdio registration"
  91         depends on DM
  92         default y
  93         help
  94           Normally serial drivers register with stdio so that they can be used
  95           as normal output devices. In SPL we don't normally use stdio, so
  96           we can omit this feature.
  97
  98 config DM_SEQ_ALIAS
  99         bool "Support numbered aliases in device tree"
 100         depends on DM
 101         default y
 102         help
 103           Most boards will have a '/aliases' node containing the path to
 104           numbered devices (e.g. serial0 = &serial0). This feature can be
 105           disabled if it is not required.
 106
 107 config SPL_DM_SEQ_ALIAS
 108         bool "Support numbered aliases in device tree in SPL"
 109         depends on SPL_DM
 110         default n
 111         help
 112           Most boards will have a '/aliases' node containing the path to
 113           numbered devices (e.g. serial0 = &serial0). This feature can be
 114           disabled if it is not required, to save code space in SPL.
 115
 116 config SPL_DM_INLINE_OFNODE
 117         bool "Inline some ofnode functions which are seldom used in SPL"
 118         depends on SPL_DM
 119         default y
 120         help
 121           This applies to several ofnode functions (see ofnode.h) which are
 122           seldom used. Inlining them can help reduce code size.
 123
 124 config TPL_DM_INLINE_OFNODE
 125         bool "Inline some ofnode functions which are seldom used in TPL"
 126         depends on TPL_DM
 127         default y
 128         help
 129           This applies to several ofnode functions (see ofnode.h) which are
 130           seldom used. Inlining them can help reduce code size.
 131
 132 config DM_DMA
 133         bool "Support per-device DMA constraints"
 134         depends on DM
 135         default n
 136         help
 137           Enable this to extract per-device DMA constraints, only supported on
 138           device-tree systems for now. This is needed in order translate
 139           addresses on systems where different buses have different views of
 140           the physical address space.
 141
 142 config REGMAP
 143         bool "Support register maps"
 144         depends on DM
 145         help
 146           Hardware peripherals tend to have one or more sets of registers
 147           which can be accessed to control the hardware. A register map
 148           models this with a simple read/write interface. It can in principle
 149           support any bus type (I2C, SPI) but so far this only supports
 150           direct memory access.
 151
 152 config SPL_REGMAP
 153         bool "Support register maps in SPL"
 154         depends on SPL_DM
 155         help
 156           Hardware peripherals tend to have one or more sets of registers
 157           which can be accessed to control the hardware. A register map
 158           models this with a simple read/write interface. It can in principle
 159           support any bus type (I2C, SPI) but so far this only supports
 160           direct memory access.
 161
 162 config TPL_REGMAP
 163         bool "Support register maps in TPL"
 164         depends on TPL_DM
 165         help
 166           Hardware peripherals tend to have one or more sets of registers
 167           which can be accessed to control the hardware. A register map
 168           models this with a simple read/write interface. It can in principle
 169           support any bus type (I2C, SPI) but so far this only supports
 170           direct memory access.
 171
 172 config SYSCON
 173         bool "Support system controllers"
 174         depends on REGMAP
 175         help
 176           Many SoCs have a number of system controllers which are dealt with
 177           as a group by a single driver. Some common functionality is provided
 178           by this uclass, including accessing registers via regmap and
 179           assigning a unique number to each.
 180
 181 config SPL_SYSCON
 182         bool "Support system controllers in SPL"
 183         depends on SPL_REGMAP
 184         help
 185           Many SoCs have a number of system controllers which are dealt with
 186           as a group by a single driver. Some common functionality is provided
 187           by this uclass, including accessing registers via regmap and
 188           assigning a unique number to each.
 189
 190 config TPL_SYSCON
 191         bool "Support system controllers in TPL"
 192         depends on TPL_REGMAP
 193         help
 194           Many SoCs have a number of system controllers which are dealt with
 195           as a group by a single driver. Some common functionality is provided
 196           by this uclass, including accessing registers via regmap and
 197           assigning a unique number to each.
 198
 199 config DEVRES
 200         bool "Managed device resources"
 201         depends on DM
 202         help
 203           This option enables the Managed device resources core support.
 204           Device resources managed by the devres framework are automatically
 205           released whether initialization fails half-way or the device gets
 206           detached.
 207
 208           If this option is disabled, devres functions fall back to
 209           non-managed variants.  For example, devres_alloc() to kzalloc(),
 210           devm_kmalloc() to kmalloc(), etc.
 211
 212 config DEBUG_DEVRES
 213         bool "Managed device resources debugging functions"
 214         depends on DEVRES
 215         help
 216           If this option is enabled, devres debug messages are printed.
 217           Also, a function is available to dump a list of device resources.
 218           Select this if you are having a problem with devres or want to
 219           debug resource management for a managed device.
 220
 221           If you are unsure about this, Say N here.
 222
 223 config SIMPLE_BUS
 224         bool "Support simple-bus driver"
 225         depends on DM && OF_CONTROL
 226         default y
 227         help
 228           Supports the 'simple-bus' driver, which is used on some systems.
 229
 230 config SPL_SIMPLE_BUS
 231         bool "Support simple-bus driver in SPL"
 232         depends on SPL_DM && SPL_OF_CONTROL
 233         default y
 234         help
 235           Supports the 'simple-bus' driver, which is used on some systems
 236           in SPL.
 237
 238 config SIMPLE_BUS_CORRECT_RANGE
 239         bool "Decode the 'simple-bus' <range> by honoring the #address-cells and #size-cells"
 240         depends on SIMPLE_BUS
 241         default y if SANDBOX
 242         help
 243           Decoding the 'simple-bus' <range> by honoring the #address-cells
 244           and #size-cells of parent/child bus. If unset, #address-cells of
 245           parent bus is assumed to be 1, #address-cells and #size-cells of
 246           child bus is also assumed to be 1, to save some spaces of using
 247           an advanced API to decode the <range>, which benefits SPL image
 248           builds that have size limits.
 249
 250           If you are unsure about this, Say N here.
 251
 252 config SIMPLE_PM_BUS
 253         bool "Support simple-pm-bus driver"
 254         depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
 255         help
 256           Supports the 'simple-pm-bus' driver, which is used for busses that
 257           have power domains and/or clocks which need to be enabled before use.
 258
 259 config OF_TRANSLATE
 260         bool "Translate addresses using fdt_translate_address"
 261         depends on DM && OF_CONTROL
 262         default y
 263         help
 264           If this option is enabled, the reg property will be translated
 265           using the fdt_translate_address() function. This is necessary
 266           on some platforms (e.g. MVEBU) using complex "ranges"
 267           properties in many nodes. As this translation is not handled
 268           correctly in the default simple_bus_translate() function.
 269
 270           If this option is not enabled, simple_bus_translate() will be
 271           used for the address translation. This function is faster and
 272           smaller in size than fdt_translate_address().
 273
 274 config OF_TRANSLATE_ZERO_SIZE_CELLS
 275         bool "Enable translation for zero size cells"
 276         depends on OF_TRANSLATE
 277         default n
 278         help
 279           The routine used to translate an FDT address into a physical CPU
 280           address was developed by IBM. It considers that crossing any level
 281           with #size-cells = <0> makes translation impossible, even if it is
 282           not the way it was specified.
 283           Enabling this option makes translation possible even in the case
 284           of crossing levels with #size-cells = <0>.
 285
 286 config SPL_OF_TRANSLATE
 287         bool "Translate addresses using fdt_translate_address in SPL"
 288         depends on SPL_DM && SPL_OF_CONTROL
 289         default n
 290         help
 291           If this option is enabled, the reg property will be translated
 292           using the fdt_translate_address() function. This is necessary
 293           on some platforms (e.g. MVEBU) using complex "ranges"
 294           properties in many nodes. As this translation is not handled
 295           correctly in the default simple_bus_translate() function.
 296
 297           If this option is not enabled, simple_bus_translate() will be
 298           used for the address translation. This function is faster and
 299           smaller in size than fdt_translate_address().
 300
 301 config TRANSLATION_OFFSET
 302         bool "Platforms specific translation offset"
 303         depends on DM && OF_CONTROL
 304         help
 305           Some platforms need a special address translation. Those
 306           platforms (e.g. mvebu in SPL) can configure a translation
 307           offset by enabling this option and setting the translation_offset
 308           variable in the GD in their platform- / board-specific code.
 309
 310 config OF_ISA_BUS
 311         bool
 312         depends on OF_TRANSLATE
 313         help
 314           Is this option is enabled then support for the ISA bus will
 315           be included for addresses read from DT. This is something that
 316           should be known to be required or not based upon the board
 317           being targeted, and whether or not it makes use of an ISA bus.
 318
 319           The bus is matched based upon its node name equalling "isa". The
 320           busses #address-cells should equal 2, with the first cell being
 321           used to hold flags & flag 0x1 indicating that the address range
 322           should be accessed using I/O port in/out accessors. The second
 323           cell holds the offset into ISA bus address space. The #size-cells
 324           property should equal 1, and of course holds the size of the
 325           address range used by a device.
 326
 327           If this option is not enabled then support for the ISA bus is
 328           not included and any such busses used in DT will be treated as
 329           typical simple-bus compatible busses. This will lead to
 330           mistranslation of device addresses, so ensure that this is
 331           enabled if your board does include an ISA bus.
 332
 333 config DM_DEV_READ_INLINE
 334         bool
 335         default y if !OF_LIVE
 336
 337 config ACPIGEN
 338         bool "Support ACPI table generation in driver model"
 339         default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
 340         help
 341           This option enables generation of ACPI tables using driver-model
 342           devices. It adds a new operation struct to each driver, to support
 343           things like generating device-specific tables and returning the ACPI
 344           name of a device.
 345
 346 config BOUNCE_BUFFER
 347         bool "Include bounce buffer API"
 348         help
 349           Some peripherals support DMA from a subset of physically
 350           addressable memory only.  To support such peripherals, the
 351           bounce buffer API uses a temporary buffer: it copies data
 352           to/from DMA regions while managing cache operations.
 353
 354           A second possible use of bounce buffers is their ability to
 355           provide aligned buffers for DMA operations.
 356
 357 endmenu