From: Nishanth Menon <nm@ti.com> To: Mark Brown <broonie@kernel.org> Cc: jerome Neanne <jneanne@baylibre.com>, Wadim Egorov <W.Egorov@phytec.de>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "kristo@kernel.org" <kristo@kernel.org>, "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "lee@kernel.org" <lee@kernel.org>, "tony@atomide.com" <tony@atomide.com>, "vigneshr@ti.com" <vigneshr@ti.com>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "geert+renesas@glider.be" <geert+renesas@glider.be>, "dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>, "marcel.ziswiler@toradex.com" <marcel.ziswiler@toradex.com>, "vkoul@kernel.org" <vkoul@kernel.org>, "biju.das.jz@bp.renesas.com" <biju.das.jz@bp.renesas.com>, "arnd@arndb.de" <arnd@arndb.de>, "jeff@labundy.com" <jeff@labundy.com>, "afd@ti.com" <afd@ti.com>, "khilman@baylibre.com" <khilman@baylibre.com>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "msp@baylibre.com" <msp@baylibre.com>, "j-keerthy@ti.com" <j-keerthy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org> Subject: Re: [PATCH v7 1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board. Date: Thu, 15 Dec 2022 15:41:49 -0600 [thread overview] Message-ID: <20221215214149.whcjdphxxvvedrih@affront> (raw) In-Reply-To: <Y5tl3+2pJispcXy6@sirena.org.uk> On 18:22-20221215, Mark Brown wrote: > On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote: > > On 16:09-20221215, Mark Brown wrote: > > > > That proposal looks really non-idiomatic and quite unusual, if there's a > > > fixed voltage supply to the LDO I'd expect to see it modeled as a fixed > > > voltage regulator. I'm not sure what the use of bypass here is trying > > > to accomplish TBH. > > > The problem is this - the default NVM in the PMIC is setup such that > > VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v). > > This implies no voltage drop over the LDO? Sounds a bit suspect. Not the choice I'd probably have made ;) > > > Now the constraint is bypass bit cannot be changed without the LDO > > being switched off. > > > regulator-allow-bypass property allows us to control bypass bit, but we > > should'nt toggle it when LDO is active. Not providing the property > > implies the bit wont be toggled by regulator core either. > > > What we need is a scheme that will disable the bypass bit with the > > intent of operating the LDO with just the vset field. I did'nt find it > > possible atm.. unless I am mistaken.. > > Can the consumer just disable the supply as part of startup? Though > that's starting to feel rather board specific. There's not really a Yeah - this happens to be SDcard supply (at least in my case).. I'd rather not change the mmc host or core layer to handle a case where LDO happened to be in bypass. it is a regulator driver's problem, IMHO how to provide the stated voltage OR fail to transition the voltage. In this driver's case, it happily accepts and set the VSET voltage - for example to 1.8V, but then, since the bypass bit is set, well, voltage sticks around at 3.3v. > good place to put a board specific setup process like that in the kernel > at the minute, you'd ideally want the firmware to leave the device at > least disabled if not actually out of bypass on startup so we don't have > to deal with this. Ugh... Yeah - that would be the other option - I could plug this bypass clear in the u-boot or someplace early so that the LDO behaves Also the reason why I did'nt send the mentioned patch (or the like upstream and the patch was done just a couple of days back) were the following questions: a) Why would'nt we handle the case where bypass bit is set AND voltage change implies bypass bit needs to be disabled? (i would expect it to fail but if i did provide regulator-allow-bypass, then if bypass is set AND requested-voltage != vin-supply, then i'd have expected framework to probably disable bypass and switch voltage to new voltage - which this driver, based on it's constraint will say "nope, cant do" - but that would be better than silently telling me all good, setting vset and leaving the bypass bit on.) b) If I wanted the LDO to poweroff the bypass bit at start (define the startup hardware condition), I dont seem to have a description for that either. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Menon <nm@ti.com> To: Mark Brown <broonie@kernel.org> Cc: jerome Neanne <jneanne@baylibre.com>, Wadim Egorov <W.Egorov@phytec.de>, "lgirdwood@gmail.com" <lgirdwood@gmail.com>, "robh+dt@kernel.org" <robh+dt@kernel.org>, "kristo@kernel.org" <kristo@kernel.org>, "dmitry.torokhov@gmail.com" <dmitry.torokhov@gmail.com>, "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "lee@kernel.org" <lee@kernel.org>, "tony@atomide.com" <tony@atomide.com>, "vigneshr@ti.com" <vigneshr@ti.com>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "geert+renesas@glider.be" <geert+renesas@glider.be>, "dmitry.baryshkov@linaro.org" <dmitry.baryshkov@linaro.org>, "marcel.ziswiler@toradex.com" <marcel.ziswiler@toradex.com>, "vkoul@kernel.org" <vkoul@kernel.org>, "biju.das.jz@bp.renesas.com" <biju.das.jz@bp.renesas.com>, "arnd@arndb.de" <arnd@arndb.de>, "jeff@labundy.com" <jeff@labundy.com>, "afd@ti.com" <afd@ti.com>, "khilman@baylibre.com" <khilman@baylibre.com>, "narmstrong@baylibre.com" <narmstrong@baylibre.com>, "msp@baylibre.com" <msp@baylibre.com>, "j-keerthy@ti.com" <j-keerthy@ti.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org> Subject: Re: [PATCH v7 1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board. Date: Thu, 15 Dec 2022 15:41:49 -0600 [thread overview] Message-ID: <20221215214149.whcjdphxxvvedrih@affront> (raw) In-Reply-To: <Y5tl3+2pJispcXy6@sirena.org.uk> On 18:22-20221215, Mark Brown wrote: > On Thu, Dec 15, 2022 at 11:54:11AM -0600, Nishanth Menon wrote: > > On 16:09-20221215, Mark Brown wrote: > > > > That proposal looks really non-idiomatic and quite unusual, if there's a > > > fixed voltage supply to the LDO I'd expect to see it modeled as a fixed > > > voltage regulator. I'm not sure what the use of bypass here is trying > > > to accomplish TBH. > > > The problem is this - the default NVM in the PMIC is setup such that > > VSET value =3.3v and bypass bit set (makes sense since the vin=3.3v). > > This implies no voltage drop over the LDO? Sounds a bit suspect. Not the choice I'd probably have made ;) > > > Now the constraint is bypass bit cannot be changed without the LDO > > being switched off. > > > regulator-allow-bypass property allows us to control bypass bit, but we > > should'nt toggle it when LDO is active. Not providing the property > > implies the bit wont be toggled by regulator core either. > > > What we need is a scheme that will disable the bypass bit with the > > intent of operating the LDO with just the vset field. I did'nt find it > > possible atm.. unless I am mistaken.. > > Can the consumer just disable the supply as part of startup? Though > that's starting to feel rather board specific. There's not really a Yeah - this happens to be SDcard supply (at least in my case).. I'd rather not change the mmc host or core layer to handle a case where LDO happened to be in bypass. it is a regulator driver's problem, IMHO how to provide the stated voltage OR fail to transition the voltage. In this driver's case, it happily accepts and set the VSET voltage - for example to 1.8V, but then, since the bypass bit is set, well, voltage sticks around at 3.3v. > good place to put a board specific setup process like that in the kernel > at the minute, you'd ideally want the firmware to leave the device at > least disabled if not actually out of bypass on startup so we don't have > to deal with this. Ugh... Yeah - that would be the other option - I could plug this bypass clear in the u-boot or someplace early so that the LDO behaves Also the reason why I did'nt send the mentioned patch (or the like upstream and the patch was done just a couple of days back) were the following questions: a) Why would'nt we handle the case where bypass bit is set AND voltage change implies bypass bit needs to be disabled? (i would expect it to fail but if i did provide regulator-allow-bypass, then if bypass is set AND requested-voltage != vin-supply, then i'd have expected framework to probably disable bypass and switch voltage to new voltage - which this driver, based on it's constraint will say "nope, cant do" - but that would be better than silently telling me all good, setting vset and leaving the bypass bit on.) b) If I wanted the LDO to poweroff the bypass bit at start (define the startup hardware condition), I dont seem to have a description for that either. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D _______________________________________________ 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:[~2022-12-15 21:42 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-04 15:23 [PATCH v7 0/6] Add support for TI TPS65219 PMIC Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-04 15:23 ` [PATCH v7 1/6] DONOTMERGE: arm64: dts: ti: Add TI TPS65219 PMIC support for AM642 SK board Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-12-15 15:09 ` Wadim Egorov 2022-12-15 15:09 ` Wadim Egorov 2022-12-15 15:51 ` jerome Neanne 2022-12-15 15:51 ` jerome Neanne 2022-12-15 16:09 ` Mark Brown 2022-12-15 16:09 ` Mark Brown 2022-12-15 17:54 ` Nishanth Menon 2022-12-15 17:54 ` Nishanth Menon 2022-12-15 18:22 ` Mark Brown 2022-12-15 18:22 ` Mark Brown 2022-12-15 21:41 ` Nishanth Menon [this message] 2022-12-15 21:41 ` Nishanth Menon 2022-12-16 6:21 ` Vignesh Raghavendra 2022-12-16 6:21 ` Vignesh Raghavendra 2022-12-16 7:28 ` jerome Neanne 2022-12-16 7:28 ` jerome Neanne 2022-12-16 13:41 ` Mark Brown 2022-12-16 13:41 ` Mark Brown 2022-12-28 10:16 ` Wadim Egorov 2022-12-28 10:16 ` Wadim Egorov 2022-11-04 15:23 ` [PATCH v7 2/6] DONOTMERGE: arm64: dts: ti: Add pinmux and irq mapping for TPS65219 external interrupts Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-04 15:23 ` [PATCH v7 3/6] DONOTMERGE: arm64: dts: ti: k3-am642-sk: Enable tps65219 power-button Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-04 15:23 ` [PATCH v7 4/6] mfd: tps65219: Add driver for TI TPS65219 PMIC Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-15 22:26 ` Kevin Hilman 2022-11-15 22:26 ` Kevin Hilman 2022-11-15 23:14 ` Kevin Hilman 2022-11-15 23:14 ` Kevin Hilman 2022-11-16 13:58 ` Lee Jones 2022-11-16 13:58 ` Lee Jones 2022-11-16 18:11 ` Lee Jones 2022-11-16 18:11 ` Lee Jones 2022-11-04 15:23 ` [PATCH v7 5/6] Input: Add tps65219 interrupt driven powerbutton Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-17 11:53 ` Lee Jones 2022-11-17 11:53 ` Lee Jones 2022-11-04 15:23 ` [PATCH v7 6/6] arm64: defconfig: Add tps65219 as modules Jerome Neanne 2022-11-04 15:23 ` Jerome Neanne 2022-11-15 22:23 ` Kevin Hilman 2022-11-15 22:23 ` Kevin Hilman 2022-11-17 16:00 ` Kevin Hilman 2022-11-17 16:00 ` Kevin Hilman 2022-12-05 18:08 ` [PATCH v7 0/6] Add support for TI TPS65219 PMIC Francesco Dolcini 2022-12-05 18:08 ` Francesco Dolcini 2022-12-06 19:22 ` jerome Neanne 2022-12-06 19:22 ` jerome Neanne 2023-05-22 11:57 ` jerome Neanne 2023-05-22 11:57 ` jerome Neanne
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=20221215214149.whcjdphxxvvedrih@affront \ --to=nm@ti.com \ --cc=W.Egorov@phytec.de \ --cc=afd@ti.com \ --cc=arnd@arndb.de \ --cc=biju.das.jz@bp.renesas.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=dmitry.torokhov@gmail.com \ --cc=geert+renesas@glider.be \ --cc=j-keerthy@ti.com \ --cc=jeff@labundy.com \ --cc=jneanne@baylibre.com \ --cc=khilman@baylibre.com \ --cc=kristo@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=lee@kernel.org \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=marcel.ziswiler@toradex.com \ --cc=msp@baylibre.com \ --cc=narmstrong@baylibre.com \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ --cc=tony@atomide.com \ --cc=vigneshr@ti.com \ --cc=vkoul@kernel.org \ --cc=will@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.