[PATCH 0/4] Pinmux subsystem

Matthieu Castet matthieu.castet at parrot.com
Thu May 12 17:17:02 EDT 2011


+In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port
+(these are four pins: CLK, RXD, TXD, FRM). In that case, pin B5 can be used as
+some general-purpose GPIO pin. However, in another setting, pins { A5, B5 } can
+be used as an I2C port (these are just two pins: SCL, SDA). Needless to say,
+we cannot use the SPI port and I2C port at the same time. However in the inside
+of the package the silicon performing the SPI logic can alternatively be routed
+out on pins { G4, G3, G2, G1 }.

Enumerating all possible case will be impossible because of the number of possible cases 
(and hardware guys can be very creative).

If spi can be in  { A8, A7, A6, A5 } and 
{ G4, G3, G2, G1 }, Then you can output the spi on :
- { A8, A7, A6, A5 }
- { A8, A7, A6, G1 }
- { A8, A7, G2, A5 }
[...]
- { G4, G3, G2, A5 }
- { G4, G3, G2, G1 }
You have 2^4 = 16 cases

Now RXD (MISO) or/and FRM (CS) can be not connected and used as a gpio. You have 4 * 16 cases = 64 cases.

Now take a complex chip, 200 balls 4 mux per ball and you can have up to 4^200 configurations...

Pin muxing is really board specific  and shouldn't be in a "generic" driver.

But what you could abstract is a way to select a configuration of a pin, not a group of pin
 for the board files.

Matthieu


More information about the linux-arm-kernel mailing list