On 07/08/2013 07:02 AM, Christian Ruppert wrote:
...

OK, a small drawing of our hardware should make this clear, let's take
an imaginary example of one port with 10 pins, one i2c interface, one
spi interface and one GPIO bank:

              | mux N-1|
              +........+
              |        |  2
              |        +--/-- i2c
              |        |
           10 |        |  4
   Pins  --/--+ mux N  +--/-- spi
              |        |
              |        |  10
              |        +--/-- GPIO
              |        |
              +........+
              | mux N+1|

This example shows the mux N inside the pin controller. It controls
all pins associated to port N through a single register value M. Let's
assume the pins are configured as follows in function of the register
value:

 pin      M=0       M=1     M=2      M=3
  0      GPIO0   SPI_MISO  GPIO0   SPI_MISO
  1      GPIO1   SPI_MOSI  GPIO1   SPI_MOSI
  2      GPIO2    SPI_CK   GPIO2    SPI_CK
  3      GPIO3    SPI_CS   GPIO3    SPI_CS
  4      GPIO4    GPIO4    GPIO4    GPIO4
  5      GPIO5    GPIO5    GPIO5    GPIO5
  6      GPIO6    GPIO6    GPIO6    GPIO6
  7      GPIO7    GPIO7    GPIO7    GPIO7
  8      GPIO8    GPIO8   I2C_SDA  I2C_SDA
  9      GPIO9    GPIO9   I2C_SCL  I2C_SCL

In that scenario, in the language of Linux's pinctrl subsystem, what you
have is:

10 pins, named 0..9
1 pin group, named perhaps "mux N".
4 different functions; values M==0, 1, 2, 3.

We now have three pin groups defined, corresponding to the chip-side
ports of the pin controller:
GPIO = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
SPI  = {0, 1, 2, 3}
I2C  = {8, 9}

You would usually only define pin groups for the pin/ball/package side
of the pinmux HW. IIRC, you're also wanting to define pin groups for the
intra-chip side of the pinmux HW. However, you're not muxing functions
onto those pingroups; they're just there to help with naming the
GPIO<->pinmux mapping. You only mux functions onto the pin/ball/package
side pins/pingroups.

abilis,pingrp now specifies one of the three pin groups. Note that I2C
       and SPI can be requested independently in a completely orthogonal
       manner: The information if I2C is reqired or not is confined to
       the I2C request and does not leak into the SPI request as would
       be the case if we configured the entire port at the same time.

The pingrp should represent the pin/ball/package side pins/groups. In
this case, it should specify "N".

abilis,ioport specifies N.

That is replaced be pingrp.

abilis,ioconf specifies M.

That'd be better named "function" or something like that, in order to
indicate that it specifies which function is mux'd onto the specified
pin(s)/pingroup(s).