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 REGMAP
 117         bool "Support register maps"
 118         depends on DM
 119         help
 120           Hardware peripherals tend to have one or more sets of registers
 121           which can be accessed to control the hardware. A register map
 122           models this with a simple read/write interface. It can in principle
 123           support any bus type (I2C, SPI) but so far this only supports
 124           direct memory access.
 125
 126 config SPL_REGMAP
 127         bool "Support register maps in SPL"
 128         depends on SPL_DM
 129         help
 130           Hardware peripherals tend to have one or more sets of registers
 131           which can be accessed to control the hardware. A register map
 132           models this with a simple read/write interface. It can in principle
 133           support any bus type (I2C, SPI) but so far this only supports
 134           direct memory access.
 135
 136 config TPL_REGMAP
 137         bool "Support register maps in TPL"
 138         depends on TPL_DM
 139         help
 140           Hardware peripherals tend to have one or more sets of registers
 141           which can be accessed to control the hardware. A register map
 142           models this with a simple read/write interface. It can in principle
 143           support any bus type (I2C, SPI) but so far this only supports
 144           direct memory access.
 145
 146 config SYSCON
 147         bool "Support system controllers"
 148         depends on REGMAP
 149         help
 150           Many SoCs have a number of system controllers which are dealt with
 151           as a group by a single driver. Some common functionality is provided
 152           by this uclass, including accessing registers via regmap and
 153           assigning a unique number to each.
 154
 155 config SPL_SYSCON
 156         bool "Support system controllers in SPL"
 157         depends on SPL_REGMAP
 158         help
 159           Many SoCs have a number of system controllers which are dealt with
 160           as a group by a single driver. Some common functionality is provided
 161           by this uclass, including accessing registers via regmap and
 162           assigning a unique number to each.
 163
 164 config TPL_SYSCON
 165         bool "Support system controllers in TPL"
 166         depends on TPL_REGMAP
 167         help
 168           Many SoCs have a number of system controllers which are dealt with
 169           as a group by a single driver. Some common functionality is provided
 170           by this uclass, including accessing registers via regmap and
 171           assigning a unique number to each.
 172
 173 config DEVRES
 174         bool "Managed device resources"
 175         depends on DM
 176         help
 177           This option enables the Managed device resources core support.
 178           Device resources managed by the devres framework are automatically
 179           released whether initialization fails half-way or the device gets
 180           detached.
 181
 182           If this option is disabled, devres functions fall back to
 183           non-managed variants.  For example, devres_alloc() to kzalloc(),
 184           devm_kmalloc() to kmalloc(), etc.
 185
 186 config DEBUG_DEVRES
 187         bool "Managed device resources debugging functions"
 188         depends on DEVRES
 189         help
 190           If this option is enabled, devres debug messages are printed.
 191           Also, a function is available to dump a list of device resources.
 192           Select this if you are having a problem with devres or want to
 193           debug resource management for a managed device.
 194
 195           If you are unsure about this, Say N here.
 196
 197 config SIMPLE_BUS
 198         bool "Support simple-bus driver"
 199         depends on DM && OF_CONTROL
 200         default y
 201         help
 202           Supports the 'simple-bus' driver, which is used on some systems.
 203
 204 config SPL_SIMPLE_BUS
 205         bool "Support simple-bus driver in SPL"
 206         depends on SPL_DM && SPL_OF_CONTROL
 207         default y
 208         help
 209           Supports the 'simple-bus' driver, which is used on some systems
 210           in SPL.
 211
 212 config SIMPLE_PM_BUS
 213         bool "Support simple-pm-bus driver"
 214         depends on DM && OF_CONTROL && CLK && POWER_DOMAIN
 215         help
 216           Supports the 'simple-pm-bus' driver, which is used for busses that
 217           have power domains and/or clocks which need to be enabled before use.
 218
 219 config OF_TRANSLATE
 220         bool "Translate addresses using fdt_translate_address"
 221         depends on DM && OF_CONTROL
 222         default y
 223         help
 224           If this option is enabled, the reg property will be translated
 225           using the fdt_translate_address() function. This is necessary
 226           on some platforms (e.g. MVEBU) using complex "ranges"
 227           properties in many nodes. As this translation is not handled
 228           correctly in the default simple_bus_translate() function.
 229
 230           If this option is not enabled, simple_bus_translate() will be
 231           used for the address translation. This function is faster and
 232           smaller in size than fdt_translate_address().
 233
 234 config SPL_OF_TRANSLATE
 235         bool "Translate addresses using fdt_translate_address in SPL"
 236         depends on SPL_DM && SPL_OF_CONTROL
 237         default n
 238         help
 239           If this option is enabled, the reg property will be translated
 240           using the fdt_translate_address() function. This is necessary
 241           on some platforms (e.g. MVEBU) using complex "ranges"
 242           properties in many nodes. As this translation is not handled
 243           correctly in the default simple_bus_translate() function.
 244
 245           If this option is not enabled, simple_bus_translate() will be
 246           used for the address translation. This function is faster and
 247           smaller in size than fdt_translate_address().
 248
 249 config TRANSLATION_OFFSET
 250         bool "Platforms specific translation offset"
 251         depends on DM && OF_CONTROL
 252         help
 253           Some platforms need a special address translation. Those
 254           platforms (e.g. mvebu in SPL) can configure a translation
 255           offset by enabling this option and setting the translation_offset
 256           variable in the GD in their platform- / board-specific code.
 257
 258 config OF_ISA_BUS
 259         bool
 260         depends on OF_TRANSLATE
 261         help
 262           Is this option is enabled then support for the ISA bus will
 263           be included for addresses read from DT. This is something that
 264           should be known to be required or not based upon the board
 265           being targeted, and whether or not it makes use of an ISA bus.
 266
 267           The bus is matched based upon its node name equalling "isa". The
 268           busses #address-cells should equal 2, with the first cell being
 269           used to hold flags & flag 0x1 indicating that the address range
 270           should be accessed using I/O port in/out accessors. The second
 271           cell holds the offset into ISA bus address space. The #size-cells
 272           property should equal 1, and of course holds the size of the
 273           address range used by a device.
 274
 275           If this option is not enabled then support for the ISA bus is
 276           not included and any such busses used in DT will be treated as
 277           typical simple-bus compatible busses. This will lead to
 278           mistranslation of device addresses, so ensure that this is
 279           enabled if your board does include an ISA bus.
 280
 281 config DM_DEV_READ_INLINE
 282         bool
 283         default y if !OF_LIVE
 284
 285 config ACPIGEN
 286         bool "Support ACPI table generation in driver model"
 287         default y if SANDBOX || (GENERATE_ACPI_TABLE && !QEMU)
 288         help
 289           This option enables generation of ACPI tables using driver-model
 290           devices. It adds a new operation struct to each driver, to support
 291           things like generating device-specific tables and returning the ACPI
 292           name of a device.
 293
 294 config INTEL_ACPIGEN
 295         bool "Support ACPI table generation for Intel SoCs"
 296         depends on ACPIGEN
 297         help
 298           This option adds some functions used for programatic generation of
 299           ACPI tables on Intel SoCs. This provides features for writing CPU
 300           information such as P states and T stages. Also included is a way
 301           to create a GNVS table and set it up.
 302
 303 config BOUNCE_BUFFER
 304         bool "Include bounce buffer API"
 305         help
 306           Some peripherals support DMA from a subset of physically
 307           addressable memory only.  To support such peripherals, the
 308           bounce buffer API uses a temporary buffer: it copies data
 309           to/from DMA regions while managing cache operations.
 310
 311           A second possible use of bounce buffers is their ability to
 312           provide aligned buffers for DMA operations.
 313
 314 endmenu