Documentation: firmware-guide: gpio-properties: Fix factual mistakes

PATCH Superseded Andy Shevchenko 5 participants 19 messages Oct 28, 2020 – Oct 29, 2020

Subsystems (3)

ACPI GPIO GPIO ACPI support

lore

Share & tools

lore

Andy Shevchenko

author maintainer

2020-10-28 21:54 UTC #0 lore raw

PATCH 1/3 Documentation: firmware-guide: gpio-properties: Fix factual mistakes

Fix factual mistakes and style issues in GPIO properties document.

Signed-off-by Andy Shevchenko <[email protected]>

---
 .../firmware-guide/acpi/gpio-properties.rst   | 29 ++++++++++---------
 1 file changed, 15 insertions(+), 14 deletions(-)

Documentation/firmware-guide/acpi/gpio-properties.rst +15 ~~-14~~

index bb6d74f23ee0..e6e65ceb2ca1 100644
@@ -20,9 +20,9 @@ index, like the ASL example below shows::
 
       Name (_CRS, ResourceTemplate ()
       {
-          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
+          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
                   "\\_SB.GPO0", 0, ResourceConsumer) {15}
-          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
+          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
                   "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
       })

@@ -49,7 +49,7 @@ index
 pin
   Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
 active_low
-  If 1 the GPIO is marked as active_low.
+  If 1, the GPIO is marked as active_low.
 
 Since ACPI GpioIo() resource does not have a field saying whether it is
 active low or high, the "active_low" argument can be used here.  Setting

@@ -112,8 +112,8 @@ Example::
   Package () {
       "gpio-line-names",
       Package () {
-          "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO",
-          "LVL_C_A1", "MUX0_IO", "SPI1_MISO"
+          "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD",
+          "MUX7_IO", "LVL_C_A1", "MUX0_IO", "SPI1_MISO",
       }
   }

@@ -137,7 +137,7 @@ to the GPIO lines it is going to use and provide the GPIO subsystem with a
 mapping between those names and the ACPI GPIO resources corresponding to them.
 
 To do that, the driver needs to define a mapping table as a NULL-terminated
-array of struct acpi_gpio_mapping objects that each contain a name, a pointer
+array of struct acpi_gpio_mapping objects that each contains a name, a pointer
 to an array of line data (struct acpi_gpio_params) objects and the size of that
 array.  Each struct acpi_gpio_params object consists of three fields,
 crs_entry_index, line_index, active_low, representing the index of the target

@@ -154,13 +154,14 @@ question would look like this::
   static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
     { "reset-gpios", &reset_gpio, 1 },
     { "shutdown-gpios", &shutdown_gpio, 1 },
-    { },
+    { }
   };
 
 Next, the mapping table needs to be passed as the second argument to
-acpi_dev_add_driver_gpios() that will register it with the ACPI device object
-pointed to by its first argument.  That should be done in the driver's .probe()
-routine.  On removal, the driver should unregister its GPIO mapping table by
+acpi_dev_add_driver_gpios() or its managed analogue that will
+register it with the ACPI device object pointed to by its first
+argument. That should be done in the driver's .probe() routine.
+On removal, the driver should unregister its GPIO mapping table by
 calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
 table was previously registered.

@@ -191,12 +192,12 @@ The driver might expect to get the right GPIO when it does::
 but since there is no way to know the mapping between "reset" and
 the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).
 
