Re: [PATCH 1/4] Make non-linear GPIO ranges accesible from gpiolib

[Christian Ruppert]

On Wed, Jun 19, 2013 at 12:15:13PM -0600, Stephen Warren wrote:
> On 06/19/2013 06:03 AM, Linus Walleij wrote:
> > On Tue, Jun 18, 2013 at 11:29 AM, Christian Ruppert
> > <christian.ruppert@xxxxxxxxxx> wrote:
> > 
> >> This patch adds the infrastructure required to register non-linear gpio
> >> ranges through gpiolib and the standard GPIO device tree bindings.
> >>
> >> Signed-off-by: Christian Ruppert <christian.ruppert@xxxxxxxxxx>
> > 
> > I'm basically fine with this, but would like Stephen's ACK if possible.
> > 
> >> +In addition, named groups of pins can be mapped to pin groups of a given
> >> +pin controller:
> >> +
> >> +       gpio_pio_g: gpio-controller@1480 {
> >> +               #gpio-cells = <2>;
> >> +               compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
> >> +               reg = <0x1480 0x18>;
> >> +               gpio-controller;
> >> +               gpio-ranges = <&pinctrl1 0 0 0>, <&pinctrl2 3 0 0>;
> >> +               gpio-ranges-group-names = "foo", "bar";
> >> +       };
> >> +
> >> +where,
> >> +   &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
> >> +
> >> +   The following value specifies the base GPIO offset of the pin range with
> >> +   respect to the GPIO controller's base. The remaining two values must be
> >> +   0 to indicate that a named pin group should be used for the respective
> >> +   range. The number of pins in the range is the number of pins in the pin
> >> +   group.
> > 
> > So while this works, these zeroes seem a bit awkward, but maybe
> > it's the only way?
> > 
> > I'm not good enough on device tree conventions, but isn't this possible:
> > 
> >               gpio-ranges = <&pinctrl1 0>, <&pinctrl2 3>;
> >               gpio-ranges-group-names = "foo", "bar";
> > 
> > Since we don't have any #gpio-ranges-cells or anything like that I
> > guess we can define this to have a flexible number of cells
> > depending on use case?
> 
> If we're willing to have gpio-ranges be either *all* group names, or
> *all* IDs, we can define the format of gpio-ranges to have two cells
> (phandle and GPIO number) if the property gpio-ranges-group-names
> exists, but four cells (phandle, GPIO number, pin number, count)
> otherwise. However, that's a little restrictive, since then what if one
> GPIO controller is hooked to two different pinmux controllers, and you
> want to use different formats for the references to each. A
> #gpio-ranges-cells in the target of the phandle would allow this, but I
> don't think this is something the pinctrl node should dictate to those
> who reference it; it's quite legitimate for a GPIO node to use the pure
> numeric mapping even if the pin controller happens to expose some pin
> groups that allow you to do the mapping by name.

I actually had a version of the patch with #gpio-range-cells specifying
the format (one argument for named ranges, three for classical ranges)
before deciding to use a separate property and sending that version. As
I said in a previous mail, I don't have a preference which of the
following three possibilities to use and would be grateful for some
guidance (if it matters at all).

1.) separate property:
	gpio {
		gpio-ranges = <&pinctrl1 0 0 5>;
		gpio-range-groups = <&pinctrl2 5>;
		gpio-range-group-names = "gpios";
	};

2.) fixed number of three arguments:
	gpio {
		gpio-ranges = <&pinctrl1 0 0 5>, <&pinctrl2 5 0 0>;
		gpio-range-names = "", "gpios";
	};

3.) pinctrl-defined format.
	pinctrl1: pctl1 {
		#gpio-range-cells = <3>;
	};
	pinctrl2: pctl2 {
		#gpio-range-cells = <1>;
	};
	gpio {
		gpio-ranges = <&pinctrl1 0 0 5>, <&pinctrl2 5>;
		gpio-range-names = "", "gpios";
	};

-- 
  Christian Ruppert              ,          <christian.ruppert@xxxxxxxxxx>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates
--
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/