[PATCH V4 2/2] gpio: inverter: document the inverter bindings

[PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Document the device tree binding for the inverter gpio
controller to configure the polarity of the gpio pins
used by the consumers.

Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
---
 .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
new file mode 100644
index 0000000..8bb6b2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
@@ -0,0 +1,29 @@
+GPIO-INVERTER
+======
+This binding defines the gpio-inverter. The gpio-inverter is a driver that
+allows to properly describe the gpio polarities on the hardware.
+
+Please refer to gpio.txt for generic information regarding GPIO bindings.
+
+Required properties:
+- compatible : "gpio-inverter".
+- gpio-controller: Marks the port as GPIO controller.
+- #gpio-cells: One. This is the pin number.
+- inverted-gpios: Array of GPIO pins required from consumers, whose polarity
+  has to be inverted in the driver.
+Note: gpio flag should be set as GPIO_ACTIVE_HIGH. Using GPIO_ACTICE_LOW will
+cause double inversion.
+
+Optional properties:
+- gpio-line-names: Refer to gpio.txt for details regarding this property.
+
+Example:
+
+gpio_inv: gpio-inv {
+	compatible = "gpio-inverter";
+	gpio-controller;
+	#gpio-cells = <1>;
+	inverted-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>,
+	<&gpio7 0 GPIO_ACTIVE_HIGH>, <&gpio7 1 GPIO_ACTIVE_HIGH>;
+	gpio-line-names = "JTAG_DNL_EN", "lvds-pwrdwn", "lcd-on";
+};
--
2.7.4

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi,

On 28/06/19 3:00 PM, Harish Jenny K N wrote:
> Document the device tree binding for the inverter gpio
> controller to configure the polarity of the gpio pins
> used by the consumers.
>
> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
> ---
>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> new file mode 100644
> index 0000000..8bb6b2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> @@ -0,0 +1,29 @@
> +GPIO-INVERTER
> +======
> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
> +allows to properly describe the gpio polarities on the hardware.
> +
> +Please refer to gpio.txt for generic information regarding GPIO bindings.
> +
> +Required properties:
> +- compatible : "gpio-inverter".
> +- gpio-controller: Marks the port as GPIO controller.
> +- #gpio-cells: One. This is the pin number.
> +- inverted-gpios: Array of GPIO pins required from consumers, whose polarity
> +  has to be inverted in the driver.
> +Note: gpio flag should be set as GPIO_ACTIVE_HIGH. Using GPIO_ACTICE_LOW will
> +cause double inversion.
> +
> +Optional properties:
> +- gpio-line-names: Refer to gpio.txt for details regarding this property.
> +
> +Example:
> +
> +gpio_inv: gpio-inv {
> +	compatible = "gpio-inverter";
> +	gpio-controller;
> +	#gpio-cells = <1>;
> +	inverted-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>,
> +	<&gpio7 0 GPIO_ACTIVE_HIGH>, <&gpio7 1 GPIO_ACTIVE_HIGH>;
> +	gpio-line-names = "JTAG_DNL_EN", "lvds-pwrdwn", "lcd-on";
> +};
> --
> 2.7.4
>

Can anyone of DT people please review this ?

Just to let you know that Linus Walleij has reviewed the gpio inverter driver and needs some review from the DT people before he applies it.

Thanks in advance.


Best Regards,

Harish Jenny K N

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Rob Herring]

On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
>
> Document the device tree binding for the inverter gpio
> controller to configure the polarity of the gpio pins
> used by the consumers.
>
> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
> ---
>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> new file mode 100644
> index 0000000..8bb6b2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> @@ -0,0 +1,29 @@
> +GPIO-INVERTER
> +======
> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
> +allows to properly describe the gpio polarities on the hardware.

I don't understand. Please explain this in terms of the hardware, not a driver.

Rob

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Rob,


On 09/07/19 4:06 AM, Rob Herring wrote:
> On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
> <harish_kandiga@mentor.com> wrote:
>> Document the device tree binding for the inverter gpio
>> controller to configure the polarity of the gpio pins
>> used by the consumers.
>>
>> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
>> ---
>>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>> new file mode 100644
>> index 0000000..8bb6b2e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>> @@ -0,0 +1,29 @@
>> +GPIO-INVERTER
>> +======
>> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
>> +allows to properly describe the gpio polarities on the hardware.
> I don't understand. Please explain this in terms of the hardware, not a driver.


gpio inverters can be used on different hardware to alter the polarity of gpio chips.
The polarity of pins can change from hardware to hardware with the use of inverters.
This device tree binding models gpio inverters in the device tree to properly describe the hardware.

Please let me know if this is enough and needs to be updated in the documentation patch.


I am sorry I did not include device tree list in the original discussion ( i.e first version of the patch
https://www.spinics.net/lists/linux-gpio/msg39681.html).


Thanks.


Best Regards,

Harish Jenny K N

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Rob Herring]

On Mon, Jul 8, 2019 at 11:25 PM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
>
> Hi Rob,
>
>
> On 09/07/19 4:06 AM, Rob Herring wrote:
> > On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
> > <harish_kandiga@mentor.com> wrote:
> >> Document the device tree binding for the inverter gpio
> >> controller to configure the polarity of the gpio pins
> >> used by the consumers.
> >>
> >> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
> >> ---
> >>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
> >>  1 file changed, 29 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> >> new file mode 100644
> >> index 0000000..8bb6b2e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
> >> @@ -0,0 +1,29 @@
> >> +GPIO-INVERTER
> >> +======
> >> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
> >> +allows to properly describe the gpio polarities on the hardware.
> > I don't understand. Please explain this in terms of the hardware, not a driver.
>
>
> gpio inverters can be used on different hardware to alter the polarity of gpio chips.
> The polarity of pins can change from hardware to hardware with the use of inverters.

Yes, I know what an inverter is.

> This device tree binding models gpio inverters in the device tree to properly describe the hardware.

We already define the active state of GPIOs in the consumers. If
there's an inverter in the middle, the consumer active state is simply
inverted. I don't agree that that is a hack as Linus said without some
reasoning why an inverter needs to be modeled in DT. Anything about
what 'userspace' needs is not a reason. That's a Linux thing that has
little to do with hardware description.

Rob

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi,

