i'm currently trying to wrap my head around the aspects of converting the various u-boot subsystems to use the driver model, and i'll do this in a number of posts so as to not have one monstrously large post, and i'm sure i will have some truly dumb questions, so apologies beforehand for those.

i'm working off this page as a starting point:

http://www.denx.de/wiki/U-Boot/DriverModel

and pawing through the code base to try to understand the big picture, so first question.

i can see that general driver model support is defined in drivers/core/Kconfig:

menu "Generic Driver Options"

config DM bool "Enable Driver Model" help This config option enables Driver Model. This brings in the core support, including scanning of platform data on start-up. If CONFIG_OF_CONTROL is enabled, the device tree will be scanned also when available.

(side note about that file: seems like a lot of Kbuild entries in that file contain the line "depends on DM", when it looks like one could just wrap a large part of that file in a single "if DM" testi to simplify things. but ... onward.)

i initially thought driver model support was included by one having to specifically select that option, until i saw all the "select DM" Kbuild lines scattered throughout the code base that explicitly selected that option based on architecture or target board.

for instance, here's some snippets from arch/Kconfig (irrelevant lines removed):

config NIOS2 bool "Nios II architecture" select SUPPORT_OF_CONTROL select OF_CONTROL select DM select CPU

config SANDBOX bool "Sandbox" select SUPPORT_OF_CONTROL select DM select DM_KEYBOARD select DM_SPI_FLASH select DM_SERIAL select DM_I2C select DM_SPI select DM_GPIO select DM_MMC

config X86 bool "x86 architecture" select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC select SUPPORT_OF_CONTROL select DM select DM_KEYBOARD select DM_SERIAL select DM_GPIO select DM_SPI select DM_SPI_FLASH

so i can see that a variety of driver model support is selected either at the architecture level, in some cases including driver model support for particular subsystems, or if not at the architecture level:

config ARM bool "ARM architecture" select CREATE_ARCH_SYMLINK select HAVE_PRIVATE_LIBGCC if !ARM64 select SUPPORT_OF_CONTROL

then possibly at the CPU or board level:

arch/arm/Kconfig:

config ARCH_MVEBU bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" select OF_CONTROL select OF_SEPARATE select DM select DM_ETH select DM_SERIAL select DM_SPI select DM_SPI_FLASH

or:

arch/arm/mach-litesom/Kconfig:

config LITESOM bool select MX6UL select DM select DM_THERMAL select SUPPORT_SPL

so what is the general workflow for adding/selecting driver model support? seems like it can be selected/defined at a number of levels:

* entire architecture * CPU * target board

is there a recipe for how driver model is slowly added to u-boot, based on updating Kconfig files for the above?

more questions coming as i keep reading ...

rday