| Message ID | cover.50931fbda5c95345087740e4c1ef5a57fdd53480.1544104801.git-series.maxime.ripard@bootlin.com |
|---|---|
| Headers | show |
| Series | pinctrl: sunxi: Account for per-bank GPIO regulators | expand |
On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > Hi, > > Here is a first attempt at getting the regulators properly accounted for > the GPIO banks on the Allwinner SoCs. Cool. This is better than what I had in mind, which involved a deferred task to grab the regulators. > The main interogation I have currently is whether we should always try to > get the regulator for the current branch, or if we should restrict it to > the one available on the SoCs. Not sure what you mean here, but we should probably just list the actual names. For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead they are named after the primary function of the pin bank, such as VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1. For pin banks that don't have per-bank power inputs, you should fall back to VCC-IO, or VCC-RTC in the case of the PL pins. So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets registered when the PMIC regulator driver is probed, which needs the RSB controller, which needs the pin controller and the PL pins... ChenYu > > Let me know what you think, > Maxime > > Maxime Ripard (2): > pinctrl: sunxi: Deal with per-bank regulators > ARM: dts: sun7i: bananapi: Add GPIO banks regulators > > arch/arm/boot/dts/sun7i-a20-bananapi.dts | 5 ++- > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 63 +++++++++++++++++++++++++- > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 6 ++- > 3 files changed, 74 insertions(+) > > base-commit: 651022382c7f8da46cb4872a545ee1da6d097d2a > -- > git-series 0.9.1
Hi, On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote: > On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > The main interogation I have currently is whether we should always try to > > get the regulator for the current branch, or if we should restrict it to > > the one available on the SoCs. > > Not sure what you mean here, but we should probably just list the actual > names. The A20 for example doesn't have a VCC-PB regulator, so do we want to try to grab it if we request a PB* pin, or should we just know that somehow and not do it? > For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead > they are named after the primary function of the pin bank, such as > VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1. I'd really prefer to stick to vcc-pX, that's pretty obvious even for those older SoCs, and we can maintain some consistency that way. > For pin banks that don't have per-bank power inputs, you should fall back > to VCC-IO, or VCC-RTC in the case of the PL pins. > > So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL > or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets > registered when the PMIC regulator driver is probed, which needs the RSB > controller, which needs the pin controller and the PL pins... I haven't seen any VCC-P* on the A33, do you have a reference? Thanks! Maxime
On Thu, Dec 6, 2018 at 11:47 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > Hi, > > On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote: > > On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > The main interogation I have currently is whether we should always try to > > > get the regulator for the current branch, or if we should restrict it to > > > the one available on the SoCs. > > > > Not sure what you mean here, but we should probably just list the actual > > names. > > The A20 for example doesn't have a VCC-PB regulator, so do we want to > try to grab it if we request a PB* pin, or should we just know that > somehow and not do it? AFAIK, pin banks that don't have a separate supply are powered collectively by VCC-IO, as mentioned below in my previous reply. > > For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead > > they are named after the primary function of the pin bank, such as > > VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1. > > I'd really prefer to stick to vcc-pX, that's pretty obvious even for > those older SoCs, and we can maintain some consistency that way. IRRC Mark said that supply names should match design names, not what is convenient. And then again there's the fallback for those that don't have separate rails. > > For pin banks that don't have per-bank power inputs, you should fall back > > to VCC-IO, or VCC-RTC in the case of the PL pins. > > > > So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL > > or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets > > registered when the PMIC regulator driver is probed, which needs the RSB > > controller, which needs the pin controller and the PL pins... > > I haven't seen any VCC-P* on the A33, do you have a reference? The A33 has a VCC-PD. This is not listed in the datasheet, but is shown in schematics. Other pins would be powered by VCC-IO, with the exception of PL, which would be power by VCC-RTC. The last bit is just a guess. We should probably ask Allwinner, or try to do some tests. ChenYu
Hi! On Fri, Dec 07, 2018 at 12:01:18AM +0800, Chen-Yu Tsai wrote: > On Thu, Dec 6, 2018 at 11:47 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Thu, Dec 06, 2018 at 11:28:21PM +0800, Chen-Yu Tsai wrote: > > > On Thu, Dec 6, 2018 at 10:02 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > > > The main interogation I have currently is whether we should always try to > > > > get the regulator for the current branch, or if we should restrict it to > > > > the one available on the SoCs. > > > > > > Not sure what you mean here, but we should probably just list the actual > > > names. > > > > The A20 for example doesn't have a VCC-PB regulator, so do we want to > > try to grab it if we request a PB* pin, or should we just know that > > somehow and not do it? > > AFAIK, pin banks that don't have a separate supply are powered collectively > by VCC-IO, as mentioned below in my previous reply. Sigh, it was too easy :) Is VCC-IO supposed to be used for something else in the SoCs (and therefore could be ignored?) or not? Otherwise, we could have some hack where if the regulator is missing, or if it's marked always-on, we just skip it, and if it isn't we emit a warning. It should cover most cases, while keeping the code quite simple. > > > For pre-A20 SoCs (A10/A10s/A13), they aren't even named VCC-Px. Instead > > > they are named after the primary function of the pin bank, such as > > > VCC-CARD, VCC-NAND, VCC-CSI0, VCC-CSI1. > > > > I'd really prefer to stick to vcc-pX, that's pretty obvious even for > > those older SoCs, and we can maintain some consistency that way. > > IRRC Mark said that supply names should match design names, not what is > convenient. And then again there's the fallback for those that don't have > separate rails. That would require to complicate the logic a bit, to have something less obvious. I'd really like to avoid it if possible. > > > For pin banks that don't have per-bank power inputs, you should fall back > > > to VCC-IO, or VCC-RTC in the case of the PL pins. > > > > > > So here's the rub: On A33 and later SoCs that are paired with a PMIC, VCC-PL > > > or VCC-RTC is powered by the RTC regulator of the PMIC, which only gets > > > registered when the PMIC regulator driver is probed, which needs the RSB > > > controller, which needs the pin controller and the PL pins... > > > > I haven't seen any VCC-P* on the A33, do you have a reference? > > The A33 has a VCC-PD. This is not listed in the datasheet, but is shown in > schematics. Other pins would be powered by VCC-IO, with the exception of PL, > which would be power by VCC-RTC. The last bit is just a guess. We should > probably ask Allwinner, or try to do some tests. Ack. Maxime