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
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
