On 07/26/2013 03:42 AM, Christian Ruppert wrote:

On Thu, Jul 18, 2013 at 01:54:18PM -0600, Stephen Warren wrote:

quoted

On 07/18/2013 10:07 AM, Christian Ruppert wrote:
...

quoted

Well, perhaps my definition of "inside"/"outside" pins was not quite
clear: The pin groups define the set of (kernel internal) pin numbers of
"outside" pins which are used by pin controller to map a given
interface. Inside pins are not numbered and the inside interfaces are
only used to determine which outside pins are part of the same group
(namely those for which the pin controller hardware provides a mux
connection to the same inside interface):

                       4
                4  /|--/-- SPI
   PINS[0..3] --/--||  4
                   \|--/-- GPIO[0..3]

                   4
   PINS[4..7] -----/------ GPIO[4..7]

                       2
                2  /|--/-- I2C
   PINS[8..9] --/--||  2
                   \|--/-- GPIO[8..9]

Pins 0..3 are in the SPI group because on the "inside" they can be muxed
to the SPI interface.
Pins 8..9 are in the I2C group because on the "inside" they can be muxed
to the I2C interface.
Pins 0..9 are in the GPIO group because on the "inside" they can be
muxed to the GPIO controller.

All pin numbers are relative to the "outside", however, or conflict
management would not be possible. I hope this is more understandable
than my previous explanations.
Both muxes are controlled by the same register. In our overly simplistic
example this is not strictly necessary but in reality you might have pin
conflicts between the different interfaces.

Same register, or same field/bits in that register?

If it's the same field/bits, I would expect to see the following pin groups:

1) PINS[0..3], PINS[8..9]
2) PINS[4..7]

... since those are the things that are independently muxable.
Otherwise, I'd expect to see the following groups:

1) PINS[0..3]
2) PINS[4..7]
3) PINS[8..9]

quoted

After the discussion we had so far I'm not so sure if extending the
pinctrl system with this kind of features is a very good idea.

That makes things simple:-)

One thing I still don't understand; in a previous mail, you'd mentioned
3 DT properties for configuring the pinmux; one represented the pin
group, one represented the mux function that was selected for that pin
group, and there was a third ("config"?) property. I still don't
understand that third property. I only see pins/pingroups and mux
functions in the diagram I quoted above.

In my proposal, pin groups represent interfaces instead of ports: All
three pin groups are configured through the same bit field in the same
register but they represent _logically_ independent functionalities.

Oh, that's a pretty "coupled" HW design!

I would suggest having a single pin group for all 10 pins (since that's
what HW really has). I imagine with that HW design, there's very little
potential for any kind of dynamic pin-muxing, since it would affect
multiple unrelated HW modules (I2C, SPI), and hence the co-ordination
required for dynamic muxing would make it impractical. As such I would
also specify the pinctrl configuration as a "hog" in the pin controller,
since each configuration bit affects multiple other devices, so it
doesn't make logical sense to try to specify the pinctrl configuration
anywhere other than the pin controller.

The three DT properties are:

1. interface (which pins are we actually interested in when requesting
   this)
2. port (which bit field/register is used to configure this)
3. configuration of that port (which mux function(s) in that bit
   field/register are possible to make the interface available)