On 10/09/2013 05:58 AM, Linus Walleij wrote:
> On Tue, Oct 8, 2013 at 2:25 PM, 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.
...
>> +Example:
>> +
>> + gpio_pio_i: gpio-controller@14B0 {
>> + #gpio-cells = <2>;
>> + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
>> + reg = <0x1480 0x18>;
>> + gpio-controller;
>> + gpio-ranges = <&pinctrl1 0 20 10>,
>> + <&pinctrl2 10 0 0>,
>> + <&pinctrl1 15 0 10>,
>> + <&pinctrl2 25 0 0>;
>> + gpio-ranges-group-names = "",
>> + "foo",
>> + "",
>> + "bar";
>> + };
>
> And here, I get a bit uneasy as I remember Stephen's stance that such
> groups must be a physical property of the controller. I am generally a
> bit soft on that, but that is from a driver point of view, and describing
> hardware in the devicetree must be reflecting an objective view of the
> hardware, not how the particular driver is written for Linux.
>
> This is very questionable :-/
I think describing the GPIO ranges is an aspect of the HW; it's
describing actual routing of signal lines between the GPIO and pinctrl
HW blocks. It seems reasonable for DT to describe that concept (although
perhaps the actual mapping could be part of some driver rather than DT,
but that's a separate issue).
Using groups to describe aspects of this mapping doesn't seem totally
unreasonable either. We have named groups for muxing, which is a real HW
property. We can have named groups for GPIO/pinctrl routing, which again
is a HW property. Certainly in the muxing case, and hopefully for this
case too, the naming of those groups is driven purely by the HW design
of the SoC top-level or GPIO/pinctrl HW blocks, and hence it's
reasonable for a DT binding to define (or rather, use) those names.
Hopefully different OSs don't use different names for the groups, since
the naming is derived directly from HW.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
