ar71xx_gpio.c touches SPI_CS1 and 2?

[Warner Losh]

On Dec 4, 2011, at 6:29 PM, Adrian Chadd wrote:

> On 5 December 2011 01:19, Warner Losh <imp at bsdimp.com> wrote:
> 
>> When I was looking into this question for the Atmel chips, I was torn.  On the one hand, it would be nice if there was a pin mux device.  On the other hand, it didn't map well into the device model.  I finally settled on having per-board functions that setup the pins.  This is also the model followed by linux.  Either the boot loader or the board-dependent code would do the setup.
> 
> I think we should have a per-board set of hints which lets us dictate
> non-default GPIO functions and config.

You are thinking too narrowly here.  It should be thought of as assigning pin function rather than some GPIO thing.   On the Atmel, you can set multiplex functions (either GPIO, or  Ethernet Tx+ for this pin, etc).

I too have wanted per-board hints, possibly several sets in one kernel, but never had the time to bring that to fruition.

> That way we can override what's going on in the board config without
> having to write C code.
> 
> As i said, something like this:
> 
> hint.blah.gpiofunction_set="0x10000000"
> hint.blah.gpiofunction_clear="0x00130000"

For the AR71xx, that might suffice, but it isn't adequate in general.  I also really don't like the names, since it is more of a pin function than a GPIO function.

> It'd also be useful if the device drivers would do this themselves -
> eg the ar71xx USB device driver could ensure that the relevant GPIO
> function wire were enabled.

No.  That's wrong, at least generally.  The USB driver has no business setting these things up.  That's for the board level init code.  The board level init code can pass data to the USB driver saying that it set things up for USB and the driver can then fail to attach when those pins are setup for other things.

Having tried to get all the Atmel drivers to automagically set themselves up turned out to be a total fiasco.  I tried it when I was bringing the boards at Timing Solutions up.  It worked great for the eval board, but turned into a night mare of special case hacks when I moved the code over to the custom board we were developing.  I'd strongly suggest that the driver is not the place to do this, any more than the driver is the place to assign PCI resources: this sort of thing belongs at a higher level.

> But we may need to _disable_ some of these
> default pins (eg if the eeprom has enabled the digital sound function
> block on the SoC) so i still think having the above would work.

Right, that's why I think that the board init code should be the one to muck with the pins.  Wether that is done via hints or hard-coded 'C' I don't care too much for, but inside the driver is definitely the wrong place to do it.

Warner