-The driver author can solve this by passing the mapping explictly
-(the recommended way and documented in the above chapter).
+The driver author can solve this by passing the mapping explicitly
+(this is the recommended way and it's documented in the above chapter).
 
 The ACPI GPIO mapping tables should not contaminate drivers that are not
 knowing about which exact device they are servicing on. It implies that
-the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain
+the ACPI GPIO mapping tables are hardly linked to an ACPI ID and certain
 objects, as listed in the above chapter, of the device in question.
 
 Getting GPIO descriptor

@@ -229,5 +230,5 @@ Case 2 explicitly tells GPIO core to look for resources in _CRS.
 Be aware that gpiod_get_index() in cases 1 and 2, assuming that there
 are two versions of ACPI device description provided and no mapping is
 present in the driver, will return different resources. That's why a
-certain driver has to handle them carefully as explained in previous
+certain driver has to handle them carefully as explained in the previous
 chapter.

Signature · 1 line

2.28.0

Andy Shevchenko

author maintainer

2020-10-28 21:54 UTC #1 lore raw

PATCH 2/3 Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

It appears that people may misinterpret active_low field in _DSD for GpioInt() resource. Add a paragraph to clarify this.

Reported-by Ricardo Ribalda <[email protected]>

Signed-off-by Andy Shevchenko <[email protected]>

---
 Documentation/firmware-guide/acpi/gpio-properties.rst | 3 +++
 1 file changed, 3 insertions(+)

Documentation/firmware-guide/acpi/gpio-properties.rst +3 -0

index e6e65ceb2ca1..370fe46c6af9 100644
@@ -55,6 +55,9 @@ Since ACPI GpioIo() resource does not have a field saying whether it is
 active low or high, the "active_low" argument can be used here.  Setting
 it to 1 marks the GPIO as active low.
 
+Note, active_low in _DSD does not make sense for GpioInt() resource and
+must be 0. GpioInt() resource has its own means of defining it.
+
 In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
 resource, second pin in that resource with the GPIO number of 31.

Signature · 1 line

2.28.0

Ricardo Ribalda

2020-10-28 21:37 UTC #2 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Hi Andy

Thanks for your patch and super fast response.

I think there are two different concepts here:

1) when the pin has a low value, it is 0 or a 1? =>active_low

2) when do I get an irq, low->high or high->low => irq polarity

When I read the acpi spec for GpioInt()
https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf page 934, it has the same problem as for GpioIo(), it does not express the active_low and this is where the _DSD field comes handy.

Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?

Thanks again

Quoted 27 lines · Andy Shevchenko

It appears that people may misinterpret active_low field in _DSD for GpioInt() resource. Add a paragraph to clarify this.

Reported-by Ricardo Ribalda <[email protected]>

Signed-off-by Andy Shevchenko <[email protected]>

---
 Documentation/firmware-guide/acpi/gpio-properties.rst | 3 +++
 1 file changed, 3 insertions(+)

Documentation/firmware-guide/acpi/gpio-properties.rst +3 -1

index e6e65ceb2ca1..370fe46c6af9 100644
@@ -55,6 +55,9 @@ Since ACPI GpioIo() resource does not have a field saying whether it is
 active low or high, the "active_low" argument can be used here.  Setting
 it to 1 marks the GPIO as active low.
 
+Note, active_low in _DSD does not make sense for GpioInt() resource and
+must be 0. GpioInt() resource has its own means of defining it.
+
 In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
 resource, second pin in that resource with the GPIO number of 31.
 
--

2.28.0

Signature · 1 line

Ricardo Ribalda

Andy Shevchenko

author maintainer

2020-10-29 14:45 UTC #3 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 7 lines · Ricardo Ribalda

Hi Andy
Thanks for your patch and super fast response.
I think there are two different concepts here:
1) when the pin has a low value, it is 0 or a 1? =>active_low

I'm not sure I have got it. GpioIo() has no such property and _DSD active_low is documented as being polarity setting:

	active_low == 1 => active low polarity.

Quoted 1 line

2) when do I get an irq, low->high or high->low => irq polarity

IRQ polarity is clearly defined by GpioInt() resource in the ACPI specification.

Quoted 4 lines

When I read the acpi spec for GpioInt()
https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf page 934, it has the same problem as for GpioIo(), it does not express the active_low and this is where the _DSD field comes handy.

ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).

Quoted 2 lines

Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?

This is nonsense.
What does it mean?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Ricardo Ribalda

2020-10-29 14:55 UTC #4 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Hi Andy

Quoted 25 lines · Andy Shevchenko

Quoted 7 lines · Ricardo Ribalda
Hi Andy
Thanks for your patch and super fast response.
I think there are two different concepts here:
1) when the pin has a low value, it is 0 or a 1? =>active_low
I'm not sure I have got it. GpioIo() has no such property and _DSD active_low is documented as being polarity setting:
        active_low == 1 => active low polarity.
