From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> To: Marco Felsch <m.felsch@pengutronix.de>, Mark Brown <broonie@kernel.org> Cc: Support Opensource <Support.Opensource@diasemi.com>, "lee.jones@linaro.org" <lee.jones@linaro.org>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>, "joel@jms.id.au" <joel@jms.id.au>, "andrew@aj.id.au" <andrew@aj.id.au>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "kernel@pengutronix.de" <kernel@pengutronix.de> Subject: RE: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage selection documentation Date: Wed, 11 Dec 2019 16:14:09 +0000 [thread overview] Message-ID: <AM5PR1001MB099497419E4DCA69D424EC35805A0@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM> (raw) In-Reply-To: <20191210094144.mxximpuouchy3fqu@pengutronix.de> On 10 December 2019 09:42, Marco Felsch wrote: > Hi Mark, > > On 19-12-04 13:46, Mark Brown wrote: > > On Fri, Nov 29, 2019 at 06:25:34PM +0100, Marco Felsch wrote: > > > > > + Optional regulator device-specific properties: > > > + - dlg,vsel-sense-gpios : A GPIO reference to a local general purpose input, > > > + the datasheet calls it GPI. The regulator sense the input signal and select > > > + the active or suspend voltage settings. If the signal is active the > > > + active-settings are applied else the suspend-settings are applied. > > > + Attention: Sharing the same GPI for other purposes or across multiple > > > + regulators is possible but the polarity setting must equal. > > > > I'm really confused by this. As far as I understand it it seems > > to be doing pinmuxing on the chip using the GPIO bindings which > > is itself a bit odd and I don't see anything here that configures > > whatever sets the state of the pins. Don't we need another GPIO > > to set the vsel-sense inputs on the PMIC? > > Yes the PMIC is very configurable and it took a while till I understand > it.. @Adam please correct me if I'm wrong. > > The PMIC regulators regardless of the type: ldo or buck can be > simplified drawn as: > > > > da9062-gpio da9062-regulator > > +------------------------------------------------------- > | PMIC > | > > GPIO0 +--------------------------+ > | | REGULATOR-0 | > > GPIO1 -------+ | | > | +-- > vsel-in voltage-a-out < > > GPIO2 | | | > | | > enable-in voltage-b-out < > | | | | > | | +--------------------------+ > | | > | | +--------------------------+ > | | | REGULATOR-1 | > | | | | > | +-- > vsel-in voltage-a-out < > | | | > | > enable-in voltage-b-out < > | | | > | +--------------------------+ > | > > The 'vsel-in' and 'enable-in' regulator inputs must be routed to the > PMIC GPIOs which must be configured as input. If this is a pinmux in > your opinion, then yes we need to do that. IMHO it isn't a pinmux > because from the regulator point of view it is just a GPIO which comes > from our own gpio-dev (da9062-gpio). So the abstraction is vald. Anyway > I'm with you that this isn't the typical use-case. We've had this discussion before and to me it felt more like pinmux than GPIO although I understand we're configuring the GPIO pin as input before then configuring a regulator to take that specific internal GPIO as the control signal. We're defining a specific role to this pin in HW rather than it being a general software handled GPI so it feels like this would be neater under pinmux. There does still need to be a mapping between that pin and the regulator which I guess would be served by passing the pin to the regulator through generic pinmux bindings and then in the regulator code you're simply just enabling the regulator to be controlled from that pin. The HW lets you control multiple regulators from the same input pin so there's a flexibility there to be captured, as you mention. > > Regards, > Marco > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> To: Marco Felsch <m.felsch@pengutronix.de>, Mark Brown <broonie@kernel.org> Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Support Opensource <Support.Opensource@diasemi.com>, "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>, "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>, "andrew@aj.id.au" <andrew@aj.id.au>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "joel@jms.id.au" <joel@jms.id.au>, "kernel@pengutronix.de" <kernel@pengutronix.de>, "lee.jones@linaro.org" <lee.jones@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage selection documentation Date: Wed, 11 Dec 2019 16:14:09 +0000 [thread overview] Message-ID: <AM5PR1001MB099497419E4DCA69D424EC35805A0@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM> (raw) In-Reply-To: <20191210094144.mxximpuouchy3fqu@pengutronix.de> On 10 December 2019 09:42, Marco Felsch wrote: > Hi Mark, > > On 19-12-04 13:46, Mark Brown wrote: > > On Fri, Nov 29, 2019 at 06:25:34PM +0100, Marco Felsch wrote: > > > > > + Optional regulator device-specific properties: > > > + - dlg,vsel-sense-gpios : A GPIO reference to a local general purpose input, > > > + the datasheet calls it GPI. The regulator sense the input signal and select > > > + the active or suspend voltage settings. If the signal is active the > > > + active-settings are applied else the suspend-settings are applied. > > > + Attention: Sharing the same GPI for other purposes or across multiple > > > + regulators is possible but the polarity setting must equal. > > > > I'm really confused by this. As far as I understand it it seems > > to be doing pinmuxing on the chip using the GPIO bindings which > > is itself a bit odd and I don't see anything here that configures > > whatever sets the state of the pins. Don't we need another GPIO > > to set the vsel-sense inputs on the PMIC? > > Yes the PMIC is very configurable and it took a while till I understand > it.. @Adam please correct me if I'm wrong. > > The PMIC regulators regardless of the type: ldo or buck can be > simplified drawn as: > > > > da9062-gpio da9062-regulator > > +------------------------------------------------------- > | PMIC > | > > GPIO0 +--------------------------+ > | | REGULATOR-0 | > > GPIO1 -------+ | | > | +-- > vsel-in voltage-a-out < > > GPIO2 | | | > | | > enable-in voltage-b-out < > | | | | > | | +--------------------------+ > | | > | | +--------------------------+ > | | | REGULATOR-1 | > | | | | > | +-- > vsel-in voltage-a-out < > | | | > | > enable-in voltage-b-out < > | | | > | +--------------------------+ > | > > The 'vsel-in' and 'enable-in' regulator inputs must be routed to the > PMIC GPIOs which must be configured as input. If this is a pinmux in > your opinion, then yes we need to do that. IMHO it isn't a pinmux > because from the regulator point of view it is just a GPIO which comes > from our own gpio-dev (da9062-gpio). So the abstraction is vald. Anyway > I'm with you that this isn't the typical use-case. We've had this discussion before and to me it felt more like pinmux than GPIO although I understand we're configuring the GPIO pin as input before then configuring a regulator to take that specific internal GPIO as the control signal. We're defining a specific role to this pin in HW rather than it being a general software handled GPI so it feels like this would be neater under pinmux. There does still need to be a mapping between that pin and the regulator which I guess would be served by passing the pin to the regulator through generic pinmux bindings and then in the regulator code you're simply just enabling the regulator to be controlled from that pin. The HW lets you control multiple regulators from the same input pin so there's a flexibility there to be captured, as you mention. > > Regards, > Marco > > -- > Pengutronix e.K. | | > Steuerwalder Str. 21 | http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-11 16:14 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-29 17:25 [PATCH v3 0/6] DA9062 PMIC features Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-11-29 17:25 ` [PATCH v3 1/6] gpio: treewide rename gpio_chip_hwgpio to gpiod_to_offset Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-12-02 2:59 ` Andrew Jeffery 2019-12-02 2:59 ` Andrew Jeffery 2019-11-29 17:25 ` [PATCH v3 2/6] gpio: make gpiod_to_offset() available for other users Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-12-02 3:00 ` Andrew Jeffery 2019-12-02 3:00 ` Andrew Jeffery 2019-11-29 17:25 ` [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage selection documentation Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-12-04 13:46 ` Mark Brown 2019-12-04 13:46 ` Mark Brown 2019-12-10 9:41 ` Marco Felsch 2019-12-10 9:41 ` Marco Felsch 2019-12-11 16:14 ` Adam Thomson [this message] 2019-12-11 16:14 ` Adam Thomson 2019-12-11 17:09 ` Marco Felsch 2019-12-11 17:09 ` Marco Felsch 2019-12-12 15:08 ` Linus Walleij 2019-12-12 15:08 ` Linus Walleij 2019-12-12 15:55 ` Marco Felsch 2019-12-12 15:55 ` Marco Felsch 2019-12-12 16:10 ` Mark Brown 2019-12-12 16:10 ` Mark Brown 2019-12-12 16:21 ` Marco Felsch 2019-12-12 16:21 ` Marco Felsch 2019-12-12 16:51 ` Mark Brown 2019-12-12 16:51 ` Mark Brown 2019-12-16 8:55 ` Marco Felsch 2019-12-16 8:55 ` Marco Felsch 2019-12-16 11:44 ` Mark Brown 2019-12-16 11:44 ` Mark Brown 2019-12-17 7:35 ` Marco Felsch 2019-12-17 7:35 ` Marco Felsch 2019-12-17 12:58 ` Mark Brown 2019-12-17 12:58 ` Mark Brown 2020-01-07 8:36 ` Marco Felsch 2020-01-07 8:36 ` Marco Felsch 2020-01-07 13:09 ` Mark Brown 2020-01-07 13:09 ` Mark Brown 2020-01-07 13:38 ` Marco Felsch 2020-01-07 13:38 ` Marco Felsch 2020-01-14 15:43 ` Mark Brown 2020-01-14 15:43 ` Mark Brown 2019-12-16 16:32 ` Adam Thomson 2019-12-16 16:32 ` Adam Thomson 2019-12-17 9:00 ` Marco Felsch 2019-12-17 9:00 ` Marco Felsch 2019-12-17 9:12 ` Marco Felsch 2019-12-17 9:12 ` Marco Felsch 2019-12-17 9:53 ` Adam Thomson 2019-12-17 9:53 ` Adam Thomson 2019-12-17 12:31 ` Marco Felsch 2019-12-17 12:31 ` Marco Felsch 2019-12-17 13:13 ` Adam Thomson 2019-12-17 13:13 ` Adam Thomson 2019-12-16 16:32 ` Adam Thomson 2019-12-16 16:32 ` Adam Thomson 2019-12-16 12:28 ` Linus Walleij 2019-12-16 12:28 ` Linus Walleij 2019-11-29 17:25 ` [PATCH v3 4/6] regulator: da9062: add voltage selection gpio support Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-11-29 17:25 ` [PATCH v3 5/6] dt-bindings: mfd: da9062: add regulator gpio enable/disable documentation Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-12-13 22:23 ` Rob Herring 2019-12-13 22:23 ` Rob Herring 2019-12-16 16:31 ` Lee Jones 2019-12-16 16:31 ` Lee Jones 2019-11-29 17:25 ` [PATCH v3 6/6] regulator: da9062: add gpio based regulator dis-/enable support Marco Felsch 2019-11-29 17:25 ` Marco Felsch 2019-12-02 11:44 ` [PATCH v3 0/6] DA9062 PMIC features Linus Walleij 2019-12-02 11:44 ` Linus Walleij 2019-12-02 12:04 ` Lee Jones 2019-12-02 12:04 ` Lee Jones
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=AM5PR1001MB099497419E4DCA69D424EC35805A0@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM \ --to=adam.thomson.opensource@diasemi.com \ --cc=Support.Opensource@diasemi.com \ --cc=andrew@aj.id.au \ --cc=bgolaszewski@baylibre.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=joel@jms.id.au \ --cc=kernel@pengutronix.de \ --cc=lee.jones@linaro.org \ --cc=lgirdwood@gmail.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=m.felsch@pengutronix.de \ --cc=robh+dt@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.