On 09/07/19 9:38 PM, Rob Herring wrote:
> On Mon, Jul 8, 2019 at 11:25 PM Harish Jenny K N
> <harish_kandiga@mentor.com> wrote:
>> Hi Rob,
>>
>>
>> On 09/07/19 4:06 AM, Rob Herring wrote:
>>> On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
>>> <harish_kandiga@mentor.com> wrote:
>>>> Document the device tree binding for the inverter gpio
>>>> controller to configure the polarity of the gpio pins
>>>> used by the consumers.
>>>>
>>>> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
>>>> ---
>>>>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>>>>  1 file changed, 29 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>> new file mode 100644
>>>> index 0000000..8bb6b2e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>> @@ -0,0 +1,29 @@
>>>> +GPIO-INVERTER
>>>> +======
>>>> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
>>>> +allows to properly describe the gpio polarities on the hardware.
>>> I don't understand. Please explain this in terms of the hardware, not a driver.
>>
>> gpio inverters can be used on different hardware to alter the polarity of gpio chips.
>> The polarity of pins can change from hardware to hardware with the use of inverters.
> Yes, I know what an inverter is.
>
>> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
> We already define the active state of GPIOs in the consumers. If
> there's an inverter in the middle, the consumer active state is simply
> inverted. I don't agree that that is a hack as Linus said without some
> reasoning why an inverter needs to be modeled in DT. Anything about
> what 'userspace' needs is not a reason. That's a Linux thing that has
> little to do with hardware description.


Yes we are talking about the hardware level inversions here. The usecase is for those without the gpio consumer driver. The usecase started with the concept of allowing an abstraction of the underlying hardware for the userland controlling program such that this program does not care whether the GPIO lines are inverted or not physically. In other words, a single userland controlling program can work unmodified across a variety of hardware platforms with the device tree mapping the logical to physical relationship of the GPIO hardware.
I totally understand anything about what 'userspace' needs is not a reason, but this is not restricted to userspace alone as kernel drivers may need this just as much. Also we are just modelling/describing the hardware state in the device tree.

Just to mention that Linus Walleij had proposed this inverter model to describe the hardware and the gpio inverter driver is developed based on comments/review from him.

Also my sincere request to Linus Walleij to please let his opinion know on this.

Thanks,

Best Regards,
Harish Jenny K N

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Linus,

On 10/07/19 1:58 PM, Harish Jenny K N wrote:
> Hi,
>
> On 09/07/19 9:38 PM, Rob Herring wrote:
>> On Mon, Jul 8, 2019 at 11:25 PM Harish Jenny K N
>> <harish_kandiga@mentor.com> wrote:
>>> Hi Rob,
>>>
>>>
>>> On 09/07/19 4:06 AM, Rob Herring wrote:
>>>> On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
>>>> <harish_kandiga@mentor.com> wrote:
>>>>> Document the device tree binding for the inverter gpio
>>>>> controller to configure the polarity of the gpio pins
>>>>> used by the consumers.
>>>>>
>>>>> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
>>>>> ---
>>>>>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>>>>>  1 file changed, 29 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>> new file mode 100644
>>>>> index 0000000..8bb6b2e
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>> @@ -0,0 +1,29 @@
>>>>> +GPIO-INVERTER
>>>>> +======
>>>>> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
>>>>> +allows to properly describe the gpio polarities on the hardware.
>>>> I don't understand. Please explain this in terms of the hardware, not a driver.
>>> gpio inverters can be used on different hardware to alter the polarity of gpio chips.
>>> The polarity of pins can change from hardware to hardware with the use of inverters.
>> Yes, I know what an inverter is.
>>
>>> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
>> We already define the active state of GPIOs in the consumers. If
>> there's an inverter in the middle, the consumer active state is simply
>> inverted. I don't agree that that is a hack as Linus said without some
>> reasoning why an inverter needs to be modeled in DT. Anything about
>> what 'userspace' needs is not a reason. That's a Linux thing that has
>> little to do with hardware description.
>
> Yes we are talking about the hardware level inversions here. The usecase is for those without the gpio consumer driver. The usecase started with the concept of allowing an abstraction of the underlying hardware for the userland controlling program such that this program does not care whether the GPIO lines are inverted or not physically. In other words, a single userland controlling program can work unmodified across a variety of hardware platforms with the device tree mapping the logical to physical relationship of the GPIO hardware.
> I totally understand anything about what 'userspace' needs is not a reason, but this is not restricted to userspace alone as kernel drivers may need this just as much. Also we are just modelling/describing the hardware state in the device tree.
>
> Just to mention that Linus Walleij had proposed this inverter model to describe the hardware and the gpio inverter driver is developed based on comments/review from him.
>
> Also my sincere request to Linus Walleij to please let his opinion know on this.
>
> Thanks,
>
> Best Regards,
> Harish Jenny K N


Can you please give your opinion on this.


Thanks.


Best Regards,

Harish Jenny K N

>

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Linus,

On 17/07/19 7:21 PM, Harish Jenny K N wrote:
> Hi Linus,
>
> On 10/07/19 1:58 PM, Harish Jenny K N wrote:
>> Hi,
>>
>> On 09/07/19 9:38 PM, Rob Herring wrote:
>>> On Mon, Jul 8, 2019 at 11:25 PM Harish Jenny K N
>>> <harish_kandiga@mentor.com> wrote:
>>>> Hi Rob,
>>>>
>>>>
>>>> On 09/07/19 4:06 AM, Rob Herring wrote:
>>>>> On Fri, Jun 28, 2019 at 3:31 AM Harish Jenny K N
>>>>> <harish_kandiga@mentor.com> wrote:
>>>>>> Document the device tree binding for the inverter gpio
>>>>>> controller to configure the polarity of the gpio pins
>>>>>> used by the consumers.
>>>>>>
>>>>>> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
>>>>>> ---
>>>>>>  .../devicetree/bindings/gpio/gpio-inverter.txt     | 29 ++++++++++++++++++++++
>>>>>>  1 file changed, 29 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-inverter.txt b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..8bb6b2e
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-inverter.txt
>>>>>> @@ -0,0 +1,29 @@
>>>>>> +GPIO-INVERTER
>>>>>> +======
>>>>>> +This binding defines the gpio-inverter. The gpio-inverter is a driver that
>>>>>> +allows to properly describe the gpio polarities on the hardware.
>>>>> I don't understand. Please explain this in terms of the hardware, not a driver.
>>>> gpio inverters can be used on different hardware to alter the polarity of gpio chips.
>>>> The polarity of pins can change from hardware to hardware with the use of inverters.
>>> Yes, I know what an inverter is.
>>>
>>>> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
>>> We already define the active state of GPIOs in the consumers. If
>>> there's an inverter in the middle, the consumer active state is simply
>>> inverted. I don't agree that that is a hack as Linus said without some
>>> reasoning why an inverter needs to be modeled in DT. Anything about
>>> what 'userspace' needs is not a reason. That's a Linux thing that has
>>> little to do with hardware description.
>> Yes we are talking about the hardware level inversions here. The usecase is for those without the gpio consumer driver. The usecase started with the concept of allowing an abstraction of the underlying hardware for the userland controlling program such that this program does not care whether the GPIO lines are inverted or not physically. In other words, a single userland controlling program can work unmodified across a variety of hardware platforms with the device tree mapping the logical to physical relationship of the GPIO hardware.
>> I totally understand anything about what 'userspace' needs is not a reason, but this is not restricted to userspace alone as kernel drivers may need this just as much. Also we are just modelling/describing the hardware state in the device tree.
>>
>> Just to mention that Linus Walleij had proposed this inverter model to describe the hardware and the gpio inverter driver is developed based on comments/review from him.
>>
>> Also my sincere request to Linus Walleij to please let his opinion know on this.
>>
>> Thanks,
>>
>> Best Regards,
>> Harish Jenny K N
>
> Can you please give your opinion on this.
>
>
> Thanks.
>
>
> Best Regards,
>
> Harish Jenny K N
>

