linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexander Shiyan <shc_work@mail.ru>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Tony Lindgren <tony@atomide.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Philipp Zabel <philipp.zabel@gmail.com>,
	Daniel Mack <zonque@gmail.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Russell King <rmk+kernel@armlinux.org.uk>
Subject: Re: [PATCH 01/19 v3] regulator: fixed: Convert to use GPIO descriptor only
Date: Mon, 11 Jun 2018 15:11:14 +0200	[thread overview]
Message-ID: <CACRpkdZEMPfxHc8dZOvyYN+S4o_zwKuYCTBbMiXMLsCZRz_f6A@mail.gmail.com> (raw)
In-Reply-To: <20180601093511.GA11734@ulmo>

On Fri, Jun 1, 2018 at 11:35 AM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, May 14, 2018 at 10:06:22AM +0200, Linus Walleij wrote:

>> As we augmented the regulator core to accept a GPIO descriptor instead
>> of a GPIO number, we can augment the fixed GPIO regulator to look up
>> and pass that descriptor directly from device tree or board GPIO
>> descriptor look up tables.
(...)
> This causes an HDMI display regression on Jetson TK1. From what I can
> tell, the problem is that we now get a double-inversion for low-active
> GPIOs. For example, we have this in the Jetson TK1 device tree:
>
>                 vdd_hdmi_pll: regulator@11 {
>                         compatible = "regulator-fixed";
>                         reg = <11>;
>                         regulator-name = "+1.05V_RUN_AVDD_HDMI_PLL";
>                         regulator-min-microvolt = <1050000>;
>                         regulator-max-microvolt = <1050000>;
>                         gpio = <&gpio TEGRA_GPIO(H, 7) GPIO_ACTIVE_LOW>;
>                         vin-supply = <&vdd_1v05_run>;
>                 };
>
> We've got GPIO_ACTIVE_LOW for the regulator's enable GPIO and since we
> don't have enable-active-high, the regulator core will treat the GPIO as
> low active. The presence of the GPIO_ACTIVE_LOW flag will cause the GPIO
> polarity to be inversed, transparently in gpiolib, and the lack of the
> enable-active-high property causes the GPIO polarity to inversed as
> well, so we effectively end up with a high-active enable GPIO for one
> which should really be low-active.

I dug into this. It turns out there are some layers of mess....

The DT binding for "regulator-fixed" specifies that enable-active-high
should be set for polarity inversion. For historical reasons, I guess,
we screwed up. The example in the binding uses that.

I interpreted the binding such that also specifying GPIO_ACTIVE_LOW
was essentially illegal, so I patched gpiolib in commit
a603a2b8d86ee93ee2107da8ca75fd854fd4ff32
"gpio: of: Add special quirk to parse regulator flags"
so it looks like that:

+       if (IS_ENABLED(CONFIG_REGULATOR) &&
+           (of_device_is_compatible(np, "reg-fixed-voltage") ||
+            of_device_is_compatible(np, "regulator-gpio"))) {
+               /*
+                * The regulator GPIO handles are specified such that the
+                * presence or absence of "enable-active-high" solely controls
+                * the polarity of the GPIO line. Any phandle flags must
+                * be actively ignored.
+                */
+               if (*flags & OF_GPIO_ACTIVE_LOW) {
+                       pr_warn("%s GPIO handle specifies active low -
ignored\n",
+                               of_node_full_name(np));
+                       *flags &= ~OF_GPIO_ACTIVE_LOW;
+               }
+               if (!of_property_read_bool(np, "enable-active-high"))
+                       *flags |= OF_GPIO_ACTIVE_LOW;
+       }

This means no matter if you specify active low, the GPIO
will be treated as active low, as this is the default behaviour.
We will warn if things are overspecified as active low on the
flag as well.

The second clause (notice nagation!) specifies that
if enable-acive-high flag is NOT specified, we will be active
low.

Sadly this only handled the undocumented fixed
regulator binding "reg-fixed-voltage". So I need to fix it
for "regulator-fixed" as well, and then it "should work".

I will follow up with a patch.