Quoted 1 line
2) when do I get an irq, low->high or high->low => irq polarity
IRQ polarity is clearly defined by GpioInt() resource in the ACPI specification.
Quoted 4 lines
When I read the acpi spec for GpioInt()
https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf page 934, it has the same problem as for GpioIo(), it does not express the active_low and this is where the _DSD field comes handy.

Quoted 8 lines

ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?

Let me try to explain myself again:

I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both

The problem is that the value of that pin is inverted: Low means 1 and high means 0.

How can I describe that the pin "is inverted" without using the _DSD field?

Best regards

Quoted 6 lines

--
With Best Regards,
Andy Shevchenko

Signature · 1 line

Ricardo Ribalda

Andy Shevchenko

2020-10-29 17:18 UTC #5 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 3 lines · Ricardo Ribalda

Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:

...

Quoted 9 lines

Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?

Quoted 8 lines

Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?

"Both edges" and "inverted" or "polarity low" in one sentence make no sense.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

2020-10-29 17:20 UTC #6 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 18 lines · Andy Shevchenko

Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 11 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Let me try to explain myself again:

Quoted 8 lines

Quoted 6 lines
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.

To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

2020-10-29 17:26 UTC #7 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 26 lines · Andy Shevchenko

Quoted 23 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 16 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?

The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.

