From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
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 <mike@compulab.co.il>,
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>
Subject: Re: [PATCH 02/21] regulator: fixed: Convert to use GPIO descriptor only
Date: Mon, 12 Feb 2018 17:13:31 +0200 [thread overview]
Message-ID: <1518448411.22495.286.camel@linux.intel.com> (raw)
In-Reply-To: <20180212131717.27193-3-linus.walleij@linaro.org>
On Mon, 2018-02-12 at 14:16 +0100, 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.
>
> Some boards just auto-enumerate their fixed regulator platform devices
> and I have assumed they get names like "fixed-regulator.0" but it's
> pretty hard to guess this. I need some testing from board maintainers
> to
> be sure. Other boards are straight forward, using just plain
> "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
> device ID.
>
> The OMAP didn't have proper label names on its GPIO chips so I have
> fixed
> this with a separate patch to the GPIO tree.
>
> It seems the da9055 and da9211 has never got around to actually
> passing
> any enable gpio into its platform data (not the in-tree code anyway)
> so we
> can just decide to simply pass a descriptor instead.
>
> The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly
> named
> "*_dummy_supply_device" while it is a very real device backed by a
> GPIO
> line. There is nothing dummy about it at all, so I renamed it with the
> infix *_regulator_* as part of this patch set.
>
> For the patch hunk hitting arch/blackfin I would say I do not expect
> testing, review or ACKs anymore so if it works, it works.
>
> The hunk hitting the x86 BCM43xx driver is especially tricky as the
> number
> comes out of SFI which is a mystery to me. I definately need someone
> to
> look at this. (Hi Andy.)
Hi, Linus!
Nice patch, though I have comments below.
> --- a/arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c
> +++ b/arch/x86/platform/intel-mid/device_libs/platform_bcm43xx.c
> @@ -43,7 +43,6 @@ static struct fixed_voltage_config bcm43xx_vmmc = {
> * real voltage and signaling are still 1.8V.
> */
> .microvolts = 2000000, /* 1.8V
> */
> - .gpio = -EINVAL,
> .startup_delay = 250 * 1000, /*
> 250ms */
> .enable_high = 1, /*
> active high */
> .enabled_at_boot = 0, /*
> disabled at boot */
> @@ -58,11 +57,25 @@ static struct platform_device
> bcm43xx_vmmc_regulator = {
> },
> };
>
> +static struct gpiod_lookup_table bcm43xx_vmmc_gpio_table = {
> + .dev_id = "reg-fixed-voltage.0",
I'm not sure this will be always like this.
We have DEVID_AUTO, which theoretically can be anything.
Okay, it looks like we have only one static regulator for now for Intel
MID. Though it's fragile if anything will change in the future (quite
unlikely).
> + .table = {
> + /* CHECKME: is this the correct PCI address for the
> GPIO controller? */
Yes.
> + GPIO_LOOKUP("0000:00:0c.0", -1, "enable",
> GPIO_ACTIVE_LOW),
> + { },
Terminator should terminate even at compile time, right?
Simple
{}
looks better to me.
> + },
> +};
> +
> static int __init bcm43xx_regulator_register(void)
> {
> + struct gpiod_lookup_table *table = &bcm43xx_vmmc_gpio_table;
> + struct gpiod_lookup *lookup = table->table;
> int ret;
>
> - bcm43xx_vmmc.gpio =
> get_gpio_by_name(WLAN_SFI_GPIO_ENABLE_NAME);
> + /* FIXME: convert SFI layer to use GPIO descriptors
> internally */
We already discussed this few years ago and decide not to do anything
WRT SFI. It should just die.
> + lookup[0].chip_hwnum =
> get_gpio_by_name(WLAN_SFI_GPIO_ENABLE_NAME);
> + gpiod_add_lookup_table(table);
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> cfg.ena_gpio_invert = !config->enable_high;
> if (config->enabled_at_boot) {
> if (config->enable_high)
> - cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
> + gflags = GPIOD_OUT_HIGH;
> else
> - cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
> + gflags = GPIOD_OUT_LOW;
> } else {
> if (config->enable_high)
> - cfg.ena_gpio_flags |= GPIOF_OUT_INIT_LOW;
> + gflags = GPIOD_OUT_LOW;
> else
> - cfg.ena_gpio_flags |= GPIOF_OUT_INIT_HIGH;
> + gflags = GPIOD_OUT_HIGH;
> }
Just a side note: It might make sense to split this to some kind of
generic helper, like:
static inline enum gpiod_flags gpiod_flags_output(bool value, bool
invert)
{
...
}
> + if (config->gpio_is_open_drain) {
> + if (gflags == GPIOD_OUT_HIGH)
> + gflags = GPIOD_OUT_HIGH_OPEN_DRAIN;
> + else
> + gflags = GPIOD_OUT_LOW_OPEN_DRAIN;
> + }
> +
> + cfg.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, NULL,
> gflags);
Shouldn't we be a little bit more stricter here, i.e. require "enable"
name?
> + if (IS_ERR(cfg.ena_gpiod))
> + return PTR_ERR(cfg.ena_gpiod);
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-02-12 15:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 13:16 [PATCH 00/21] regulator: switch core to GPIO descriptors Linus Walleij
2018-02-12 13:16 ` [PATCH 01/21] regulator: core: Support passing an initialized GPIO enable descriptor Linus Walleij
2018-02-16 17:12 ` Applied "regulator: core: Support passing an initialized GPIO enable descriptor" to the regulator tree Mark Brown
2018-02-12 13:16 ` [PATCH 02/21] regulator: fixed: Convert to use GPIO descriptor only Linus Walleij
2018-02-12 15:13 ` Andy Shevchenko [this message]
2018-04-19 12:36 ` Linus Walleij
2018-02-12 13:16 ` [PATCH 03/21] regulator: gpio: Get enable GPIO using GPIO descriptor Linus Walleij
2018-05-29 14:59 ` Applied "regulator: gpio: Get enable GPIO using GPIO descriptor" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 04/21] regulator: da9055: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 14:59 ` Lee Jones
2018-02-16 17:12 ` Applied "regulator: da9055: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 05/21] regulator: arizona-ldo1: Look up a descriptor and pass to the core Linus Walleij
2018-02-13 11:06 ` Charles Keepax
2018-04-19 13:43 ` Linus Walleij
2018-04-19 15:02 ` Charles Keepax
2018-02-13 11:51 ` Charles Keepax
2018-02-12 13:17 ` [PATCH 06/21] regulator: da9211: Pass descriptors instead of GPIO numbers Linus Walleij
2018-02-16 17:12 ` Applied "regulator: da9211: Pass descriptors instead of GPIO numbers" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 07/21] regulator: max8973: Pass descriptor instead of GPIO number Linus Walleij
2018-05-24 19:14 ` Applied "regulator: max8973: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 08/21] regulator: max77686: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 13:37 ` Krzysztof Kozlowski
2018-02-12 13:17 ` [PATCH 09/21] regulator: lm363x: " Linus Walleij
2018-05-24 19:14 ` Applied "regulator: lm363x: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 10/21] regulator: lp8788-ldo: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 14:59 ` Lee Jones
2018-05-24 19:14 ` Applied "regulator: lp8788-ldo: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 11/21] regulator: max8952: Pass descriptor instead of GPIO number Linus Walleij
2018-05-24 19:14 ` Applied "regulator: max8952: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 12/21] regulator: pfuze100: Delete reference to ena_gpio Linus Walleij
2018-05-24 19:14 ` Applied "regulator: pfuze100: Delete reference to ena_gpio" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 13/21] regulator: s2mps11: Pass descriptor instead of GPIO number Linus Walleij
2018-05-17 16:41 ` Applied "regulator: s2mps11: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 14/21] regulator: s5m8767: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 14:58 ` Lee Jones
2018-05-24 19:13 ` Applied "regulator: s5m8767: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 15/21] regulator: tps65090: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 14:58 ` Lee Jones
2018-05-24 19:13 ` Applied "regulator: tps65090: Pass descriptor instead of GPIO number" to the regulator tree Mark Brown
2018-02-12 13:17 ` [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number Linus Walleij
2018-02-12 14:58 ` Lee Jones
2018-02-13 11:11 ` Charles Keepax
2018-04-19 13:55 ` Linus Walleij
2018-04-19 14:05 ` Mark Brown
2018-04-19 15:01 ` [PATCH] ARM: s3c64xx: Tidy up handling of regulator GPIO lookups Charles Keepax
2018-05-14 5:54 ` Linus Walleij
2018-02-13 11:52 ` [PATCH 16/21] regulator: wm8994: Pass descriptor instead of GPIO number Charles Keepax
2018-02-12 13:17 ` [PATCH 17/21] regulator: core: Only support passing enable GPIO descriptors Linus Walleij
2018-02-12 13:17 ` [PATCH 18/21] regulator: fixed/gpio: Pull inversion/OD into gpiolib Linus Walleij
2018-02-17 9:59 ` Robert Jarzmik
2018-02-12 13:17 ` [PATCH 19/21] regulator: fixed/gpio: Update device tree bindings Linus Walleij
2018-02-19 2:41 ` Rob Herring
2018-02-12 13:17 ` [PATCH 20/21] regulator: gpio: Convert to fully use descriptors Linus Walleij
2018-02-12 13:17 ` [PATCH 21/21] regulator: gpio: Simplify probe path 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=1518448411.22495.286.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=aaro.koskinen@iki.fi \
--cc=broonie@kernel.org \
--cc=geert+renesas@glider.be \
--cc=haojian.zhuang@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mike@compulab.co.il \
--cc=philipp.zabel@gmail.com \
--cc=robert.jarzmik@free.fr \
--cc=shc_work@mail.ru \
--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).