sorry for the repeated mail. can you please give your opinion on this ?

Thanks.

Harish

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Linus Walleij]

On Wed, Jul 10, 2019 at 10:28 AM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
> On 09/07/19 9:38 PM, Rob Herring wrote:

> >> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
> >
> > We already define the active state of GPIOs in the consumers. If
> > there's an inverter in the middle, the consumer active state is simply
> > inverted. I don't agree that that is a hack as Linus said without some
> > reasoning why an inverter needs to be modeled in DT. Anything about
> > what 'userspace' needs is not a reason. That's a Linux thing that has
> > little to do with hardware description.

There is some level of ambition here which is inherently a bit fuzzy
around the edges. ("How long is the coast of Britain?" comes to mind.)

Surely the intention of device tree is not to recreate the schematic
in all detail. What we want is a model of the hardware that will
suffice for the operating system usecases.

But sometimes the DTS files will become confusing: why is this
component using GPIO_ACTIVE_LOW when another system
doesn't have that flag? If there is an explicit inverter, the
DTS gets more readable for a human.

But arguable that is case for adding inverters as syntactic
sugar in the DTS compiler instead...

> Yes we are talking about the hardware level inversions here.
> The usecase is for those without the gpio consumer driver.
> The usecase started with the concept of allowing an abstraction
> of the underlying hardware for the userland controlling program
> such that this program does not care whether the GPIO lines
> are inverted or not physically. In other words, a single userland
> controlling program can work unmodified across a variety of
> hardware platforms with the device tree mapping the logical
> to physical relationship of the GPIO hardware.
> I totally understand anything about what 'userspace' needs is
> not a reason, but this is not restricted to userspace alone as
> kernel drivers may need this just as much. Also we are
> just modelling/describing the hardware state in the device tree.

The kernel also has a need to model inverters and it has come
up from time to time, but I don't remember these instances
right off the top of my head.

I am not sure userspace needs are of zero concerns either.

Sure, for anything reimplementing what I have listed in
Documentation/driver-api/gpio/drivers-on-gpio.rst
it is just abuse of the ABI, but things like industrial control
systems and other one-offs have this need to run the
same binary unmodified for measuring the trigger level
of water in some tank or so, they can't create kernel
drivers for that kind of stuff.

Yours,
Linus Walleij

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Rob Herring]

On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Jul 10, 2019 at 10:28 AM Harish Jenny K N
> <harish_kandiga@mentor.com> wrote:
> > On 09/07/19 9:38 PM, Rob Herring wrote:
>
> > >> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
> > >
> > > We already define the active state of GPIOs in the consumers. If
> > > there's an inverter in the middle, the consumer active state is simply
> > > inverted. I don't agree that that is a hack as Linus said without some
> > > reasoning why an inverter needs to be modeled in DT. Anything about
> > > what 'userspace' needs is not a reason. That's a Linux thing that has
> > > little to do with hardware description.
>
> There is some level of ambition here which is inherently a bit fuzzy
> around the edges. ("How long is the coast of Britain?" comes to mind.)
>
> Surely the intention of device tree is not to recreate the schematic
> in all detail. What we want is a model of the hardware that will
> suffice for the operating system usecases.
>
> But sometimes the DTS files will become confusing: why is this
> component using GPIO_ACTIVE_LOW when another system
> doesn't have that flag? If there is an explicit inverter, the
> DTS gets more readable for a human.
>
> But arguable that is case for adding inverters as syntactic
> sugar in the DTS compiler instead...

If you really want something more explicit, then add a new GPIO
'inverted' flag. Then a device can always have the same HIGH/LOW flag.
That also solves the abstract it for userspace problem.

> > Yes we are talking about the hardware level inversions here.
> > The usecase is for those without the gpio consumer driver.
> > The usecase started with the concept of allowing an abstraction
> > of the underlying hardware for the userland controlling program
> > such that this program does not care whether the GPIO lines
> > are inverted or not physically. In other words, a single userland
> > controlling program can work unmodified across a variety of
> > hardware platforms with the device tree mapping the logical
> > to physical relationship of the GPIO hardware.
> > I totally understand anything about what 'userspace' needs is
> > not a reason, but this is not restricted to userspace alone as
> > kernel drivers may need this just as much. Also we are
> > just modelling/describing the hardware state in the device tree.
>
> The kernel also has a need to model inverters and it has come
> up from time to time, but I don't remember these instances
> right off the top of my head.

The only thing I can think of is an inverter needing its power supply
turned on. Seems a bit silly to have such fine grained control, but
who knows.

> I am not sure userspace needs are of zero concerns either.

No, but kernel vs. userspace is all a black box from a DT perspective
and not a distinction that we can design bindings around.

> Sure, for anything reimplementing what I have listed in
> Documentation/driver-api/gpio/drivers-on-gpio.rst
> it is just abuse of the ABI, but things like industrial control
> systems and other one-offs have this need to run the
> same binary unmodified for measuring the trigger level
> of water in some tank or so, they can't create kernel
> drivers for that kind of stuff.

The userspace interface already passes the flags for the gpio lines,
why can't a userspace program honor them? You can't have it both ways:
low level GPIO access and abstracted to not care about the details.

Rob

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Linus Walleij]

On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:

> > There is some level of ambition here which is inherently a bit fuzzy
> > around the edges. ("How long is the coast of Britain?" comes to mind.)
> >
> > Surely the intention of device tree is not to recreate the schematic
> > in all detail. What we want is a model of the hardware that will
> > suffice for the operating system usecases.
> >
> > But sometimes the DTS files will become confusing: why is this
> > component using GPIO_ACTIVE_LOW when another system
> > doesn't have that flag? If there is an explicit inverter, the
> > DTS gets more readable for a human.
> >
> > But arguable that is case for adding inverters as syntactic
> > sugar in the DTS compiler instead...
>
> If you really want something more explicit, then add a new GPIO
> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
> That also solves the abstract it for userspace problem.

I think there are some intricate ontologies at work here.

Consider this example: a GPIO is controlling a chip select
regulator, say Acme Foo. The chip select
has a pin named CSN. We know from convention that the
"N" at the end of that pin name means "negative" i.e. active
low, and that is how the electronics engineers think about
that chip select line: it activates the IC when
the line goes low.

The regulator subsystem and I think all subsystems in the
Linux kernel say the consumer pin should be named and
tagged after the datsheet of the regulator.

So it has for example:

foo {
    compatible = "acme,foo";
    cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};

(It would be inappropriate to name it "csn-gpios" since
we have an established flag for active low. But it is another
of these syntactic choices where people likely do mistakes.)

I think it would be appropriate for the DT binding to say
that this flag must always be GPIO_ACTIVE_LOW since
the bindings are seen from the component point of view,
and thus this is always active low.

It would even be reasonable for a yaml schema to enfore
this, if it could. It is defined as active low after all.

Now if someone adds an inverter on that line between
gpio0 and Acme Foo it looks like this:

foo {
    compatible = "acme,foo";
    cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};

And now we get cognitive dissonance or whatever I should
call it: someone reading this DTS sheet and the data
sheet for the component Acme Foo to troubleshoot
this will be confused: this component has CS active
low and still it is specified as active high? Unless they
also look at the schematic or the board and find the
inverter things are pretty muddy and they will likely curse
and solve the situation with the usual trial-and-error,
inserting some random cursewords as a comment.

With an intermediate inverter node, the cs-gpios
can go back to GPIO_ACTIVE_LOW and follow
the bindings:

inv0: inverter {
    compatible = "gpio-inverter";
    gpio-controller;
    #gpio-cells = <1>;
    inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};

foo {
    compatible = "acme,foo";
    cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
};

And now Acme Foo bindings can keep enforcing cs-gpios
to always be tagged GPIO_ACTIVE_LOW.

Yours,
Linus Walleij

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Rob, Hi Linus,


On 30/08/19 10:51 AM, Harish Jenny K N wrote:
> Hi Rob,
>
>
> On 27/08/19 1:17 PM, Harish Jenny K N wrote:
>> Hi Rob,
>>
>>
>> On 19/08/19 3:06 PM, Harish Jenny K N wrote:
>>> Hi Rob,
>>>
>>>
>>> On 10/08/19 2:21 PM, Linus Walleij wrote:
>>>> On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
>>>>> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>>>>>> There is some level of ambition here which is inherently a bit fuzzy
>>>>>> around the edges. ("How long is the coast of Britain?" comes to mind.)
>>>>>>
>>>>>> Surely the intention of device tree is not to recreate the schematic
>>>>>> in all detail. What we want is a model of the hardware that will
>>>>>> suffice for the operating system usecases.
>>>>>>
>>>>>> But sometimes the DTS files will become confusing: why is this
>>>>>> component using GPIO_ACTIVE_LOW when another system
>>>>>> doesn't have that flag? If there is an explicit inverter, the
>>>>>> DTS gets more readable for a human.
>>>>>>
>>>>>> But arguable that is case for adding inverters as syntactic
>>>>>> sugar in the DTS compiler instead...
>>>>> If you really want something more explicit, then add a new GPIO
>>>>> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
>>>>> That also solves the abstract it for userspace problem.
>>>> I think there are some intricate ontologies at work here.
>>>>
>>>> Consider this example: a GPIO is controlling a chip select
>>>> regulator, say Acme Foo. The chip select
>>>> has a pin named CSN. We know from convention that the
>>>> "N" at the end of that pin name means "negative" i.e. active
>>>> low, and that is how the electronics engineers think about
>>>> that chip select line: it activates the IC when
>>>> the line goes low.
>>>>
>>>> The regulator subsystem and I think all subsystems in the
>>>> Linux kernel say the consumer pin should be named and
>>>> tagged after the datsheet of the regulator.
>>>>
>>>> So it has for example:
>>>>
>>>> foo {
>>>>     compatible = "acme,foo";
>>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
>>>> };
>>>>
>>>> (It would be inappropriate to name it "csn-gpios" since
>>>> we have an established flag for active low. But it is another
>>>> of these syntactic choices where people likely do mistakes.)
>>>>
>>>> I think it would be appropriate for the DT binding to say
>>>> that this flag must always be GPIO_ACTIVE_LOW since
>>>> the bindings are seen from the component point of view,
>>>> and thus this is always active low.
>>>>
>>>> It would even be reasonable for a yaml schema to enfore
>>>> this, if it could. It is defined as active low after all.
>>>>
>>>> Now if someone adds an inverter on that line between
>>>> gpio0 and Acme Foo it looks like this:
>>>>
>>>> foo {
>>>>     compatible = "acme,foo";
>>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>> };
>>>>
>>>> And now we get cognitive dissonance or whatever I should
>>>> call it: someone reading this DTS sheet and the data
>>>> sheet for the component Acme Foo to troubleshoot
>>>> this will be confused: this component has CS active
>>>> low and still it is specified as active high? Unless they
>>>> also look at the schematic or the board and find the
>>>> inverter things are pretty muddy and they will likely curse
>>>> and solve the situation with the usual trial-and-error,
>>>> inserting some random cursewords as a comment.
>>>>
>>>> With an intermediate inverter node, the cs-gpios
>>>> can go back to GPIO_ACTIVE_LOW and follow
>>>> the bindings:
>>>>
>>>> inv0: inverter {
>>>>     compatible = "gpio-inverter";
>>>>     gpio-controller;
>>>>     #gpio-cells = <1>;
>>>>     inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>> };
>>>>
>>>> foo {
>>>>     compatible = "acme,foo";
>>>>     cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
>>>> };
>>>>
>>>> And now Acme Foo bindings can keep enforcing cs-gpios
>>>> to always be tagged GPIO_ACTIVE_LOW.
>>> Can you please review/let us know your opinion on this ? I think the idea here is to also isolate the changes to a separate consumer driver and avoid getting inversions inside gpiolib.
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Regards,
>>>
>>> Harish Jenny K N
>>>
>> Can you please comment on this ?
>>
>>
>> Thanks,
>>
>> Harish Jenny K N
>>
> Friendly Reminder.
>
> can we please finalize this ?
>
> Linus has also mentioned in another patchset "[PATCH v2] Input: tsc2007 - use GPIO descriptor" that
>
> he is in favor of introducing explicit inverters in device tree.
>
>
> Please consider this and let us know your inputs.
>
>
>
> Thanks,
>
> Harish Jenny K N
>