[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Ricardo Ribalda

2020-10-29 17:33 UTC #8 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Hi Andy

Quoted 33 lines · Andy Shevchenko

Quoted 30 lines · Andy Shevchenko
Quoted 26 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 9 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Quoted 8 lines
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.

Quoted 8 lines

Quoted 3 lines
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.

This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"

This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.

Quoted 8 lines

[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45
--
With Best Regards,
Andy Shevchenko

Signature · 1 line

Ricardo Ribalda

Ricardo Ribalda

2020-10-29 18:10 UTC #9 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

(clicked on reply instead of reply all sorry)

Quoted 48 lines · Ricardo Ribalda

Hi Andy
Quoted 33 lines · Andy Shevchenko
Quoted 30 lines · Andy Shevchenko
Quoted 26 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 9 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Quoted 8 lines
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
Quoted 8 lines
Quoted 3 lines
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.

Quoted 6 lines

This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"
This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.

And there are also other devices where the swith works the other way around, so the acpi should be verbose enough to describe both situations.

With my proposal (use the same active_low field as with GpioIO) we cover both usecases.

Quoted 15 lines

Quoted 10 lines
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45
--
With Best Regards,
Andy Shevchenko
--
Ricardo Ribalda

Signature · 1 line

Ricardo Ribalda

Andy Shevchenko

2020-10-29 18:13 UTC #10 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 50 lines · Ricardo Ribalda

Quoted 43 lines · Ricardo Ribalda
Quoted 31 lines · Andy Shevchenko
Quoted 29 lines · Andy Shevchenko
Quoted 26 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 9 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Quoted 8 lines
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
Quoted 8 lines
Quoted 3 lines
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.
Quoted 6 lines
This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"
This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.

Quoted 6 lines

And there are also other devices where the swith works the other way around, so the acpi should be verbose enough to describe both situations.
With my proposal (use the same active_low field as with GpioIO) we cover both usecases.

Even without your proposal it's feasible.
You see, the problem here is that if you describe GPIO as Interrupt, the edge and level together make complete nonsense.

Solution: do *not* describe it as Interrupt.

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Ricardo Ribalda

2020-10-29 18:58 UTC #11 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 56 lines · Andy Shevchenko

Quoted 54 lines · Ricardo Ribalda
Quoted 43 lines · Ricardo Ribalda
Quoted 31 lines · Andy Shevchenko
Quoted 29 lines · Andy Shevchenko
Quoted 26 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 9 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Quoted 8 lines
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
Quoted 8 lines
Quoted 3 lines
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.
Quoted 6 lines
This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"
This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.
And there are also other devices where the swith works the other way around, so the acpi should be verbose enough to describe both situations.

Quoted 8 lines

Quoted 2 lines
With my proposal (use the same active_low field as with GpioIO) we cover both usecases.
Even without your proposal it's feasible.
You see, the problem here is that if you describe GPIO as Interrupt, the edge and level together make complete nonsense.
Solution: do *not* describe it as Interrupt.

Now I get my mistake:

I thought that gpiod_to_irq will not work unless it was a GpioInt() but it works fine. So in this case I will just convert it to that.

Could we say that doing gpiod_get_value() from a GpioInt() is always wrong? Can we modify the code to avoid it?

Sorry for the confusion and thanks for your help.

Quoted 8 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45
--
With Best Regards,
Andy Shevchenko

--
Ricardo Ribalda

Andy Shevchenko

2020-10-29 19:10 UTC #12 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

Quoted 10 lines · Ricardo Ribalda

Quoted 8 lines · Andy Shevchenko
Quoted 7 lines · Ricardo Ribalda
Quoted 6 lines · Ricardo Ribalda
Quoted 4 lines · Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
On Thu, Oct 29, 2020 at 7:17 PM Andy Shevchenko
<[email protected]> wrote:

...

Quoted 38 lines

Quoted 38 lines
Quoted 27 lines
Quoted 21 lines
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 8 lines
Let me try to explain myself again:
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
Quoted 8 lines
Quoted 3 lines
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.
Quoted 6 lines
This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"
This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.
Quoted 6 lines
And there are also other devices where the swith works the other way around, so the acpi should be verbose enough to describe both situations.
With my proposal (use the same active_low field as with GpioIO) we cover both usecases.
Even without your proposal it's feasible.
You see, the problem here is that if you describe GPIO as Interrupt, the edge and level together make complete nonsense.

Quoted 6 lines

Quoted 1 line
Solution: do *not* describe it as Interrupt.
Now I get my mistake:
I thought that gpiod_to_irq will not work unless it was a GpioInt() but it works fine. So in this case I will just convert it to that.

It's actually that gpio_to_irq() is solely for GPIOs which initially are not IRQs.

Quoted 2 lines

Could we say that doing gpiod_get_value() from a GpioInt() is always wrong?

But it's not wrong. Some cases simply make little or no sense, but in principal why not? Yes, it may be fragile or too much customized.

Quoted 1 line

Can we modify the code to avoid it?

GpioInt() is orthogonal to GPIO APIs in Linux kernel. It close to be impossible. Also see above.

Quoted 1 line

Sorry for the confusion and thanks for your help.

No problem, you're welcome, it's good that you started a discussion!

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Andy Shevchenko

2020-10-29 18:11 UTC #13 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

In reply to Ricardo Ribalda

Quoted 37 lines · Ricardo Ribalda

Quoted 35 lines · Andy Shevchenko
Quoted 32 lines · Andy Shevchenko
Quoted 18 lines · Andy Shevchenko
Quoted 3 lines · Ricardo Ribalda
Quoted 1 line · Andy Shevchenko
On Wed, Oct 28, 2020 at 10:10:42PM +0100, Ricardo Ribalda wrote:
...
Quoted 11 lines
Quoted 8 lines
ActiveLevel field is described in 19.6.55 GpioInt (GPIO Interrupt Connection Resource Descriptor Macro).
Quoted 2 lines
Without using the active_low, how can we describe a pin that is active low and has to trigger an irq on both edges?
This is nonsense.
What does it mean?
Let me try to explain myself again:
Quoted 8 lines
Quoted 6 lines
I have a gpio pin that produces IRQs on both edges. so ActiveLevel is Both
The problem is that the value of that pin is inverted: Low means 1 and high means 0.
How can I describe that the pin "is inverted" without using the _DSD field?
"Both edges" and "inverted" or "polarity low" in one sentence make no sense.
To be on the constructive side, I can *imagine* so badly designed hardware that uses level and edge at the same time, but before I go to conclusions, can you share relevant (pieces of) datasheet?

Quoted 8 lines

Quoted 4 lines
The [1] is a real example of how GPIO is being used to detect changing of current level of the signal.
Note, ACPI tables for that device have problems [2], but I guess you may get the idea.
This is exactly what I need to do. Get an IRQ whenever the value changes. But the pin is "inverted"

Yes. It's fine. The above is using GpioIo() resource where polarity is part of the _DSD (okay, the actual ACPI table doesn't have it, but you can do it).

Quoted 5 lines

This is the "schematic" : https://ibb.co/f8GMBbP . I want to pass to userspace a "1" when the switch is closed and "0" when it is open.
Quoted 2 lines
[1]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L138
[2]: https://elixir.bootlin.com/linux/latest/source/drivers/extcon/extcon-intel-int3496.c#L45

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Mika Westerberg

Reviewed-by on v1 2/3

2020-10-29 08:16 UTC #14 lore raw

Re: [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo()

In reply to Andy Shevchenko

Quoted 5 lines · Andy Shevchenko

It appears that people may misinterpret active_low field in _DSD for GpioInt() resource. Add a paragraph to clarify this.
Reported-by Ricardo Ribalda <[email protected]>
Signed-off-by Andy Shevchenko <[email protected]>

Reviewed-by Mika Westerberg <[email protected]>

Andy Shevchenko

author maintainer

2020-10-28 21:56 UTC #15 lore raw

PATCH 3/3 Documentation: firmware-guide: gpio-properties: Clarify initial output state

In reply to Andy Shevchenko

GpioIo() doesn't provide an explicit state for an output pin. Linux tries to be smart and uses a common sense based on other parameters. Document how it looks like in the code.

Signed-off-by Andy Shevchenko <[email protected]>

---
 .../firmware-guide/acpi/gpio-properties.rst   | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

Documentation/firmware-guide/acpi/gpio-properties.rst +23 -0

index 370fe46c6af9..59aad6138b6e 100644
@@ -61,6 +61,29 @@ must be 0. GpioInt() resource has its own means of defining it.
 In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
 resource, second pin in that resource with the GPIO number of 31.
 
+The GpioIo() resource unfortunately doesn't explicitly provide an initial
+state of the output pin which driver should use during its initialization.
+
+Linux tries to use common sense here and derives the state from the bias
+and polarity settings. The table below shows the expectations:
+
+=========  =============  ==============
+Pull Bias     Polarity     Requested...
+=========  =============  ==============
+Implicit     x            AS IS (assumed firmware configured for us)
+Explicit     x (no _DSD)  as Pull Bias (Up == High, Down == Low),
+                          assuming non-active (Polarity = !Pull Bias)
+Down         Low          as low, assuming active
+Down         High         as low, assuming non-active
+Up           Low          as high, assuming non-active
+Up           High         as high, assuming active
+=========  =============  ==============
+
+That said, for our above example the both GPIOs, since the bias setting
+is explicit and _DSD is present, will be treated as active with a high
+polarity and Linux will configure the pins in this state until a driver
+reprograms them differently.
+
 It is possible to leave holes in the array of GPIOs. This is useful in
 cases like with SPI host controllers where some chip selects may be
 implemented as GPIOs and some as native signals. For example a SPI host

Signature · 1 line

2.28.0

Mika Westerberg

Reviewed-by on v1 3/3

2020-10-29 08:17 UTC #16 lore raw

Re: [PATCH v1 3/3] Documentation: firmware-guide: gpio-properties: Clarify initial output state

Quoted 5 lines · Andy Shevchenko

GpioIo() doesn't provide an explicit state for an output pin. Linux tries to be smart and uses a common sense based on other parameters. Document how it looks like in the code.
Signed-off-by Andy Shevchenko <[email protected]>

Reviewed-by Mika Westerberg <[email protected]>

Mika Westerberg

2020-10-29 08:13 UTC #17 lore raw

In reply to Andy Shevchenko

Quoted 1 line · Andy Shevchenko

Fix factual mistakes and style issues in GPIO properties document.

Can you clarify here what factual mistakes this fixes :)

Quoted 2 lines

Signed-off-by Andy Shevchenko <[email protected]>

Andy Shevchenko

author maintainer

2020-10-29 11:09 UTC #18 lore raw

Quoted 4 lines · Mika Westerberg

Quoted 1 line · Andy Shevchenko
Fix factual mistakes and style issues in GPIO properties document.
Can you clarify here what factual mistakes this fixes :)

The IoRestriction has wrong direction in the examples. I'll do in v2.

Quoted 1 line

Quoted 1 line
Signed-off-by Andy Shevchenko <[email protected]>

Signature · 2 lines

With Best Regards,
Andy Shevchenko