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