QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

[Nicolas Pitre]

On Mon, 15 Mar 2010, Armando VISCONTI wrote:

> > 
> > What I think you really want is for your board-specific code (or some
> > helper code elsewhere in your mach-* directory) to do the pin
> > assignments, and the drivers just assume that the pins are all right. That's
> > the approach used in OMAP2 and AT91, among others, and it seems
> > to work out just fine.
> >   
> 
> Bill,
> 
> What you and Russell are saying is a little bit different from what I got
> since
> now, with people suggesting to implement a single linux image which is
> then configured at runtime thru (for example) bootargs.
> 
> Now you both are saying that compile time options are better, correct?

No.

> So, we have two choices:
> 
> 1. Stay as it is, which means to use menuconfig options.
> 2. Provide board-specific code in the mach-spear directory.
> 
> You are suggesting 2, which also seems to be the pin_config stuff
> inside mach-pxa. Am I aligned?

Yes.  Another good example that you might have a look at is 
arch/arm/mach-kirkwood/*-setup.c.  Those files are defining what and how 
each of those particular machine targets should be configured.  And for 
the multiplexed pin config, there is a mpp.h which statically defines 
all the possible combinations for each pin, including the function type 
(GPIO or dedicated function), the direction, and a bitmask of specific 
SOC versions each definition may apply to.  Then a list of those is 
passed to kirkwood_mpp_conf() which performs the appropriate validation 
and configuration.

Please take the time to look at a couple examples like those.  You 
should get a good idea of the overall strategy and one of those might be 
a better example than the others to follow for your particular hardware.


Nicolas