Re: Pinmux driver model: per board vs. unified

Dirk Brandewie <dirk.j.brandewie@...>

On 02/24/2016 01:34 PM, Vinicius Costa Gomes wrote:
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
yeah better idea :-D when the quark_se gets more design wins things
would get crowded.

Now the question is who is signing up to do the refactoring? :-)

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.