[U-Boot] some questions about u-boot's driver model

[Robert P. J. Day]

  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
========================================================================