Can we please finalize this ?


Sorry for the repeated emails.

Am I missing something here ? I am not getting replies.



Thanks,

Harish Jenny K N

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Rob Herring]

On Wed, Sep 4, 2019 at 5:58 AM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
>
> Hi Rob, Hi Linus,
>
>
> On 30/08/19 10:51 AM, Harish Jenny K N wrote:
> > Hi Rob,
> >
> >
> > On 27/08/19 1:17 PM, Harish Jenny K N wrote:
> >> Hi Rob,
> >>
> >>
> >> On 19/08/19 3:06 PM, Harish Jenny K N wrote:
> >>> Hi Rob,
> >>>
> >>>
> >>> On 10/08/19 2:21 PM, Linus Walleij wrote:
> >>>> On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> >>>>> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >>>>>> There is some level of ambition here which is inherently a bit fuzzy
> >>>>>> around the edges. ("How long is the coast of Britain?" comes to mind.)
> >>>>>>
> >>>>>> Surely the intention of device tree is not to recreate the schematic
> >>>>>> in all detail. What we want is a model of the hardware that will
> >>>>>> suffice for the operating system usecases.
> >>>>>>
> >>>>>> But sometimes the DTS files will become confusing: why is this
> >>>>>> component using GPIO_ACTIVE_LOW when another system
> >>>>>> doesn't have that flag? If there is an explicit inverter, the
> >>>>>> DTS gets more readable for a human.
> >>>>>>
> >>>>>> But arguable that is case for adding inverters as syntactic
> >>>>>> sugar in the DTS compiler instead...
> >>>>> If you really want something more explicit, then add a new GPIO
> >>>>> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
> >>>>> That also solves the abstract it for userspace problem.
> >>>> I think there are some intricate ontologies at work here.
> >>>>
> >>>> Consider this example: a GPIO is controlling a chip select
> >>>> regulator, say Acme Foo. The chip select
> >>>> has a pin named CSN. We know from convention that the
> >>>> "N" at the end of that pin name means "negative" i.e. active
> >>>> low, and that is how the electronics engineers think about
> >>>> that chip select line: it activates the IC when
> >>>> the line goes low.
> >>>>
> >>>> The regulator subsystem and I think all subsystems in the
> >>>> Linux kernel say the consumer pin should be named and
> >>>> tagged after the datsheet of the regulator.
> >>>>
> >>>> So it has for example:
> >>>>
> >>>> foo {
> >>>>     compatible = "acme,foo";
> >>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
> >>>> };
> >>>>
> >>>> (It would be inappropriate to name it "csn-gpios" since
> >>>> we have an established flag for active low. But it is another
> >>>> of these syntactic choices where people likely do mistakes.)
> >>>>
> >>>> I think it would be appropriate for the DT binding to say
> >>>> that this flag must always be GPIO_ACTIVE_LOW since
> >>>> the bindings are seen from the component point of view,
> >>>> and thus this is always active low.
> >>>>
> >>>> It would even be reasonable for a yaml schema to enfore
> >>>> this, if it could. It is defined as active low after all.
> >>>>
> >>>> Now if someone adds an inverter on that line between
> >>>> gpio0 and Acme Foo it looks like this:
> >>>>
> >>>> foo {
> >>>>     compatible = "acme,foo";
> >>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> >>>> };
> >>>>
> >>>> And now we get cognitive dissonance or whatever I should
> >>>> call it: someone reading this DTS sheet and the data
> >>>> sheet for the component Acme Foo to troubleshoot
> >>>> this will be confused: this component has CS active
> >>>> low and still it is specified as active high? Unless they
> >>>> also look at the schematic or the board and find the
> >>>> inverter things are pretty muddy and they will likely curse
> >>>> and solve the situation with the usual trial-and-error,
> >>>> inserting some random cursewords as a comment.
> >>>>
> >>>> With an intermediate inverter node, the cs-gpios
> >>>> can go back to GPIO_ACTIVE_LOW and follow
> >>>> the bindings:
> >>>>
> >>>> inv0: inverter {
> >>>>     compatible = "gpio-inverter";
> >>>>     gpio-controller;
> >>>>     #gpio-cells = <1>;
> >>>>     inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> >>>> };
> >>>>
> >>>> foo {
> >>>>     compatible = "acme,foo";
> >>>>     cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
> >>>> };
> >>>>
> >>>> And now Acme Foo bindings can keep enforcing cs-gpios
> >>>> to always be tagged GPIO_ACTIVE_LOW.
> >>> Can you please review/let us know your opinion on this ? I think the idea here is to also isolate the changes to a separate consumer driver and avoid getting inversions inside gpiolib.
> >>>
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Harish Jenny K N
> >>>
> >> Can you please comment on this ?
> >>
> >>
> >> Thanks,
> >>
> >> Harish Jenny K N
> >>
> > Friendly Reminder.
> >
> > can we please finalize this ?

I think I have made my position clear and don't really have more to
add. I'm simply not convinced of the need for this. An inverter is not
a GPIO controller. You can't set/get or do any control. It is already
possible to invert GPIO lines in DT by changing the flags and it has
been this way for decades.

Rob

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Linus,

