| Message ID | 1340406842-27135-1-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Saturday 23 June 2012 04:44 AM, Stephen Warren wrote: > From: Stephen Warren<swarren@nvidia.com> > > Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a > couple of fixed GPIO-controlled regulators too. > > The regulator configurations were mostly taken from the ChromeOS 3.2 > kernel. Exceptions are: > > * The schematic lists a fixed voltage for each rail, whereas the ChromeOS > kernel lists a range for many rails. I used the values from the ChromeOS > kernel in all cases, since I know the board file there is the most > complete available for this hardware. > > * The vdd_1v2 fixed regulator is present only in the schematic. So, I added > this based on the schematic. > > * A 3.3v fixed regulator using GPIO3 of the TPS6586x is present in the > ChromeOS kernel, but not in the schematic. So, I dropped this based on > the schematic. > > Signed-off-by: Stephen Warren<swarren@nvidia.com> > --- Acked-by: Laxman Dewangan <ldewangan@nvidia.com> I think this series very much depends on the series [PATCH V3 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible" > + regulator@3 { > + reg =<3>; > + regulator-compatible = "ldo0"; > + regulator-name = "vdd_ldo0"; > + regulator-min-microvolt =<1250000>; > + regulator-max-microvolt =<3300000>; > + vin-supply =<&sm2_reg>; I think support for vin-supply is still not there for this regulator in driver. -- 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/25/2012 12:24 AM, Laxman Dewangan wrote: > On Saturday 23 June 2012 04:44 AM, Stephen Warren wrote: >> From: Stephen Warren<swarren@nvidia.com> >> >> Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a >> couple of fixed GPIO-controlled regulators too. >> >> The regulator configurations were mostly taken from the ChromeOS 3.2 >> kernel. Exceptions are: >> >> * The schematic lists a fixed voltage for each rail, whereas the ChromeOS >> kernel lists a range for many rails. I used the values from the >> ChromeOS >> kernel in all cases, since I know the board file there is the most >> complete available for this hardware. >> >> * The vdd_1v2 fixed regulator is present only in the schematic. So, I >> added >> this based on the schematic. >> >> * A 3.3v fixed regulator using GPIO3 of the TPS6586x is present in the >> ChromeOS kernel, but not in the schematic. So, I dropped this based on >> the schematic. >> >> Signed-off-by: Stephen Warren<swarren@nvidia.com> >> --- > > Acked-by: Laxman Dewangan <ldewangan@nvidia.com> > > I think this series very much depends on the series > [PATCH V3 0/3] regulator: dt: add policy to match regulator with prop > "regulator-compatible" That's certainly true. However, it's a runtime dependency to enable a new feature, and shouldn't cause any breakage without that patch, so we don't need to be explicit about the dependency in git. >> + regulator@3 { >> + reg =<3>; >> + regulator-compatible = "ldo0"; >> + regulator-name = "vdd_ldo0"; >> + regulator-min-microvolt =<1250000>; >> + regulator-max-microvolt =<3300000>; >> + vin-supply =<&sm2_reg>; > > I think support for vin-supply is still not there for this regulator in > driver. That's also true. I wonder if we shouldn't support this in the regulator core bindings instead, since the existence of a parent regulator seems likely to be common. Either way, I'd like to include the property to document it for now. -- 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 Monday 25 June 2012 08:42 PM, Stephen Warren wrote: > On 06/25/2012 12:24 AM, Laxman Dewangan wrote: >> On Saturday 23 June 2012 04:44 AM, Stephen Warren wrote: >>> From: Stephen Warren<swarren@nvidia.com> >>> >>> Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a >>> couple of fixed GPIO-controlled regulators too. >>> >>> >>> Signed-off-by: Stephen Warren<swarren@nvidia.com> >>> --- >> Acked-by: Laxman Dewangan<ldewangan@nvidia.com> >> >> I think this series very much depends on the series >> [PATCH V3 0/3] regulator: dt: add policy to match regulator with prop >> "regulator-compatible" > That's certainly true. However, it's a runtime dependency to enable a > new feature, and shouldn't cause any breakage without that patch, so we > don't need to be explicit about the dependency in git. > Here, wanted to say that although we enable it but it will not work. The functionality depends on the above patch. >>> + regulator@3 { >>> + reg =<3>; >>> + regulator-compatible = "ldo0"; >>> + regulator-name = "vdd_ldo0"; >>> + regulator-min-microvolt =<1250000>; >>> + regulator-max-microvolt =<3300000>; >>> + vin-supply =<&sm2_reg>; >> I think support for vin-supply is still not there for this regulator in >> driver. > That's also true. I wonder if we shouldn't support this in the regulator > core bindings instead, since the existence of a parent regulator seems > likely to be common. Either way, I'd like to include the property to > document it for now. I had detailed discussion with Mark on this support and as per him (based on my understanding), the input to different regulator is from the pin of the chips and so the name should be the <pin-name>-supply which should be part of chip-dt binding, not to the particular rail. -- 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/25/2012 09:24 AM, Laxman Dewangan wrote: > On Monday 25 June 2012 08:42 PM, Stephen Warren wrote: >> On 06/25/2012 12:24 AM, Laxman Dewangan wrote: >>> On Saturday 23 June 2012 04:44 AM, Stephen Warren wrote: >>>> From: Stephen Warren<swarren@nvidia.com> >>>> >>>> Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a >>>> couple of fixed GPIO-controlled regulators too. ... >>>> + regulator@3 { >>>> + reg =<3>; >>>> + regulator-compatible = "ldo0"; >>>> + regulator-name = "vdd_ldo0"; >>>> + regulator-min-microvolt =<1250000>; >>>> + regulator-max-microvolt =<3300000>; >>>> + vin-supply =<&sm2_reg>; >>> I think support for vin-supply is still not there for this regulator in >>> driver. >> That's also true. I wonder if we shouldn't support this in the regulator >> core bindings instead, since the existence of a parent regulator seems >> likely to be common. Either way, I'd like to include the property to >> document it for now. > > I had detailed discussion with Mark on this support and as per him > (based on my understanding), the input to different regulator is from > the pin of the chips and so the name should be the <pin-name>-supply > which should be part of chip-dt binding, not to the particular rail. OK, that's fine. Can you please update the TPS6586x binding and driver to allow this to be represented correctly then. Thanks. -- 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 Mon, Jun 25, 2012 at 08:54:21PM +0530, Laxman Dewangan wrote: > I had detailed discussion with Mark on this support and as per him > (based on my understanding), the input to different regulator is > from the pin of the chips and so the name should be the > <pin-name>-supply which should be part of chip-dt binding, not to > the particular rail. More specifically, all the supplies for a device (including those that happen to be inputs for regulators) should be specified in exactly the same fashion. This makes the binding more regular and means that users can just go through the schematic adding the mappings without worrying about what what the supply happens to be.
On 06/25/2012 04:26 PM, Mark Brown wrote: > On Mon, Jun 25, 2012 at 08:54:21PM +0530, Laxman Dewangan wrote: > >> I had detailed discussion with Mark on this support and as per >> him (based on my understanding), the input to different regulator >> is from the pin of the chips and so the name should be the >> <pin-name>-supply which should be part of chip-dt binding, not >> to the particular rail. > > More specifically, all the supplies for a device (including those > that happen to be inputs for regulators) should be specified in > exactly the same fashion. This makes the binding more regular and > means that users can just go through the schematic adding the > mappings without worrying about what what the supply happens to > be. Just making sure I parsed that right. I think what you're saying is that the device itself should represent its input pins, e.g.: tps6586x { vin-ldo01-supply = <&some_regulator>; vin-ldo23-supply = <...>; vin-ldo4-supply = <...>; vin-ldo678-supply = <...>; vin-ldo9-supply = <...>; regulators { regulator@0 { regulator-compatible = "ldo0"; ... }; regulator@1 { regulator-compatible = "ldo1"; ... }; }; }; (and then the driver internally uses the *-supply to set up the parents of each of its own regulators) ... rather than each regulator specifying its parent, which might result in some duplication, since in this case both ldo0/1 are supplied from the same input pin: tps6586x { regulators { regulator@0 { regulator-compatible = "ldo0"; vin-supply = <&some_regulator>; ... }; regulator@1 { regulator-compatible = "ldo1"; vin-supply = <&some_regulator>; ... }; }; }; -- 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 Tuesday 26 June 2012 04:39 AM, Stephen Warren wrote: > On 06/25/2012 04:26 PM, Mark Brown wrote: >> On Mon, Jun 25, 2012 at 08:54:21PM +0530, Laxman Dewangan wrote: >> >>> I had detailed discussion with Mark on this support and as per >>> him (based on my understanding), the input to different regulator >>> is from the pin of the chips and so the name should be the >>> <pin-name>-supply which should be part of chip-dt binding, not >>> to the particular rail. >> More specifically, all the supplies for a device (including those >> that happen to be inputs for regulators) should be specified in >> exactly the same fashion. This makes the binding more regular and >> means that users can just go through the schematic adding the >> mappings without worrying about what what the supply happens to >> be. > Just making sure I parsed that right. I think what you're saying is > that the device itself should represent its input pins, e.g.: > > tps6586x { > vin-ldo01-supply =<&some_regulator>; I think it is fine. The pin name as per data sheet is VINLDO01 and so we can have vin-ldo01. > vin-ldo23-supply =<...>; > vin-ldo4-supply =<...>; > vin-ldo678-supply =<...>; > vin-ldo9-supply =<...>; > > regulators { > regulator@0 { > regulator-compatible = "ldo0"; > ... > }; > regulator@1 { > regulator-compatible = "ldo1"; > ... > }; > }; > }; > > (and then the driver internally uses the *-supply to set up the > parents of each of its own regulators) > > ... rather than each regulator specifying its parent, which might > result in some duplication, since in this case both ldo0/1 are > supplied from the same input pin: > > tps6586x { > regulators { > regulator@0 { > regulator-compatible = "ldo0"; > vin-supply =<&some_regulator>; > ... > }; > regulator@1 { > regulator-compatible = "ldo1"; > vin-supply =<&some_regulator>; > ... > }; > }; > }; -- 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 Mon, Jun 25, 2012 at 05:09:56PM -0600, Stephen Warren wrote: > Just making sure I parsed that right. I think what you're saying is > that the device itself should represent its input pins, e.g.: > > tps6586x { > vin-ldo01-supply = <&some_regulator>; Yes, that's what I'd expect here. > ... rather than each regulator specifying its parent, which might > result in some duplication, since in this case both ldo0/1 are > supplied from the same input pin: Plus you then get back to the problem of users having to figure out where to put the references which makes everything harder to use.
Hi Mark, I require your input on supporting the vin-supply for tps6586x. On Tuesday 26 June 2012 04:39 AM, Stephen Warren wrote: > On 06/25/2012 04:26 PM, Mark Brown wrote: >> >> More specifically, all the supplies for a device (including those >> that happen to be inputs for regulators) should be specified in >> exactly the same fashion. This makes the binding more regular and >> means that users can just go through the schematic adding the >> mappings without worrying about what what the supply happens to >> be. > Just making sure I parsed that right. I think what you're saying is > that the device itself should represent its input pins, e.g.: > > tps6586x { > vin-ldo01-supply =<&some_regulator>; > vin-ldo23-supply =<...>; > vin-ldo4-supply =<...>; > vin-ldo678-supply =<...>; > vin-ldo9-supply =<...>; > ::::::::::: > }; Looked tps6586x-regulator driver and it has the platform data which is regulator_init_data. So for adding the vin-supply similar to what we have in fixed or tps6591x regulator to pass through the desc.supply_name, we are not having option here in platform data which can work for DT and non-DT case. So if still want to have the DT and non-DT case similar, we can add one tps6586x_regulator_platform_data as struct tps6586x_regulator_platform_data { const char *input_supply; struct regulator_init_data *reg_init_data; } and then pass this when registering the regulator. Or, second option is to support the input supply name for DT case through desc.supply_name and for non-DT let it be there through regulator_init_data. Please let me know your opinion. Thanks, Laxman -- 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, Jul 10, 2012 at 05:29:06PM +0530, Laxman Dewangan wrote: > Looked tps6586x-regulator driver and it has the platform data which > is regulator_init_data. > So for adding the vin-supply similar to what we have in fixed or > tps6591x regulator to pass through the desc.supply_name, we are not > having option here in platform data which can work for DT and non-DT > case. > So if still want to have the DT and non-DT case similar, we can add > one tps6586x_regulator_platform_data as The supply names are not supposed to be conditional (I realise they are for your current DT patch, I let that in because I just want to see an end to all this DT stuff).
On Tuesday 10 July 2012 07:14 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Jul 10, 2012 at 05:29:06PM +0530, Laxman Dewangan wrote: > >> Looked tps6586x-regulator driver and it has the platform data which >> is regulator_init_data. >> So for adding the vin-supply similar to what we have in fixed or >> tps6591x regulator to pass through the desc.supply_name, we are not >> having option here in platform data which can work for DT and non-DT >> case. >> So if still want to have the DT and non-DT case similar, we can add >> one tps6586x_regulator_platform_data as > The supply names are not supposed to be conditional (I realise they are > for your current DT patch, I let that in because I just want to see an > end to all this DT stuff). > Sorry, I did not get it fully. I had two patches, one for fixed one and other for tps65910. On which patch, you are seeing issue and which part of code? I like to fix it if it does not conform the DT or your expectation or any future enhancement which you are planning. Little bit more details will help so that I will not repeat the same and fix it in my future patches. Thanks, Laxman -- 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, Jul 10, 2012 at 07:14:53PM +0530, Laxman Dewangan wrote: > Sorry, I did not get it fully. I had two patches, one for fixed one > and other for tps65910. On which patch, you are seeing issue and > which part of code? Mainly tps65910. The fixed voltage regulator does have the same issue but it is somewhat special here.
On Tuesday 10 July 2012 07:23 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Jul 10, 2012 at 07:14:53PM +0530, Laxman Dewangan wrote: > >> Sorry, I did not get it fully. I had two patches, one for fixed one >> and other for tps65910. On which patch, you are seeing issue and >> which part of code? > Mainly tps65910. The fixed voltage regulator does have the same issue > but it is somewhat special here. Oops, I follow the same approach for tps65910 what it was with fixed regulator, was thinking that this is good approach. The sample code for tps65910 is as follows. So where do you think that it is wrong and what should be correct approach. I need to follow the same for tps6586x also. @@ -1023,6 +1051,13 @@ static struct tps65910_board *tps65910_parse_dt_reg_data( "ti,regulator-ext-sleep-control", &prop); if (!ret) pmic_plat_data->regulator_ext_sleep_control[idx] = prop; + + + if (info->vin_name) { + snprintf(in_supply, 32, "%s-supply", info->vin_name); + if (of_find_property(np, in_supply, 0)) + pmic_plat_data->input_supply[idx] = + info->vin_name; + } } return pmic_plat_data; @@ -1126,6 +1161,7 @@ static __devinit int tps65910_probe(struct platform_device *pdev) pmic->info[i] = info; pmic->desc[i].name = info->name; + pmic->desc[i].supply_name = pmic_plat_data->input_supply[i]; pmic->desc[i].id = i; -- 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, Jul 10, 2012 at 08:34:24PM +0530, Laxman Dewangan wrote: > The sample code for tps65910 is as follows. So where do you think > that it is wrong and what should be correct approach. > I need to follow the same for tps6586x also. Like I said the use of a supply name should be unconditional, you should just set the supply name in the descriptor.
On Tuesday 10 July 2012 09:12 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Jul 10, 2012 at 08:34:24PM +0530, Laxman Dewangan wrote: > >> The sample code for tps65910 is as follows. So where do you think >> that it is wrong and what should be correct approach. >> I need to follow the same for tps6586x also. > Like I said the use of a supply name should be unconditional, you should > just set the supply name in the descriptor. > if I set the desc.supply_name unconditional then if the entry of that supply name is not there in the DT entry (on device node) then that regulator will not get registered because the search for supply_regulator will fail during registration. I am setting the desc.supply only when there is supply entry in DT or if it is from platform. Do we need to make such supply pin entry as required inplace of optional? -- 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, Jul 10, 2012 at 10:09:38PM +0530, Laxman Dewangan wrote:
> Do we need to make such supply pin entry as required inplace of optional?
That's the idea.
On Tuesday 10 July 2012 10:22 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Jul 10, 2012 at 10:09:38PM +0530, Laxman Dewangan wrote: > >> Do we need to make such supply pin entry as required inplace of optional? > That's the idea. Then I will have 2 question: 1. If that pin is connected to battery then what should be entry? vcc1-supply = <>>>; Do we need to register battery supply as fixed (non-gpio based) and then refer here for phandle? 2. what about non-dt case? The regulator registration will also fail here because of there is no regulator saying vcc1 in this case. Do we need to register the vcc1 regualtor as fixed, battery supplied regulator in board files so that the ldo's registration will success? -- 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, Jul 10, 2012 at 10:23:48PM +0530, Laxman Dewangan wrote: > Then I will have 2 question: > 1. If that pin is connected to battery then what should be entry? > vcc1-supply = <>>>; > Do we need to register battery supply as fixed (non-gpio based) and > then refer here for phandle? Use a fixed voltage regulator to represent the battery. > 2. what about non-dt case? The regulator registration will also fail > here because of there is no regulator saying vcc1 in this case. Do > we need to register the vcc1 regualtor as fixed, battery supplied > regulator in board files so that the ldo's registration will > success? Same thing, use a fixed voltage regulator.
On Tuesday 10 July 2012 10:31 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Jul 10, 2012 at 10:23:48PM +0530, Laxman Dewangan wrote: > >> Then I will have 2 question: >> 1. If that pin is connected to battery then what should be entry? >> vcc1-supply =<>>>; >> Do we need to register battery supply as fixed (non-gpio based) and >> then refer here for phandle? > Use a fixed voltage regulator to represent the battery. > >> 2. what about non-dt case? The regulator registration will also fail >> here because of there is no regulator saying vcc1 in this case. Do >> we need to register the vcc1 regualtor as fixed, battery supplied >> regulator in board files so that the ldo's registration will >> success? > Same thing, use a fixed voltage regulator. Understood completely and it is so simple to support vin-supply. Will implement the same. Thanks for clearing doubts. -- 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
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts index 85e621a..fe2bdd0 100644 --- a/arch/arm/boot/dts/tegra20-seaboard.dts +++ b/arch/arm/boot/dts/tegra20-seaboard.dts @@ -374,6 +374,141 @@ 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 = "vdd_sm0"; + regulator-min-microvolt = < 950000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + }; + + regulator@1 { + reg = <1>; + regulator-compatible = "sm1"; + regulator-name = "vdd_sm1"; + regulator-min-microvolt = < 750000>; + regulator-max-microvolt = <1275000>; + regulator-always-on; + }; + + sm2_reg: regulator@2 { + reg = <2>; + regulator-compatible = "sm2"; + regulator-name = "vdd_sm2"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <4550000>; + regulator-always-on; + }; + + regulator@3 { + reg = <3>; + regulator-compatible = "ldo0"; + regulator-name = "vdd_ldo0"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@4 { + reg = <4>; + regulator-compatible = "ldo1"; + regulator-name = "vdd_ldo1"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + + regulator@5 { + reg = <5>; + regulator-compatible = "ldo2"; + regulator-name = "vdd_ldo2"; + regulator-min-microvolt = < 900000>; + regulator-max-microvolt = <1300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@6 { + reg = <6>; + regulator-compatible = "ldo3"; + regulator-name = "vdd_ldo3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + + regulator@7 { + reg = <7>; + regulator-compatible = "ldo4"; + regulator-name = "vdd_ldo4"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + + regulator@8 { + reg = <8>; + regulator-compatible = "ldo5"; + regulator-name = "vdd_ldo5"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + regulator@9 { + reg = <9>; + regulator-compatible = "ldo6"; + regulator-name = "vdd_ldo6"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&sm2_reg>; + }; + + regulator@10 { + reg = <10>; + regulator-compatible = "ldo7"; + regulator-name = "vdd_ldo7"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&sm2_reg>; + }; + + regulator@11 { + reg = <11>; + regulator-compatible = "ldo8"; + regulator-name = "vdd_ldo8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&sm2_reg>; + }; + + regulator@12 { + reg = <12>; + regulator-compatible = "ldo9"; + regulator-name = "vdd_ldo9"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + vin-supply = <&sm2_reg>; + }; + }; + }; + temperature-sensor@4c { compatible = "nct1008"; reg = <0x4c>; @@ -387,6 +522,10 @@ }; }; + pmc { + nvidia,invert-interrupt; + }; + memory-controller@0x7000f400 { emc-table@190000 { reg = <190000>; @@ -473,6 +612,31 @@ }; }; + regulators { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + regulator@0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "vdd_1v5"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + gpio = <&pmic 0 0>; + }; + + regulator@1 { + compatible = "regulator-fixed"; + reg = <1>; + regulator-name = "vdd_1v2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + gpio = <&pmic 1 0>; + enable-active-high; + }; + }; + sound { compatible = "nvidia,tegra-audio-wm8903-seaboard", "nvidia,tegra-audio-wm8903";