Date:	Wed, 26 Jun 2013 11:33:19 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Christian Ruppert <christian.ruppert@...lis.com>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Patrice CHOTARD <patrice.chotard@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Sascha Leuenberger <sascha.leuenberger@...lis.com>,
	Pierrick Hascoet <pierrick.hascoet@...lis.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>
Subject: Re: [PATCH 1/4] Make non-linear GPIO ranges accesible from gpiolib

On 06/26/2013 05:42 AM, Christian Ruppert wrote:
> 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@...lis.com> 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@...lis.com>
>>>
>>> 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@...0 {
>>>> +               #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";
> 	};

Multiple properties seems a little like over-kill, although I agree it
makes specifying the format of the properties simplest.

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

This one seems fine to me. In many ways it's the simplest.

I guess I'd be OK with either (1) or (2) if someone else had a strong
opinion either way, although I'd tend towards (2) myself I think.

It's a pity properties don't carry type information in them, or we could
just put the string inline with the numbers in gpio-ranges:-(

> 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";
> 	};

I don't like that, because the pin controller node shouldn't determine
the format of the gpio-ranges entries here; a DT author would always
have the choice to use purely numerical values in gpio-ranges even if
the pinctrl node's binding did actually define named pin groups that
would allow you to use group names. Hence, the concept of the pinctrl
node having a #gpio-range-cells property seems wrong to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists