| Message ID | 1340406842-27135-3-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hi Stephen, On Friday 22 June 2012 17:14:02 Stephen Warren wrote: > From: Stephen Warren <swarren@nvidia.com> > > The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. > > The regulator configurations were all taken from the AC100 kernel used by > the Ubuntu port, specifically: > > git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git > chromeos-ac100-3.0-exp > > Cc: Marc Dietrich <marvin24@gmx.de> > Signed-off-by: Stephen Warren <swarren@nvidia.com> > --- > arch/arm/boot/dts/tegra20-paz00.dts | 138 > +++++++++++++++++++++++++++++++++++ 1 files changed, 138 insertions(+), 0 > deletions(-) > > diff --git a/arch/arm/boot/dts/tegra20-paz00.dts > b/arch/arm/boot/dts/tegra20-paz00.dts index 684a9e1..55ca34c 100644 > --- a/arch/arm/boot/dts/tegra20-paz00.dts > +++ b/arch/arm/boot/dts/tegra20-paz00.dts > @@ -272,12 +272,150 @@ > status = "okay"; > clock-frequency = <400000>; > > + pmic: tps6586x@34 { > + compatible = "ti,tps6586x"; > + reg = <0x34>; > + interrupts = <0 86 0x4>; > + > + #gpio-cells = <2>; > + gpio-controller; > + > + regulators { > + #address-cells = <1>; > + #size-cells = <0>; > + > + regulator@0 { > + reg = <0>; > + regulator-compatible = "sm0"; > + regulator-name = "+1.2vs_sm0"; > + regulator-min-microvolt = < 725000>; > + regulator-max-microvolt = <1300000>; > + regulator-always-on; > + }; > + > + regulator@1 { > + reg = <1>; > + regulator-compatible = "sm1"; > + regulator-name = "+1.0vs_sm1"; > + regulator-min-microvolt = < 725000>; > + regulator-max-microvolt = <1125000>; > + regulator-always-on; > + }; > + > + sm2_reg: regulator@2 { > + reg = <2>; > + regulator-compatible = "sm2"; > + regulator-name = "+3.7vs_sm2"; > + regulator-min-microvolt = <3000000>; > + regulator-max-microvolt = <3700000>; > + regulator-always-on; > + }; > + > + regulator@3 { > + reg = <3>; > + regulator-compatible = "ldo0"; > + regulator-name = "+3.3vs_ldo0"; > + regulator-min-microvolt = <1250000>; I think the common sense was that this should also be 3.3 V as it is the pex clock (which is not used at all on this board). I guess it doesn't matter much. So ... Acked-By: Marc Dietrich <marvin24@gmx.de> > + regulator-max-microvolt = <3300000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@4 { > + reg = <4>; > + regulator-compatible = "ldo1"; > + regulator-name = "+1.1vs_ldo1"; > + regulator-min-microvolt = < 725000>; > + regulator-max-microvolt = <1100000>; > + regulator-always-on; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@5 { > + reg = <5>; > + regulator-compatible = "ldo2"; > + regulator-name = "+1.2vs_ldo2"; > + regulator-min-microvolt = < 725000>; > + regulator-max-microvolt = <1275000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@6 { > + reg = <6>; > + regulator-compatible = "ldo3"; > + regulator-name = "+3.3vs_ldo3"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <3300000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@7 { > + reg = <7>; > + regulator-compatible = "ldo4"; > + regulator-name = "+1.8vs_ldo4"; > + regulator-min-microvolt = <1700000>; > + regulator-max-microvolt = <1800000>; > + regulator-always-on; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@8 { > + reg = <8>; > + regulator-compatible = "ldo5"; > + regulator-name = "+2.85vs_ldo5"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <2850000>; > + regulator-always-on; > + }; > + > + regulator@9 { > + reg = <9>; > + regulator-compatible = "ldo6"; > + regulator-name = "+2.85vs_ldo6"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <2850000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@10 { > + reg = <10>; > + regulator-compatible = "ldo7"; > + regulator-name = "+3.3vs_ldo7"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <3300000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@11 { > + reg = <11>; > + regulator-compatible = "ldo8"; > + regulator-name = "+1.8vs_ldo8"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <1800000>; > + vin-supply = <&sm2_reg>; > + }; > + > + regulator@12 { > + reg = <12>; > + regulator-compatible = "ldo9"; > + regulator-name = "+2.85vs_ldo9"; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <2850000>; > + regulator-always-on; > + vin-supply = <&sm2_reg>; > + }; > + }; > + }; > + > adt7461@4c { > compatible = "adi,adt7461"; > reg = <0x4c>; > }; > }; > > + pmc { > + nvidia,invert-interrupt; > + }; > + > usb@c5000000 { > status = "okay"; > }; -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jun 23, 2012 at 06:35:01PM +0200, Marc Dietrich wrote: > > The regulator configurations were all taken from the AC100 kernel used by > > the Ubuntu port, specifically: These generally all look pretty broken... > > + regulator@0 { > > + reg = <0>; > > + regulator-compatible = "sm0"; > > + regulator-name = "+1.2vs_sm0"; > > + regulator-min-microvolt = < 725000>; > > + regulator-max-microvolt = <1300000>; Most of these ranges look suspiciously like the maximum possible variation the regulator has, not what the board actually requires (which is a depressingly common error, I've no idea why people seem to think they're supposed to cut'n'paste the physical limits of the regualtor out of the driver). If something decides to take advantage of the variation this could be problematic. > > + regulator@3 { > > + reg = <3>; > > + regulator-compatible = "ldo0"; > > + regulator-name = "+3.3vs_ldo0"; > > + regulator-min-microvolt = <1250000>; > I think the common sense was that this should also be 3.3 V as it is the pex > clock (which is not used at all on this board). I guess it doesn't matter > much. So ... > Acked-By: Marc Dietrich <marvin24@gmx.de> > > + regulator-max-microvolt = <3300000>; This is one example, it looks like the rail needs to be fixed to 3.3V. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sunday 24 June 2012 12:03:06 Mark Brown wrote: > On Sat, Jun 23, 2012 at 06:35:01PM +0200, Marc Dietrich wrote: > > > The regulator configurations were all taken from the AC100 kernel used > > > by > > > > the Ubuntu port, specifically: > These generally all look pretty broken... > > > > + regulator@0 { > > > + reg = <0>; > > > + regulator-compatible = "sm0"; > > > + regulator-name = "+1.2vs_sm0"; > > > + regulator-min-microvolt = < 725000>; > > > + regulator-max-microvolt = <1300000>; > > Most of these ranges look suspiciously like the maximum possible > variation the regulator has, not what the board actually requires (which > is a depressingly common error, I've no idea why people seem to think > they're supposed to cut'n'paste the physical limits of the regualtor out > of the driver). If something decides to take advantage of the variation > this could be problematic. AFAIR we saw some instabilities with 1.2 V here, but looking back, that could also be related to something else. Finding these "undervolt" bugs is really hard to do. I indeed just copied the values from the original source ( http://gitorious.org/ac100/kernel/blobs/2.6.32/arch/arm/mach- tegra/odm_kit/adaptations/pmu/tps6586x/nvodm_pmu_tps6586x.c#line136 ) and bumped up sm0 by 100 mV for the said stabilty reasons. According to the datasheet, sm0 can go up to 1.5 V if I read it correctly, so 1.3 V is still inside the spec and not the maximum the regulator can provide. > > > > + regulator@3 { > > > + reg = <3>; > > > + regulator-compatible = "ldo0"; > > > + regulator-name = "+3.3vs_ldo0"; > > > + regulator-min-microvolt = <1250000>; > > > > I think the common sense was that this should also be 3.3 V as it is the > > pex clock (which is not used at all on this board). I guess it doesn't > > matter much. So ... > > > > Acked-By: Marc Dietrich <marvin24@gmx.de> > > > > > + regulator-max-microvolt = <3300000>; > > This is one example, it looks like the rail needs to be fixed to 3.3V. I think nowhere in the code a regulator (beside sm*) is programmed to some different value that the maximum given here (this is not the maximum the regulator can provide). I never understood why the kernel code always sets the regulator to the maximum value if no other value was specified. IMHO, there should be some initial value, e.g. regulator-default-microvolt, as the original driver (from 2.6.32 ages) did. This way the maximum value can be set to the hw limits, but maybe this is a bit dangerous. Marc -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 24, 2012 at 02:01:58PM +0200, Marc Dietrich wrote: > On Sunday 24 June 2012 12:03:06 Mark Brown wrote: > > > > + regulator-name = "+3.3vs_ldo0"; > > > > + regulator-max-microvolt = <3300000>; > > This is one example, it looks like the rail needs to be fixed to 3.3V. > I think nowhere in the code a regulator (beside sm*) is programmed to some > different value that the maximum given here (this is not the maximum the > regulator can provide). I never understood why the kernel code always sets the > regulator to the maximum value if no other value was specified. IMHO, there > should be some initial value, e.g. regulator-default-microvolt, as the > original driver (from 2.6.32 ages) did. This way the maximum value can be set That's *never* been in mainline, and nobody even bothered trying to submit it. > to the hw limits, but maybe this is a bit dangerous. One of two things should be happening. Either a single voltage is specified (in which case that voltage will be configured in the hardware and consumer drivers can't change anything) or a voltage range is specified (in which case the consumers are expected to manage the voltage and the most the API should do is bring the voltage within the limits given, though I don't think that's actually implemented yet). Specifying an initial value within the range should at best be redundant as the drivers that are actively managing their voltages will be overriding it anyway. We certainly shouldn't be specifying the limits of the regulator itself as normally the board design will be much more constrained than the regulator itself and like I said it's stupid to have to cut'n'paste the numbers out of the driver into the machine constraints. We should instead be specifying the constraints the system is designed to operate in. Chances are that if nothing is able to actively manage the voltage it's not in fact safe to change the voltage at all and therefore the constraints should specify only one voltage. In the above case the fact that the supply is named "+3.3vs_ldo0" seems like a fairly clear sign that the board has been designed for this to operate at 3.3V which makes the fact that the constraints go down to 1.25V seem at best odd.
On Sunday 24 June 2012 13:31:51 Mark Brown wrote: > On Sun, Jun 24, 2012 at 02:01:58PM +0200, Marc Dietrich wrote: > > On Sunday 24 June 2012 12:03:06 Mark Brown wrote: > > > > > + regulator-name = "+3.3vs_ldo0"; > > > > > + regulator-max-microvolt = <3300000>; > > > > > > This is one example, it looks like the rail needs to be fixed to 3.3V. > > > > I think nowhere in the code a regulator (beside sm*) is programmed to some > > different value that the maximum given here (this is not the maximum the > > regulator can provide). I never understood why the kernel code always sets > > the regulator to the maximum value if no other value was specified. IMHO, > > there should be some initial value, e.g. regulator-default-microvolt, as > > the original driver (from 2.6.32 ages) did. This way the maximum value > > can be set > That's *never* been in mainline, and nobody even bothered trying to > submit it. which was the best thing to do ;-) > > to the hw limits, but maybe this is a bit dangerous. > > One of two things should be happening. Either a single voltage is > specified (in which case that voltage will be configured in the I'm not an expert on this, but it seems to me that only sm0 and sm1 should be changeable (and some rail called vdd_aon, which seems to be ldo2 in case of paz00 connected to the rtc). So, all others can be constant voltage. Maybe Stephen can comment on the actual requirements (also for the other boards which may have similar layout). Marc > hardware and consumer drivers can't change anything) or a voltage range > is specified (in which case the consumers are expected to manage the > voltage and the most the API should do is bring the voltage within the > limits given, though I don't think that's actually implemented yet). > Specifying an initial value within the range should at best be redundant > as the drivers that are actively managing their voltages will be > overriding it anyway. > > We certainly shouldn't be specifying the limits of the regulator itself > as normally the board design will be much more constrained than the > regulator itself and like I said it's stupid to have to cut'n'paste the > numbers out of the driver into the machine constraints. We should > instead be specifying the constraints the system is designed to operate > in. Chances are that if nothing is able to actively manage the voltage > it's not in fact safe to change the voltage at all and therefore the > constraints should specify only one voltage. > > In the above case the fact that the supply is named "+3.3vs_ldo0" seems > like a fairly clear sign that the board has been designed for this to > operate at 3.3V which makes the fact that the constraints go down to > 1.25V seem at best odd. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 24, 2012 at 03:27:42PM +0200, Marc Dietrich wrote: > On Sunday 24 June 2012 13:31:51 Mark Brown wrote: > > > there should be some initial value, e.g. regulator-default-microvolt, as > > > the original driver (from 2.6.32 ages) did. This way the maximum value > > > can be set > > That's *never* been in mainline, and nobody even bothered trying to > > submit it. > which was the best thing to do ;-) Well, no - had there been some attempt to submit it it might've helped stop people writing constaints like this.
Am Montag, 25. Juni 2012, 09:46:56 schrieb Mark Brown: > On Sun, Jun 24, 2012 at 03:27:42PM +0200, Marc Dietrich wrote: > > On Sunday 24 June 2012 13:31:51 Mark Brown wrote: > > > > there should be some initial value, e.g. regulator-default-microvolt, > > > > as > > > > the original driver (from 2.6.32 ages) did. This way the maximum value > > > > can be set > > > > > > That's *never* been in mainline, and nobody even bothered trying to > > > submit it. > > > > which was the best thing to do ;-) > > Well, no - had there been some attempt to submit it it might've helped > stop people writing constaints like this. by saying "best thing to do" I meant that the driver isn't mainline compatible as it is based on some cross OS HAL. On the other hand, I think the current tps6586x could be enhanced to include such a field. I don't know if the regulator api supports this, though. Marc -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jun 24, 2012 at 03:27:42PM +0200, Marc Dietrich wrote: > On Sunday 24 June 2012 13:31:51 Mark Brown wrote: > > On Sun, Jun 24, 2012 at 02:01:58PM +0200, Marc Dietrich wrote: > > > On Sunday 24 June 2012 12:03:06 Mark Brown wrote: > > > > > > + regulator-name = "+3.3vs_ldo0"; > > > > > > + regulator-max-microvolt = <3300000>; > > > > > > > > This is one example, it looks like the rail needs to be fixed to 3.3V. > > > > > > I think nowhere in the code a regulator (beside sm*) is programmed to some > > > different value that the maximum given here (this is not the maximum the > > > regulator can provide). I never understood why the kernel code always sets > > > the regulator to the maximum value if no other value was specified. IMHO, > > > there should be some initial value, e.g. regulator-default-microvolt, as > > > the original driver (from 2.6.32 ages) did. This way the maximum value > > > can be set > > That's *never* been in mainline, and nobody even bothered trying to > > submit it. > > which was the best thing to do ;-) > > > > to the hw limits, but maybe this is a bit dangerous. > > > > One of two things should be happening. Either a single voltage is > > specified (in which case that voltage will be configured in the > > I'm not an expert on this, but it seems to me that only sm0 and sm1 should be > changeable (and some rail called vdd_aon, which seems to be ldo2 in case of > paz00 connected to the rtc). So, all others can be constant voltage. Maybe > Stephen can comment on the actual requirements (also for the other boards > which may have similar layout). I can confirm that at least for ldo0 the value needs to be fixed. I did in fact post a patch back in February that was needed to fix PCIe on Harmony. I also sat down with one of our hardware engineers and worked through the list and wrote down the requirements for Harmony. I need to check where our notes have gone, though. Thierry
On 06/24/2012 05:03 AM, Mark Brown wrote: > On Sat, Jun 23, 2012 at 06:35:01PM +0200, Marc Dietrich wrote: > >>> The regulator configurations were all taken from the AC100 kernel used by >>> the Ubuntu port, specifically: > > These generally all look pretty broken... > >>> + regulator@0 { >>> + reg = <0>; >>> + regulator-compatible = "sm0"; >>> + regulator-name = "+1.2vs_sm0"; >>> + regulator-min-microvolt = < 725000>; >>> + regulator-max-microvolt = <1300000>; > > Most of these ranges look suspiciously like the maximum possible > variation the regulator has, not what the board actually requires (which > is a depressingly common error, I've no idea why people seem to think > they're supposed to cut'n'paste the physical limits of the regualtor out > of the driver). If something decides to take advantage of the variation > this could be problematic. So I think this sm0 (and the sm1) entry might actually be correct; sm0 feeds vdd_core and sm1 feeds vdd_cpu. These rails have DVFS and hence the voltage can vary. I guess I should change the regulator-name in these cases to something more useful than the very first signal name on the schematics too. That said, we don't actually have DVFS in the mainline kernel yet, and correlating the regulator limits in our downstream kernels against the DVFS tables we use is ... challenging; I'm not sure they're consistent anyway:-( However, it probably doesn't make sense to vary sm2, since all that is used for is to feed the TPS6586x's input pins for the the LDO regulators. Likewise, all the LDO regulators are used for various peripherals in general, and in the main it probably makes no sense for those rails to vary. So, what I think I'll do for any regulators where the downstream board files specify a voltage range, is boot the kernel and find out what voltage is selected by default, and program both min-/max-microvolt to that specific value. That way, there will be no behaviour change. We can expand the ranges on the regulators later if/when we add DVFS etc. Does that sound like a reasonable approach? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 26, 2012 at 04:35:46PM -0600, Stephen Warren wrote: > So I think this sm0 (and the sm1) entry might actually be correct; sm0 > feeds vdd_core and sm1 feeds vdd_cpu. These rails have DVFS and hence > the voltage can vary. I guess I should change the regulator-name in > these cases to something more useful than the very first signal name on > the schematics too. Even if they feed these supplies are they capable of varying on this board if they're shared with other things? This is one of the common issues with constraints... But generally if the supply covers more than one thing the idiomatic thing is to list them all separated by / or something. > That said, we don't actually have DVFS in the mainline kernel yet, and > correlating the regulator limits in our downstream kernels against the > DVFS tables we use is ... challenging; I'm not sure they're consistent > anyway:-( Well, if you're using the regulator API the regulator API limits will win if they're more constrained. But this is half the problem with these silly constraints that just copy the regulator limits, you've no idea what the board is actually supposed to do. > However, it probably doesn't make sense to vary sm2, since all that is > used for is to feed the TPS6586x's input pins for the the LDO regulators. Actually if we get clever then there's some fun to be had there. If we can have all the LDOs specify the headroom they need then we should be able to arrange to vary the DCDC depending on what the needs of the currently active LDOs are which would improve power efficiency as the goal here is to drop the voltage as much as possible using the more efficient DCDC then regulate on from there with the LDOs. I keep considering doing this but don't have any real need for it myself, it's just amusing. Might fall out of (or be similar to) some work I'm going to be doing soon for bypass modes though. > Likewise, all the LDO regulators are used for various peripherals in > general, and in the main it probably makes no sense for those rails to vary. This is typically very unusual, the devices on the rails are normally heavily constrained when active. > So, what I think I'll do for any regulators where the downstream board > files specify a voltage range, is boot the kernel and find out what > voltage is selected by default, and program both min-/max-microvolt to > that specific value. That way, there will be no behaviour change. We can > expand the ranges on the regulators later if/when we add DVFS etc. Does > that sound like a reasonable approach? Yes.
On 06/26/2012 05:02 PM, Mark Brown wrote: > On Tue, Jun 26, 2012 at 04:35:46PM -0600, Stephen Warren wrote: > >> So I think this sm0 (and the sm1) entry might actually be >> correct; sm0 feeds vdd_core and sm1 feeds vdd_cpu. These rails >> have DVFS and hence the voltage can vary. I guess I should change >> the regulator-name in these cases to something more useful than >> the very first signal name on the schematics too. > > Even if they feed these supplies are they capable of varying on > this board if they're shared with other things? This is one of the > common issues with constraints... But generally if the supply > covers more than one thing the idiomatic thing is to list them all > separated by / or something. These two supplies aren't shared, it's just that the signal on the schematic ends up being named different things in different places; on the regulator page it's named vdd_sm0, but on some other page it gets renamed vdd_core. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/26/2012 05:02 PM, Mark Brown wrote: > On Tue, Jun 26, 2012 at 04:35:46PM -0600, Stephen Warren wrote: > >> So I think this sm0 (and the sm1) entry might actually be >> correct; sm0 feeds vdd_core and sm1 feeds vdd_cpu. These rails >> have DVFS and hence the voltage can vary. I guess I should change >> the regulator-name in these cases to something more useful than >> the very first signal name on the schematics too. > > Even if they feed these supplies are they capable of varying on > this board if they're shared with other things? This is one of the > common issues with constraints... But generally if the supply > covers more than one thing the idiomatic thing is to list them all > separated by / or something. Just FYI, the particular choice of "/" as a separator doesn't work well, because then /sys/kernel/debug/regulator/${regulator-name} can't be created. I guess I'll use a comma. I assume it's not worth fixing the regulator core to s@/@,@ when generating the debugfs filenames? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 29, 2012 at 11:32:30AM -0600, Stephen Warren wrote: > Just FYI, the particular choice of "/" as a separator doesn't work > well, because then /sys/kernel/debug/regulator/${regulator-name} can't > be created. I guess I'll use a comma. I assume it's not worth fixing > the regulator core to s@/@,@ when generating the debugfs filenames? I don't think that's sensible, no.
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts index 684a9e1..55ca34c 100644 --- a/arch/arm/boot/dts/tegra20-paz00.dts +++ b/arch/arm/boot/dts/tegra20-paz00.dts @@ -272,12 +272,150 @@ status = "okay"; clock-frequency = <400000>; + pmic: tps6586x@34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + interrupts = <0 86 0x4>; + + #gpio-cells = <2>; + gpio-controller; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + regulator@0 { + reg = <0>; + regulator-compatible = "sm0"; + regulator-name = "+1.2vs_sm0"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + }; + + regulator@1 { + reg = <1>; + regulator-compatible = "sm1"; + regulator-name = "+1.0vs_sm1"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1125000>; + regulator-always-on; + }; + + sm2_reg: regulator@2 { + reg = <2>; + regulator-compatible = "sm2"; + regulator-name = "+3.7vs_sm2"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3700000>; + regulator-always-on; + }; + + regulator@3 { + reg = <3>; + regulator-compatible = "ldo0"; + regulator-name = "+3.3vs_ldo0"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@4 { + reg = <4>; + regulator-compatible = "ldo1"; + regulator-name = "+1.1vs_ldo1"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + + regulator@5 { + reg = <5>; + regulator-compatible = "ldo2"; + regulator-name = "+1.2vs_ldo2"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1275000>; + vin-supply = <&sm2_reg>; + }; + + regulator@6 { + reg = <6>; + regulator-compatible = "ldo3"; + regulator-name = "+3.3vs_ldo3"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@7 { + reg = <7>; + regulator-compatible = "ldo4"; + regulator-name = "+1.8vs_ldo4"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + + regulator@8 { + reg = <8>; + regulator-compatible = "ldo5"; + regulator-name = "+2.85vs_ldo5"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + }; + + regulator@9 { + reg = <9>; + regulator-compatible = "ldo6"; + regulator-name = "+2.85vs_ldo6"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <2850000>; + vin-supply = <&sm2_reg>; + }; + + regulator@10 { + reg = <10>; + regulator-compatible = "ldo7"; + regulator-name = "+3.3vs_ldo7"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@11 { + reg = <11>; + regulator-compatible = "ldo8"; + regulator-name = "+1.8vs_ldo8"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&sm2_reg>; + }; + + regulator@12 { + reg = <12>; + regulator-compatible = "ldo9"; + regulator-name = "+2.85vs_ldo9"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + }; + }; + adt7461@4c { compatible = "adi,adt7461"; reg = <0x4c>; }; }; + pmc { + nvidia,invert-interrupt; + }; + usb@c5000000 { status = "okay"; };