Re: Pinmux driver model: per board vs. unified

Vinicius Costa Gomes

Hi Dirk,

Dirk Brandewie <dirk.j.brandewie(a)> writes:


After writing this mail, looking at the code again I have a alternate

1. move the current pinmux drivers back into drivers with reasonable

2. remove the API support from all the drivers and move it to a
quark_pinmux_dev driver that just provides the API if people really
need runtime control of the pin configuration they can build the

So all the replicated code moves to a single place where it is needed
and the remaining pimux driver only do init() and are done.
I like it.

The only thing I am thinking about is polluting the drivers/pinmux/
directory when there are more than a couple of board variants. But this
may not be a problem.

I would only propose to have a different directory for the 'pinmux_dev'
driver. From what I understand, there would be no code shared between
the pinmux "board" driver and the pinmux "dev" driver (the only
information needed seems to be what is already provided by

And all concerns that were raised about the increases in ROM size and boot
time overhead seems to be addressed.


Join to automatically receive all group messages.