Re: Pinmux driver model: per board vs. unified
Andre Guedes <andre.guedes@...>
Hi all,toggle quoted messageShow quoted text
Here is one proposal on how we can deal with pinmux drivers and board-
specific pinmux configurations:
1. All pinmux drivers land in driver/pinmux/ directory and they all
implement the include/pinmux.h API only.
2. Board-specific code (e.g. board/quark_d2000_crb/board.c) defines
the pinmux table and uses the pinmux APIs to apply its specific
configurations. To achieve that, we could define the board_init()
function in board.c which would handle any board-specific initialization,
including pinmux configuration. We could use SYS_INIT() so board_init()
is executed during kernel initialization.
In order to this approach work, we have to ensure the pinmux driver is
initialized before board_init() is called. This can be achieved by setting
pinmux driver initialization to PRIMARY level and board_init() to SECONDARY
AFAICS, this approach would work for all boards, besides Galileo. Pinmux
in Galileo is quite different and it would require a special handling.
Since Galileo pinmux driver depends on others devices (I2C, PCA9535 and
PCAL9685) we cannot init it on PRIMARY level. So the Galileo board_init()
would be set to SECONDARY level and we use the 'prio' argument from
SYS_INIT() to ensure board_init() is executed after galileo pinmux
Quoting Vinicius Costa Gomes (2016-02-23 15:18:25)
So I like the idea here to move all the code common to manipulatingMakes sense.