On 10/09/19 1:17 PM, Rob Herring wrote:
> On Wed, Sep 4, 2019 at 5:58 AM Harish Jenny K N
> <harish_kandiga@mentor.com> wrote:
>> Hi Rob, Hi Linus,
>>
>>
>> On 30/08/19 10:51 AM, Harish Jenny K N wrote:
>>> Hi Rob,
>>>
>>>
>>> On 27/08/19 1:17 PM, Harish Jenny K N wrote:
>>>> Hi Rob,
>>>>
>>>>
>>>> On 19/08/19 3:06 PM, Harish Jenny K N wrote:
>>>>> Hi Rob,
>>>>>
>>>>>
>>>>> On 10/08/19 2:21 PM, Linus Walleij wrote:
>>>>>> On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
>>>>>>> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>>>>>>>> There is some level of ambition here which is inherently a bit fuzzy
>>>>>>>> around the edges. ("How long is the coast of Britain?" comes to mind.)
>>>>>>>>
>>>>>>>> Surely the intention of device tree is not to recreate the schematic
>>>>>>>> in all detail. What we want is a model of the hardware that will
>>>>>>>> suffice for the operating system usecases.
>>>>>>>>
>>>>>>>> But sometimes the DTS files will become confusing: why is this
>>>>>>>> component using GPIO_ACTIVE_LOW when another system
>>>>>>>> doesn't have that flag? If there is an explicit inverter, the
>>>>>>>> DTS gets more readable for a human.
>>>>>>>>
>>>>>>>> But arguable that is case for adding inverters as syntactic
>>>>>>>> sugar in the DTS compiler instead...
>>>>>>> If you really want something more explicit, then add a new GPIO
>>>>>>> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
>>>>>>> That also solves the abstract it for userspace problem.
>>>>>> I think there are some intricate ontologies at work here.
>>>>>>
>>>>>> Consider this example: a GPIO is controlling a chip select
>>>>>> regulator, say Acme Foo. The chip select
>>>>>> has a pin named CSN. We know from convention that the
>>>>>> "N" at the end of that pin name means "negative" i.e. active
>>>>>> low, and that is how the electronics engineers think about
>>>>>> that chip select line: it activates the IC when
>>>>>> the line goes low.
>>>>>>
>>>>>> The regulator subsystem and I think all subsystems in the
>>>>>> Linux kernel say the consumer pin should be named and
>>>>>> tagged after the datsheet of the regulator.
>>>>>>
>>>>>> So it has for example:
>>>>>>
>>>>>> foo {
>>>>>>     compatible = "acme,foo";
>>>>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
>>>>>> };
>>>>>>
>>>>>> (It would be inappropriate to name it "csn-gpios" since
>>>>>> we have an established flag for active low. But it is another
>>>>>> of these syntactic choices where people likely do mistakes.)
>>>>>>
>>>>>> I think it would be appropriate for the DT binding to say
>>>>>> that this flag must always be GPIO_ACTIVE_LOW since
>>>>>> the bindings are seen from the component point of view,
>>>>>> and thus this is always active low.
>>>>>>
>>>>>> It would even be reasonable for a yaml schema to enfore
>>>>>> this, if it could. It is defined as active low after all.
>>>>>>
>>>>>> Now if someone adds an inverter on that line between
>>>>>> gpio0 and Acme Foo it looks like this:
>>>>>>
>>>>>> foo {
>>>>>>     compatible = "acme,foo";
>>>>>>     cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>>>> };
>>>>>>
>>>>>> And now we get cognitive dissonance or whatever I should
>>>>>> call it: someone reading this DTS sheet and the data
>>>>>> sheet for the component Acme Foo to troubleshoot
>>>>>> this will be confused: this component has CS active
>>>>>> low and still it is specified as active high? Unless they
>>>>>> also look at the schematic or the board and find the
>>>>>> inverter things are pretty muddy and they will likely curse
>>>>>> and solve the situation with the usual trial-and-error,
>>>>>> inserting some random cursewords as a comment.
>>>>>>
>>>>>> With an intermediate inverter node, the cs-gpios
>>>>>> can go back to GPIO_ACTIVE_LOW and follow
>>>>>> the bindings:
>>>>>>
>>>>>> inv0: inverter {
>>>>>>     compatible = "gpio-inverter";
>>>>>>     gpio-controller;
>>>>>>     #gpio-cells = <1>;
>>>>>>     inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>>>> };
>>>>>>
>>>>>> foo {
>>>>>>     compatible = "acme,foo";
>>>>>>     cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
>>>>>> };
>>>>>>
>>>>>> And now Acme Foo bindings can keep enforcing cs-gpios
>>>>>> to always be tagged GPIO_ACTIVE_LOW.
>>>>> Can you please review/let us know your opinion on this ? I think the idea here is to also isolate the changes to a separate consumer driver and avoid getting inversions inside gpiolib.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Harish Jenny K N
>>>>>
>>>> Can you please comment on this ?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Harish Jenny K N
>>>>
>>> Friendly Reminder.
>>>
>>> can we please finalize this ?
> I think I have made my position clear and don't really have more to
> add. I'm simply not convinced of the need for this. An inverter is not
> a GPIO controller. You can't set/get or do any control. It is already
> possible to invert GPIO lines in DT by changing the flags and it has
> been this way for decades.
>
> Rob


If Rob is fine with adding "inverted" flag in the device tree, can we just go back the initial approach of

defining the polarity on the producer side?

With this we would need something like this in the device tree for any gpiochip controller.

inverted = /bits/ 8 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0>;


RFC patch sent earlier can be found here. https://www.spinics.net/lists/linux-gpio/msg38815.html ( Note: various terms would need change)

I can send another patchset if you agree.


Please let us know your suggestion.


Thanks,

Harish Jenny K N

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Harish Jenny K N]

Hi Geert,


