From: Geert Uytterhoeven <geert@linux-m68k.org> To: Rob Herring <robh@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Jonathan Corbet <corbet@lwn.net>, Mark Rutland <mark.rutland@arm.com>, Harish Jenny K N <harish_kandiga@mentor.com>, Eugeniu Rosca <erosca@de.adit-jv.com>, Alexander Graf <graf@amazon.com>, Peter Maydell <peter.maydell@linaro.org>, Paolo Bonzini <pbonzini@redhat.com>, Phil Reid <preid@electromag.com.au>, Marc Zyngier <marc.zyngier@arm.com>, Christoffer Dall <christoffer.dall@arm.com>, Magnus Damm <magnus.damm@gmail.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, QEMU Developers <qemu-devel@nongnu.org> Subject: Re: [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings Date: Fri, 6 Dec 2019 10:17:43 +0100 [thread overview] Message-ID: <CAMuHMdXKPC7-XaezodwL1Dhvke6PUVSZEbvN-sm3Uh6T61qbhQ@mail.gmail.com> (raw) In-Reply-To: <20191205210653.GA29969@bogus> Hi Rob, On Thu, Dec 5, 2019 at 10:06 PM Rob Herring <robh@kernel.org> wrote: > On Wed, Nov 27, 2019 at 09:42:50AM +0100, Geert Uytterhoeven wrote: > > Add Device Tree bindings for a GPIO repeater, with optional translation > > of physical signal properties. This is useful for describing explicitly > > the presence of e.g. an inverter on a GPIO line, and was inspired by the > > non-YAML gpio-inverter bindings by Harish Jenny K N > > <harish_kandiga@mentor.com>[1]. > > > > Note that this is different from a GPIO Nexus Node[2], which cannot do > > physical signal property translation. > > It can't? Why not? The point of the passthru mask is to not do > translation of flags, but without it you are always doing translation of > cells. Thanks for pushing me deeper into nexuses! You're right, you can map from one type to another. However, you cannot handle the "double inversion" of an ACTIVE_LOW signal with a physical inverter added: nexus: led-nexus { #gpio-cells = <2>; gpio-map = <0 0 &gpio2 19 GPIO_ACTIVE_LOW>, // inverted <1 0 &gpio2 20 GPIO_ACTIVE_HIGH>, // noninverted <2 0 &gpio2 21 GPIO_ACTIVE_LOW>; // inverted gpio-map-mask = <3 0>; // default gpio-map-pass-thru = <0 0>; }; leds { compatible = "gpio-leds"; led6-inverted { gpios = <&nexus 0 GPIO_ACTIVE_HIGH>; }; led7-noninverted { gpios = <&nexus 1 GPIO_ACTIVE_HIGH>; }; led8-double-inverted { // FAILS: still inverted gpios = <&nexus 2 GPIO_ACTIVE_LOW>; }; }; It "works" if the last entry in gpio-map is changed to GPIO_ACTIVE_HIGH. Still, the consumer would see the final translated polarity, and not the actual one it needs to program the consumer for. > > While an inverter can be described implicitly by exchanging the > > GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags, this has its limitations. > > Each GPIO line has only a single GPIO_ACTIVE_* flag, but applies to both > > th provider and consumer sides: > > 1. The GPIO provider (controller) looks at the flags to know the > > polarity, so it can translate between logical (active/not active) > > and physical (high/low) signal levels. > > 2. While the signal polarity is usually fixed on the GPIO consumer > > side (e.g. an LED is tied to either the supply voltage or GND), > > it may be configurable on some devices, and both sides need to > > agree. Hence the GPIO_ACTIVE_* flag as seen by the consumer must > > match the actual polarity. > > There exists a similar issue with interrupt flags, where both the > > interrupt controller and the device generating the interrupt need > > to agree, which breaks in the presence of a physical inverter not > > described in DT (see e.g. [3]). > > Adding an inverted flag as I've suggested would also solve this issue. As per your suggestion in "Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings"? https://lore.kernel.org/linux-devicetree/CAL_JsqLp___2O-naU+2PPQy0QmJX6+aN3hByz-OB9+qFvWgN9Q@mail.gmail.com/ Oh, now I understand. I was misguided by Harish' interpretation https://lore.kernel.org/linux-devicetree/dde73334-a26d-b53f-6b97-4101c1cdc185@mentor.com/ which assumed an "inverted" property, e.g. inverted = /bits/ 8 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0>; But you actually meant a new GPIO_INVERTED flag, to be ORed into the 2nd cell of a GPIO specifier? I.e. add to include/dt-bindings/gpio/gpio.h" /* Bit 6 expresses the presence of a physical inverter */ #define GPIO_INVERTED 64 We need to be very careful in defining to which side the GPIO_ACTIVE_* applies to (consumer?), and which side the GPIO_INVERTED flag (provider?). Still, this doesn't help if e.g. a FET is used instead of a push-pull inverter, as the former needs translation of other flags (which the nexus can do, the caveats above still applies, though). Same for adding IRQ_TYPE_INVERTED. Related issue: how to handle physical inverters on SPI chip select lines, if the SPI slave can be configured for both polarities? 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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org> To: Rob Herring <robh@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Peter Maydell <peter.maydell@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>, Phil Reid <preid@electromag.com.au>, Geert Uytterhoeven <geert+renesas@glider.be>, Jonathan Corbet <corbet@lwn.net>, Marc Zyngier <marc.zyngier@arm.com>, Linus Walleij <linus.walleij@linaro.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Magnus Damm <magnus.damm@gmail.com>, Christoffer Dall <christoffer.dall@arm.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Harish Jenny K N <harish_kandiga@mentor.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <graf@amazon.com>, Eugeniu Rosca <erosca@de.adit-jv.com> Subject: Re: [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings Date: Fri, 6 Dec 2019 10:17:43 +0100 [thread overview] Message-ID: <CAMuHMdXKPC7-XaezodwL1Dhvke6PUVSZEbvN-sm3Uh6T61qbhQ@mail.gmail.com> (raw) In-Reply-To: <20191205210653.GA29969@bogus> Hi Rob, On Thu, Dec 5, 2019 at 10:06 PM Rob Herring <robh@kernel.org> wrote: > On Wed, Nov 27, 2019 at 09:42:50AM +0100, Geert Uytterhoeven wrote: > > Add Device Tree bindings for a GPIO repeater, with optional translation > > of physical signal properties. This is useful for describing explicitly > > the presence of e.g. an inverter on a GPIO line, and was inspired by the > > non-YAML gpio-inverter bindings by Harish Jenny K N > > <harish_kandiga@mentor.com>[1]. > > > > Note that this is different from a GPIO Nexus Node[2], which cannot do > > physical signal property translation. > > It can't? Why not? The point of the passthru mask is to not do > translation of flags, but without it you are always doing translation of > cells. Thanks for pushing me deeper into nexuses! You're right, you can map from one type to another. However, you cannot handle the "double inversion" of an ACTIVE_LOW signal with a physical inverter added: nexus: led-nexus { #gpio-cells = <2>; gpio-map = <0 0 &gpio2 19 GPIO_ACTIVE_LOW>, // inverted <1 0 &gpio2 20 GPIO_ACTIVE_HIGH>, // noninverted <2 0 &gpio2 21 GPIO_ACTIVE_LOW>; // inverted gpio-map-mask = <3 0>; // default gpio-map-pass-thru = <0 0>; }; leds { compatible = "gpio-leds"; led6-inverted { gpios = <&nexus 0 GPIO_ACTIVE_HIGH>; }; led7-noninverted { gpios = <&nexus 1 GPIO_ACTIVE_HIGH>; }; led8-double-inverted { // FAILS: still inverted gpios = <&nexus 2 GPIO_ACTIVE_LOW>; }; }; It "works" if the last entry in gpio-map is changed to GPIO_ACTIVE_HIGH. Still, the consumer would see the final translated polarity, and not the actual one it needs to program the consumer for. > > While an inverter can be described implicitly by exchanging the > > GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags, this has its limitations. > > Each GPIO line has only a single GPIO_ACTIVE_* flag, but applies to both > > th provider and consumer sides: > > 1. The GPIO provider (controller) looks at the flags to know the > > polarity, so it can translate between logical (active/not active) > > and physical (high/low) signal levels. > > 2. While the signal polarity is usually fixed on the GPIO consumer > > side (e.g. an LED is tied to either the supply voltage or GND), > > it may be configurable on some devices, and both sides need to > > agree. Hence the GPIO_ACTIVE_* flag as seen by the consumer must > > match the actual polarity. > > There exists a similar issue with interrupt flags, where both the > > interrupt controller and the device generating the interrupt need > > to agree, which breaks in the presence of a physical inverter not > > described in DT (see e.g. [3]). > > Adding an inverted flag as I've suggested would also solve this issue. As per your suggestion in "Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings"? https://lore.kernel.org/linux-devicetree/CAL_JsqLp___2O-naU+2PPQy0QmJX6+aN3hByz-OB9+qFvWgN9Q@mail.gmail.com/ Oh, now I understand. I was misguided by Harish' interpretation https://lore.kernel.org/linux-devicetree/dde73334-a26d-b53f-6b97-4101c1cdc185@mentor.com/ which assumed an "inverted" property, e.g. inverted = /bits/ 8 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0>; But you actually meant a new GPIO_INVERTED flag, to be ORed into the 2nd cell of a GPIO specifier? I.e. add to include/dt-bindings/gpio/gpio.h" /* Bit 6 expresses the presence of a physical inverter */ #define GPIO_INVERTED 64 We need to be very careful in defining to which side the GPIO_ACTIVE_* applies to (consumer?), and which side the GPIO_INVERTED flag (provider?). Still, this doesn't help if e.g. a FET is used instead of a push-pull inverter, as the former needs translation of other flags (which the nexus can do, the caveats above still applies, though). Same for adding IRQ_TYPE_INVERTED. Related issue: how to handle physical inverters on SPI chip select lines, if the SPI slave can be configured for both polarities? 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
next prev parent reply other threads:[~2019-12-06 9:18 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-27 8:42 [PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-27 8:42 ` [PATCH v3 1/7] gpiolib: Add GPIOCHIP_NAME definition Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:38 ` Ulrich Hecht 2019-11-28 3:38 ` Ulrich Hecht 2019-12-02 21:17 ` Eugeniu Rosca 2019-12-02 21:17 ` Eugeniu Rosca 2019-12-12 10:37 ` Linus Walleij 2019-12-12 10:37 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 2/7] gpiolib: Add support for gpiochipN-based table lookup Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:38 ` Ulrich Hecht 2019-11-28 3:38 ` Ulrich Hecht 2019-12-12 13:20 ` Linus Walleij 2019-12-12 13:20 ` Linus Walleij 2019-12-12 13:33 ` Geert Uytterhoeven 2019-12-12 13:33 ` Geert Uytterhoeven 2019-12-12 14:36 ` Linus Walleij 2019-12-12 14:36 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 3/7] gpiolib: Add support for GPIO line " Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:39 ` Ulrich Hecht 2019-11-28 3:39 ` Ulrich Hecht 2019-12-12 13:40 ` Linus Walleij 2019-12-12 13:40 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 4/7] dt-bindings: gpio: Add gpio-repeater bindings Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:39 ` Ulrich Hecht 2019-11-28 3:39 ` Ulrich Hecht 2019-12-03 5:51 ` Harish Jenny K N 2019-12-03 5:51 ` Harish Jenny K N 2019-12-05 21:06 ` Rob Herring 2019-12-05 21:06 ` Rob Herring 2019-12-06 9:17 ` Geert Uytterhoeven [this message] 2019-12-06 9:17 ` Geert Uytterhoeven 2019-12-06 15:03 ` Rob Herring 2019-12-06 15:03 ` Rob Herring 2020-01-06 8:12 ` Geert Uytterhoeven 2020-01-06 8:12 ` Geert Uytterhoeven 2020-01-07 9:22 ` Harish Jenny K N 2020-01-07 9:22 ` Harish Jenny K N 2020-01-16 5:09 ` Harish Jenny K N 2020-01-16 5:09 ` Harish Jenny K N 2019-11-27 8:42 ` [PATCH v3 5/7] gpio: Add GPIO Aggregator/Repeater driver Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-27 14:15 ` Eugeniu Rosca 2019-11-27 14:15 ` Eugeniu Rosca 2019-11-27 14:33 ` Geert Uytterhoeven 2019-11-27 14:33 ` Geert Uytterhoeven 2019-11-28 3:40 ` Ulrich Hecht 2019-11-28 3:40 ` Ulrich Hecht 2019-12-03 5:42 ` Harish Jenny K N 2019-12-03 5:42 ` Harish Jenny K N 2019-12-03 8:17 ` Geert Uytterhoeven 2019-12-03 8:17 ` Geert Uytterhoeven 2019-12-03 8:51 ` Harish Jenny K N 2019-12-03 8:51 ` Harish Jenny K N 2019-12-03 10:51 ` Eugeniu Rosca 2019-12-03 10:51 ` Eugeniu Rosca 2020-01-09 13:35 ` Geert Uytterhoeven 2020-01-09 13:35 ` Geert Uytterhoeven 2020-01-09 13:49 ` Eugeniu Rosca 2020-01-09 13:49 ` Eugeniu Rosca 2019-12-12 14:34 ` Linus Walleij 2019-12-12 14:34 ` Linus Walleij 2019-12-12 15:24 ` Geert Uytterhoeven 2019-12-12 15:24 ` Geert Uytterhoeven 2020-01-04 0:38 ` Linus Walleij 2020-01-04 0:38 ` Linus Walleij 2020-01-06 8:23 ` Geert Uytterhoeven 2020-01-06 8:23 ` Geert Uytterhoeven 2020-01-08 23:12 ` Linus Walleij 2020-01-08 23:12 ` Linus Walleij 2019-11-27 8:42 ` [PATCH v3 6/7] docs: gpio: Add GPIO Aggregator/Repeater documentation Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-11-28 3:41 ` Ulrich Hecht 2019-11-28 3:41 ` Ulrich Hecht 2019-12-12 14:42 ` Linus Walleij 2019-12-12 14:42 ` Linus Walleij 2019-12-12 14:48 ` Geert Uytterhoeven 2019-12-12 14:48 ` Geert Uytterhoeven 2020-01-04 0:21 ` Linus Walleij 2020-01-04 0:21 ` Linus Walleij 2020-01-06 8:06 ` Geert Uytterhoeven 2020-01-06 8:06 ` Geert Uytterhoeven 2019-11-27 8:42 ` [PATCH v3 7/7] MAINTAINERS: Add GPIO Aggregator/Repeater section Geert Uytterhoeven 2019-11-27 8:42 ` Geert Uytterhoeven 2019-12-03 5:38 ` Harish Jenny K N 2019-12-03 5:38 ` Harish Jenny K N 2020-01-18 1:46 ` [PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater Eugeniu Rosca 2020-01-18 1:46 ` Eugeniu Rosca 2020-01-20 9:33 ` Geert Uytterhoeven 2020-01-20 9:33 ` Geert Uytterhoeven 2020-01-20 12:14 ` Eugeniu Rosca 2020-01-20 12:14 ` Eugeniu Rosca
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAMuHMdXKPC7-XaezodwL1Dhvke6PUVSZEbvN-sm3Uh6T61qbhQ@mail.gmail.com \ --to=geert@linux-m68k.org \ --cc=bgolaszewski@baylibre.com \ --cc=christoffer.dall@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=erosca@de.adit-jv.com \ --cc=geert+renesas@glider.be \ --cc=graf@amazon.com \ --cc=harish_kandiga@mentor.com \ --cc=linus.walleij@linaro.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=magnus.damm@gmail.com \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=preid@electromag.com.au \ --cc=qemu-devel@nongnu.org \ --cc=robh@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.