Hi Stephen,

On Wed, Oct 29, 2014 at 10:05:40PM -0600, Stephen Warren wrote:

On 10/23/2014 07:23 AM, Sascha Hauer wrote:

quoted

Most iomux controllers allow a configuration per pin. These currently
have no common device tree binding. There are many different SoC
specific bindings for this class of iomux controllers. Some controllers
artificially group pins together where in hardware no groups exist (for
example lantiq). Other controllers just put each pin into a separate
group which explodes to many many strings to parse (Tegra30).


A pin controller has n pins, each muxable to m different positions.

I assume that sentence is meant to say something more specific:

This binding is intended to apply to pin controllers where each pin has
an independently selectable mux function.

Yes.

"A pin controller ..." sounds like a general statement that is intended
to apply to any pin controller. If that were intended, the statement you
made certainly wouldn't be true.

Right.

quoted

There exists a logical numbering for all pins, for most SoCs this will
be defined by the register ordering so that the pin number can directly
be translated to a register offset without the need of tables in the
driver. The register usually takes m different numbers to specify the
function the pin should have. Both the pin and its function can be
described as a single 32bit number:

#define PINMUX_PIN(no, fn) (((no) & 0xffffff) << 8) | (fn) & 0xff)

This allows to put multiple pins into a single device tree property
which is very efficiently parsable by the driver (or the pinmux core).
We suggest to name this property 'pins' and to put it next to the
generic pinconf binding.  This allows to describe multiple pins with the
same pinconf settings in a single device tree node. Multiple of these
nodes can be grouped under a pinctrl state node. This allows to put pins
with different pinconf settings to a single state.

Example:

	uart2 {
		uart2_default_mode: uart2_default {
			pins1 {
				pins = <PINMUX_PIN(127, 3), PINMUX_PIN(128, 3)>;

Within each of the nodes, the binding for pinmux is defined
independently by each pin controller. I don't have any /strong/
objection to any particular pin controller using this binding, or even
it being re-used across many similar pin controllers, or even being
the/a default binding style for new pin controllers.

I'm not totally sure whether blending the pin ID and mux function ID
into the same value is a good idea. That said, it does have advantages
as you state, and shouldn't cause any significant issues. In any case
where it would be a bad idea, the binding for the pin controller in
question can still choose to use some more appropriate binding, so
allowing this binding for some controllers won't force issues onto other
controllers. So, it seems fine.

Note however that we can't change existing bindings. Well, I suppose
certain bindings could be enhanced to support either a string-based or
an integer-base binding, but I don't think that'd be a good idea.

I'm only talking about new bindings, no need to change existing
bindings. For new bindings it surely has benefits when we can just point
to a well established binding. Right now the existing bindings for the
pin controllers which independently control each pin differ a lot.

The next step should be to integrate the above into the pinctrl
documentation.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |