Re: [RFC] pinctrl: Provide a generic device tree binding for per-pin pin controllers

[Sascha Hauer]

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:
> > 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.

> 
> > 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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/