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 level. 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 initialization. Regards, Andre 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.
|
|