On 11/10/19 10:05 AM, Harish Jenny K N wrote:
> Hi Geert,
>
>
> On 07/10/19 1:48 PM, Geert Uytterhoeven wrote:
>> Hi Eugeniu,
>>
>> On Sat, Oct 5, 2019 at 3:08 PM Eugeniu Rosca <roscaeugeniu@gmail.com> wrote:
>>> On Fri, Sep 27, 2019 at 11:07:20AM +0200, Geert Uytterhoeven wrote:
>>>> My standard reply would be: describe the device connected to the GPIO(s)
>>>> in DT.  The GPIO line polarities are specified in the device's "gpios"
>>>> properties.
>>>> Next step would be to use the device from Linux.  For that to work, you
>>>> need a dedicated driver (for the complex case), or something generic
>>>> (for the simple case).
>>>> The latter is not unlike e.g. spidev.  Once you have a generic driver,
>>>> you can use "driver_override" in sysfs to bind the generic driver to
>>>> your device.  See e.g. commit 5039563e7c25eccd ("spi: Add
>>>> driver_override SPI device attribute").
>>> We have passed your suggestions along. Many thanks.
>>>
>>>> Currently we don't have a "generic" driver for GPIOs. We do have the
>>>> GPIO chardev interface, which exports a full gpio_chip.
>>>> It indeed looks like this "gpio-inverter" could be used as a generic
>>>> driver.  But it is limited to GPIOs that are inverted, which rules out
>>>> some use cases.
>>>>
>>>> So what about making it more generic, and dropping the "inverter" from
>>>> its name, and the "inverted" from the "inverted-gpios" property? After
>>>> all the inversion can be specified by the polarity of the GPIO cells in
>>>> the "gpios" property, and the GPIO core will take care of it[*]?
>>>> Which boils down to adding a simple DT interface to my gpio-aggregator
>>>> ("[PATCH/RFC v2 0/5] gpio: Add GPIO Aggregator Driver",
>>>>  https://lore.kernel.org/lkml/20190911143858.13024-1-geert+renesas@glider.be/).
>>>> And now I have realized[*], we probably no longer need the GPIO
>>>> Forwarder Helper, as there is no need to add inversion on top.
>>> After having a look at the gpio aggregator (and giving it a try on
>>> R-Car3 H3ULCB), here is how I interpret the above comment:
>>>
>>> If there is still a compelling reason for having gpio-inverter, then it
>>> probably makes sense to strip it from its "inverter" function (hence,
>>> transforming it into some kind of "repeater") on the basis that the
>>> inverting function is more of a collateral/secondary feature, rather
>>> than its primary one. Just like in the case of gpio aggregator, the
>>> primary function of gpio inverter is to accept a bunch of GPIO lines and
>>> to expose those via a dedicated gpiochip. I hope this is a proper
>>> summary of the first point in your comment. In any case, this is the
>>> understanding I get based on my experiments with both drivers.
>> Yes, the inverter is basically a "repeater" (or "aggregator", when it has
>> multiple GPIOs connected), hardcoded to invert.
>>
>>> What I also infer is that, assuming gpio-inverter will stay (potentially
>>> renamed and stripped of its non-essential inverting function), the gpio
>>> aggregator will need to keep its Forwarder Helper (supposed to act as a
>>> common foundation for both drivers).
>> What I meant is that if the inverter and aggregator would be combinoed
>> into a single driver, there would no longer be a need[*] for a separate
>> helper, and it could be incorporated into the single driver.
>>
>> [*] The individual helper functions may still be useful for some other
>>      driver, though.
>
> Agree.
>
>
>>> The second point which I extract from your comment is that the "gpio
>>> aggregator" could alternatively acquire the role of "gpio-inverter"
>>> (hence superseding it) by adding a "simple DT interface". I actually
>>> tend to like this proposal, since (as said above) both drivers are
>>> essentially doing the same thing, i.e. they cluster a number of gpio
>>> lines and expose this cluster as a new gpiochip (keeping the
>>> reserved/used gpio lines on hold). That looks like a huge overlap in
>>> the functionalities of the two drivers.
>> Yes, both drivers are very similar.  The difference lies in how they
>> acquire the list of GPIO descriptors.
> Yes. In fact my V2 version of the patch tried to implement the same role as repeater/forwarder albeit with a different naming/intention.
>
> Linus Walleij mentioned that using GPIO_ACTIVE_LOW just to get free inversion inside GPIOLIB was not OK really and this is a hardware description problem and totally different from the implementation problem inside the driver.
>
> Hence we changed the logic to inverter consumer driver doing inversion inside get and set functions.
>
>>> The only difference which I see is that "gpio-inverter" is getting its
>>> input from DT and generates the gpiochips at probe time, while
>>> "gpio aggregator" is getting its input from sysfs and generates the
>>> gpiochips at runtime, post-probe.
>> Exactly.
>>
>> For my virtualization use case, I need to create the list of GPIO
>> descriptors at run-time, hence the sysfs interface. This is
>> polarity-agnostic (i.e. the end user needs to care about polarity).
>>
>> For Harish use case, he needs to describe the list from DT, with
>> polarity inverted, which can be done by specifying the GPIO_ACTIVE_LOW
>> flag in the node's"gpios" property.
>>
>> For your use case, you want to describe the list in DT, with line-names,
>> and polarity specified.
>>
>>> So, assuming no objections from Harish and other reviewers, I would be
>>> very happy to review and test the DT-based gpio inversion functionality
>>> as part of gpio aggregator. Thanks!
>
> I tested your aggregator driver with the below minor changes in gpio-aggregator (combined with some minor changes in GPIO forwarder) to get devicetree support.
>
>
> 195,196d194
> <     int index = 0;
> <     int count;
> 278,295d275
> <     count = gpiod_count(dev, NULL);
> <     if (count > 0) {
> <         while (index < count) {
> <             desc = devm_gpiod_get_index(dev, NULL, index, GPIOD_ASIS);
> <
> <             if (desc == ERR_PTR(-ENOENT))
> <                 return -EPROBE_DEFER;
> <
> <             if (IS_ERR(desc))
> <                 return PTR_ERR(desc);
> <
> <             error = add_gpio(dev, &descs, &n, desc);
> <             if (error)
> <                 return error;
> <             index++;
> <         }
> <     }
> <
> 316,319d295
> < static const struct of_device_id gpio_aggregator_match[] = {
> <     { .compatible =    "gpio-aggregator", }, { },
> < };
> <
> 326d301
> <         .of_match_table = of_match_ptr(gpio_aggregator_match),
>
>
> This does work and achieve our aim of inverter driver.
>
> Hence no objection from my side to merge the drivers. Please let me know if I need to send you a patch on top of your aggregator patch.
>
> Hoping to get some credits for my work of 5 months effort ! ;)
>
>
> Best Regards,
>
> Harish Jenny K N


Is any attempt being made for the newer version of the aggregator/inverter driver ?


Best Regards,

Harish Jenny K N

>

Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings

[Geert Uytterhoeven]

Hi Harish,

On Tue, Nov 12, 2019 at 12:52 PM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
> On 11/10/19 10:05 AM, Harish Jenny K N wrote:
> > On 07/10/19 1:48 PM, Geert Uytterhoeven wrote:
> >> On Sat, Oct 5, 2019 at 3:08 PM Eugeniu Rosca <roscaeugeniu@gmail.com> wrote:
> >>> On Fri, Sep 27, 2019 at 11:07:20AM +0200, Geert Uytterhoeven wrote:
> >>>> My standard reply would be: describe the device connected to the GPIO(s)
> >>>> in DT.  The GPIO line polarities are specified in the device's "gpios"
> >>>> properties.
> >>>> Next step would be to use the device from Linux.  For that to work, you
> >>>> need a dedicated driver (for the complex case), or something generic
> >>>> (for the simple case).
> >>>> The latter is not unlike e.g. spidev.  Once you have a generic driver,
> >>>> you can use "driver_override" in sysfs to bind the generic driver to
> >>>> your device.  See e.g. commit 5039563e7c25eccd ("spi: Add
> >>>> driver_override SPI device attribute").
> >>> We have passed your suggestions along. Many thanks.
> >>>
> >>>> Currently we don't have a "generic" driver for GPIOs. We do have the
> >>>> GPIO chardev interface, which exports a full gpio_chip.
> >>>> It indeed looks like this "gpio-inverter" could be used as a generic
> >>>> driver.  But it is limited to GPIOs that are inverted, which rules out
> >>>> some use cases.
> >>>>
> >>>> So what about making it more generic, and dropping the "inverter" from
> >>>> its name, and the "inverted" from the "inverted-gpios" property? After
> >>>> all the inversion can be specified by the polarity of the GPIO cells in
> >>>> the "gpios" property, and the GPIO core will take care of it[*]?
> >>>> Which boils down to adding a simple DT interface to my gpio-aggregator
> >>>> ("[PATCH/RFC v2 0/5] gpio: Add GPIO Aggregator Driver",
> >>>>  https://lore.kernel.org/lkml/20190911143858.13024-1-geert+renesas@glider.be/).
> >>>> And now I have realized[*], we probably no longer need the GPIO
> >>>> Forwarder Helper, as there is no need to add inversion on top.
> >>> After having a look at the gpio aggregator (and giving it a try on
> >>> R-Car3 H3ULCB), here is how I interpret the above comment:
> >>>
> >>> If there is still a compelling reason for having gpio-inverter, then it
> >>> probably makes sense to strip it from its "inverter" function (hence,
> >>> transforming it into some kind of "repeater") on the basis that the
> >>> inverting function is more of a collateral/secondary feature, rather
> >>> than its primary one. Just like in the case of gpio aggregator, the
> >>> primary function of gpio inverter is to accept a bunch of GPIO lines and
> >>> to expose those via a dedicated gpiochip. I hope this is a proper
> >>> summary of the first point in your comment. In any case, this is the
> >>> understanding I get based on my experiments with both drivers.
> >> Yes, the inverter is basically a "repeater" (or "aggregator", when it has
> >> multiple GPIOs connected), hardcoded to invert.
> >>
> >>> What I also infer is that, assuming gpio-inverter will stay (potentially
> >>> renamed and stripped of its non-essential inverting function), the gpio
> >>> aggregator will need to keep its Forwarder Helper (supposed to act as a
> >>> common foundation for both drivers).
> >> What I meant is that if the inverter and aggregator would be combinoed
> >> into a single driver, there would no longer be a need[*] for a separate
> >> helper, and it could be incorporated into the single driver.
> >>
> >> [*] The individual helper functions may still be useful for some other
> >>      driver, though.
> >
> > Agree.
> >
> >
> >>> The second point which I extract from your comment is that the "gpio
> >>> aggregator" could alternatively acquire the role of "gpio-inverter"
> >>> (hence superseding it) by adding a "simple DT interface". I actually
> >>> tend to like this proposal, since (as said above) both drivers are
> >>> essentially doing the same thing, i.e. they cluster a number of gpio
> >>> lines and expose this cluster as a new gpiochip (keeping the
> >>> reserved/used gpio lines on hold). That looks like a huge overlap in
> >>> the functionalities of the two drivers.
> >> Yes, both drivers are very similar.  The difference lies in how they
> >> acquire the list of GPIO descriptors.
> > Yes. In fact my V2 version of the patch tried to implement the same role as repeater/forwarder albeit with a different naming/intention.
> >
> > Linus Walleij mentioned that using GPIO_ACTIVE_LOW just to get free inversion inside GPIOLIB was not OK really and this is a hardware description problem and totally different from the implementation problem inside the driver.
> >
> > Hence we changed the logic to inverter consumer driver doing inversion inside get and set functions.
> >
> >>> The only difference which I see is that "gpio-inverter" is getting its
> >>> input from DT and generates the gpiochips at probe time, while
> >>> "gpio aggregator" is getting its input from sysfs and generates the
> >>> gpiochips at runtime, post-probe.
> >> Exactly.
> >>
> >> For my virtualization use case, I need to create the list of GPIO
> >> descriptors at run-time, hence the sysfs interface. This is
> >> polarity-agnostic (i.e. the end user needs to care about polarity).
> >>
> >> For Harish use case, he needs to describe the list from DT, with
> >> polarity inverted, which can be done by specifying the GPIO_ACTIVE_LOW
> >> flag in the node's"gpios" property.
> >>
> >> For your use case, you want to describe the list in DT, with line-names,
> >> and polarity specified.
> >>
> >>> So, assuming no objections from Harish and other reviewers, I would be
> >>> very happy to review and test the DT-based gpio inversion functionality
> >>> as part of gpio aggregator. Thanks!
> >
> > I tested your aggregator driver with the below minor changes in gpio-aggregator (combined with some minor changes in GPIO forwarder) to get devicetree support.
> >
> >
> > 195,196d194
> > <     int index = 0;
> > <     int count;
> > 278,295d275
> > <     count = gpiod_count(dev, NULL);
> > <     if (count > 0) {
> > <         while (index < count) {
> > <             desc = devm_gpiod_get_index(dev, NULL, index, GPIOD_ASIS);
> > <
> > <             if (desc == ERR_PTR(-ENOENT))
> > <                 return -EPROBE_DEFER;
> > <
> > <             if (IS_ERR(desc))
> > <                 return PTR_ERR(desc);
> > <
> > <             error = add_gpio(dev, &descs, &n, desc);
> > <             if (error)
> > <                 return error;
> > <             index++;
> > <         }
> > <     }
> > <
> > 316,319d295
> > < static const struct of_device_id gpio_aggregator_match[] = {
> > <     { .compatible =    "gpio-aggregator", }, { },
> > < };
> > <
> > 326d301
> > <         .of_match_table = of_match_ptr(gpio_aggregator_match),
> >
> >
> > This does work and achieve our aim of inverter driver.
> >
> > Hence no objection from my side to merge the drivers. Please let me know if I need to send you a patch on top of your aggregator patch.
> >
> > Hoping to get some credits for my work of 5 months effort ! ;)
> >
> >
> > Best Regards,
> >
> > Harish Jenny K N
>
>
> Is any attempt being made for the newer version of the aggregator/inverter driver ?

It's on my list, and I hope to tackle it soon (later this week, or next week).
Thanks for your patience!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds