Re: Pinmux driver model: per board vs. unified

Andre Guedes <andre.guedes@...>

Hi all,

Quoting Vinicius Costa Gomes (2016-02-24 18:34:16)
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
Yes, I also like this proposal and I think we should move with it instead
of with the proposal I did.

I have just one comment regarding the 'pinmux board driver'. The way I see
it, what we are calling 'pinmux board driver' is more like a board-specific
initialization code than a driver per se. And, as a board-specific code, I
think we should land it in board/.

For 'pinmux dev driver', yes, it totally make sense to me that we should
land them in driver/ and the user can build it if his/her *application*
requires it.



Join to automatically receive all group messages.