Yours,
Linus Walleij

  parent reply	other threads:[~2018-06-11 13:11 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14  8:06 [PATCH 00/19 v3] Refactor fixed and GPIO regulators Linus Walleij
2018-05-14  8:06 ` [PATCH 01/19 v3] regulator: fixed: Convert to use GPIO descriptor only Linus Walleij
2018-05-14 11:03   ` Andy Shevchenko
2018-05-21 11:27     ` Linus Walleij
2018-07-06 15:21       ` Andy Shevchenko
2018-05-14 11:49   ` Geert Uytterhoeven
2018-05-17 19:50   ` Tony Lindgren
2018-05-30 21:27   ` Arnd Bergmann
2018-06-01  9:35   ` Thierry Reding
2018-06-01  9:36     ` Thierry Reding
2018-06-01 10:21     ` Mark Brown
2018-06-11 13:11     ` Linus Walleij [this message]
2018-06-11 15:00       ` Mark Brown
2018-06-12  8:15         ` Linus Walleij
2018-06-12 11:00           ` Mark Brown
2018-05-14  8:06 ` [PATCH 02/19 v3] regulator: gpio: Get enable GPIO using GPIO descriptor Linus Walleij
2018-05-14  8:06 ` [PATCH 03/19 v3] regulator: arizona-ldo1: Look up a descriptor and pass to the core Linus Walleij
2018-05-15 11:53   ` Charles Keepax
2018-05-17 16:41   ` Applied "regulator: arizona-ldo1: Look up a descriptor and pass to the core" to the regulator tree Mark Brown
2018-05-14  8:06 ` [PATCH 04/19 v3] regulator: max8973: Pass descriptor instead of GPIO number Linus Walleij
2018-05-14  8:06 ` [PATCH 05/19 v3] regulator: max77686: " Linus Walleij
2018-05-14  9:28   ` Krzysztof Kozlowski
2018-05-17 16:41   ` Applied "regulator: max77686: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-05-14  8:06 ` [PATCH 06/19 v3] regulator: lm363x: Pass descriptor instead of GPIO number Linus Walleij
2018-05-14  8:06 ` [PATCH 07/19 v3] regulator: lp8788-ldo: " Linus Walleij
2018-05-14  8:06 ` [PATCH 08/19 v3] regulator: max8952: " Linus Walleij
2018-05-14  8:06 ` [PATCH 09/19 v3] regulator: pfuze100: Delete reference to ena_gpio Linus Walleij
2018-05-14  8:06 ` [PATCH 10/19 v3] regulator: s2mps11: Pass descriptor instead of GPIO number Linus Walleij
2018-05-14  9:42   ` Krzysztof Kozlowski
2018-05-26 10:02   ` Mark Brown
2018-05-28  8:41     ` Linus Walleij
     [not found]       ` <CGME20180528112908eucas1p2946a9b6385fcaf6c19921c9767420405@eucas1p2.samsung.com>
2018-05-28 11:29         ` Bartlomiej Zolnierkiewicz
2018-05-28 12:26           ` Andy Shevchenko
2018-05-30  7:10             ` Linus Walleij
2018-05-29 14:47           ` Mark Brown
     [not found]           ` <CGME20180530134408eucas1p14c6d7fe692e2ed91ef833c8a1ead8ce7@eucas1p1.samsung.com>
2018-05-30 13:44             ` Bartlomiej Zolnierkiewicz
2018-05-30 14:16               ` Mark Brown
2018-05-14  8:06 ` [PATCH 11/19 v3] regulator: s5m8767: " Linus Walleij
2018-05-14  8:06 ` [PATCH 12/19 v3] regulator: tps65090: " Linus Walleij
2018-05-14  8:06 ` [PATCH 13/19 v3] regulator: wm8994: " Linus Walleij
2018-05-14  8:06 ` [PATCH 14/19 v3] regulator: core: Only support passing enable GPIO descriptors Linus Walleij
2018-05-14  8:06 ` [PATCH 15/19 v3] regulator: fixed/gpio: Pull inversion/OD into gpiolib Linus Walleij
2018-05-29 14:54   ` Mark Brown
2018-05-30  7:15     ` Linus Walleij
2018-05-14  8:06 ` [PATCH 16/19 v3] regulator: fixed/gpio: Update device tree bindings Linus Walleij
2018-05-14  8:06 ` [PATCH 17/19 v3] regulator: gpio: Convert to fully use descriptors Linus Walleij
2018-05-14  8:06 ` [PATCH 18/19 v3] regulator: gpio: Simplify probe path Linus Walleij
2018-05-14  8:06 ` [PATCH 19/19 v3] ARM: s3c64xx: Tidy up handling of regulator GPIO lookups Linus Walleij
2018-05-17  5:06   ` Mark Brown
2018-05-21 11:24     ` Linus Walleij

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=CACRpkdZEMPfxHc8dZOvyYN+S4o_zwKuYCTBbMiXMLsCZRz_f6A@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=aaro.koskinen@iki.fi \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=haojian.zhuang@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=philipp.zabel@gmail.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=robert.jarzmik@free.fr \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=shc_work@mail.ru \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.com \
    --cc=zonque@gmail.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).