| Message ID | 1304081264-4915-2-git-send-email-kalle.jokiniemi@nokia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 29 Apr 2011 15:47:44 +0300 Kalle Jokiniemi <kalle.jokiniemi@nokia.com> wrote: > +static struct regulator_init_data rx51_vintana1 = { > + .constraints = { > + .name = "VINTANA1", > + .min_uV = 1500000, > + .max_uV = 1500000, > + .always_on = true, ... > +static struct regulator_init_data rx51_vintdig = { > + .constraints = { > + .name = "VINTDIG", > + .min_uV = 1500000, > + .max_uV = 1500000, > + .always_on = true, Are these two used at all? According to public schematics they are connected to just one capasitor. Could be some needed filtering/charge pump capacitors for TWL though. I was thinking are all of these regulators really always_on? How about letting those without any known user to be switched off? > @@ -838,6 +911,8 @@ static int __init rx51_i2c_init(void) > omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2, > ARRAY_SIZE(rx51_peripherals_i2c_board_info_2)); > omap_register_i2c_bus(3, 400, NULL, 0); > + regulator_has_full_constraints(); > + > return 0; > } > Move this somewhere else than in i2c initialization function :-)
On Fri, Apr 29, 2011 at 03:47:44PM +0300, Kalle Jokiniemi wrote: > + .always_on = true, > + .valid_modes_mask = REGULATOR_MODE_NORMAL > + | REGULATOR_MODE_STANDBY, > + .valid_ops_mask = REGULATOR_CHANGE_MODE > + | REGULATOR_CHANGE_STATUS, _CHANGE_STATUS doesn't make much sense in conjunction with always_on. Otherwise this looks OK to me. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, > -----Original Message----- > From: ext Jarkko Nikula [mailto:jhnikula@gmail.com] > Sent: 29. huhtikuuta 2011 17:04 > To: Jokiniemi Kalle (Nokia-SD/Tampere) > Cc: tony@atomide.com; Ailus Sakari (Nokia-SD/Helsinki); linux- > omap@vger.kernel.org; lrg@slimlogic.co.uk; > broonie@opensource.wolfsonmicro.com > Subject: Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions > > On Fri, 29 Apr 2011 15:47:44 +0300 > Kalle Jokiniemi <kalle.jokiniemi@nokia.com> wrote: > > > +static struct regulator_init_data rx51_vintana1 = { > > + .constraints = { > > + .name = "VINTANA1", > > + .min_uV = 1500000, > > + .max_uV = 1500000, > > + .always_on = true, > ... > > +static struct regulator_init_data rx51_vintdig = { > > + .constraints = { > > + .name = "VINTDIG", > > + .min_uV = 1500000, > > + .max_uV = 1500000, > > + .always_on = true, > > Are these two used at all? According to public schematics they are > connected to just one capasitor. Could be some needed filtering/charge > pump capacitors for TWL though. > > I was thinking are all of these regulators really always_on? How about > letting those without any known user to be switched off? In a working environment, these regulators were on. If you let all regulators get disabled, you'll just be asking for trouble. Here's the initial discussion how this patch came about: http://www.mail-archive.com/linux-media@vger.kernel.org/msg30775.html > > > @@ -838,6 +911,8 @@ static int __init rx51_i2c_init(void) > > omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2, > > ARRAY_SIZE(rx51_peripherals_i2c_board_info_2)); > > omap_register_i2c_bus(3, 400, NULL, 0); > > + regulator_has_full_constraints(); > > + > > return 0; > > } > > > Move this somewhere else than in i2c initialization function :-) I figured it would be right after the regulators have been initialized... But yes, I'll find a better place for this. - Kalle > > -- > Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, > -----Original Message----- > From: ext Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] > Sent: 30. huhtikuuta 2011 22:24 > To: Jokiniemi Kalle (Nokia-SD/Tampere) > Cc: tony@atomide.com; Ailus Sakari (Nokia-SD/Helsinki); linux- > omap@vger.kernel.org; lrg@slimlogic.co.uk > Subject: Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions > > On Fri, Apr 29, 2011 at 03:47:44PM +0300, Kalle Jokiniemi wrote: > > > + .always_on = true, > > + .valid_modes_mask = REGULATOR_MODE_NORMAL > > + | REGULATOR_MODE_STANDBY, > > + .valid_ops_mask = REGULATOR_CHANGE_MODE > > + | REGULATOR_CHANGE_STATUS, > > _CHANGE_STATUS doesn't make much sense in conjunction with always_on. > Otherwise this looks OK to me. Ok, I'll remove those. Thanks. - Kalle -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Jokiniemi Kalle (Nokia-SD/Tampere) > > Hi, > > > -----Original Message----- > > From: ext Jarkko Nikula [mailto:jhnikula@gmail.com] > > Sent: 29. huhtikuuta 2011 17:04 > > To: Jokiniemi Kalle (Nokia-SD/Tampere) > > Cc: tony@atomide.com; Ailus Sakari (Nokia-SD/Helsinki); linux- > > omap@vger.kernel.org; lrg@slimlogic.co.uk; > > broonie@opensource.wolfsonmicro.com > > Subject: Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions > > > > On Fri, 29 Apr 2011 15:47:44 +0300 > > Kalle Jokiniemi <kalle.jokiniemi@nokia.com> wrote: > > > > > +static struct regulator_init_data rx51_vintana1 = { > > > + .constraints = { > > > + .name = "VINTANA1", > > > + .min_uV = 1500000, > > > + .max_uV = 1500000, > > > + .always_on = true, > > ... > > > +static struct regulator_init_data rx51_vintdig = { > > > + .constraints = { > > > + .name = "VINTDIG", > > > + .min_uV = 1500000, > > > + .max_uV = 1500000, > > > + .always_on = true, > > > > Are these two used at all? According to public schematics they are > > connected to just one capasitor. Could be some needed filtering/charge > > pump capacitors for TWL though. It seems I was not answering your question quite rightly... So these are used to power some internal blocks inside the TWL5030. The dependencies there are not very well documented, so it's best to leave them be. I think these could be turned off via the power scripts during OFF mode (if we would be using that). - Kalle > > > > I was thinking are all of these regulators really always_on? How about > > letting those without any known user to be switched off? > > In a working environment, these regulators were on. If you let all regulators > get disabled, you'll just be asking for trouble. > > Here's the initial discussion how this patch came about: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg30775.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2 May 2011 05:19:46 +0000 <kalle.jokiniemi@nokia.com> wrote: > It seems I was not answering your question quite rightly... So these are used > to power some internal blocks inside the TWL5030. The dependencies there > are not very well documented, so it's best to leave them be. I think these > could be turned off via the power scripts during OFF mode (if we would be > using that). > Sounds safe assumption for those two. Also I don't point out from public schematics where are the vintana2 and vpll2 routed so looks like need keep them on as well.
Hi, > -----Original Message----- > From: ext Jarkko Nikula [mailto:jhnikula@gmail.com] > Sent: 2. toukokuuta 2011 9:57 > To: Jokiniemi Kalle (Nokia-SD/Tampere) > Cc: tony@atomide.com; Ailus Sakari (Nokia-SD/Helsinki); linux- > omap@vger.kernel.org; lrg@slimlogic.co.uk; > broonie@opensource.wolfsonmicro.com > Subject: Re: [PATCH 1/1] OMAP3: rx-51: Add full regulator definitions > > On Mon, 2 May 2011 05:19:46 +0000 > <kalle.jokiniemi@nokia.com> wrote: > > > It seems I was not answering your question quite rightly... So these are used > > to power some internal blocks inside the TWL5030. The dependencies there > > are not very well documented, so it's best to leave them be. I think these > > could be turned off via the power scripts during OFF mode (if we would be > > using that). > > > Sounds safe assumption for those two. Also I don't point out from > public schematics where are the vintana2 and vpll2 routed so looks like > need keep them on as well. In case you're interested, the high level routings are listed in the TPS65950 TRM: http://focus.ti.com/lit/ug/swcu050g/swcu050g.pdf See chapter 6.3, figure 6-3. - Kalle > > -- > Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index bbcb677..8373b74 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -475,6 +475,34 @@ static struct regulator_init_data rx51_vmmc2 = { .consumer_supplies = rx51_vmmc2_supplies, }; +static struct regulator_init_data rx51_vpll1 = { + .constraints = { + .name = "VPLL", + .min_uV = 1800000, + .max_uV = 1800000, + .apply_uV = true, + .always_on = true, + .valid_modes_mask = REGULATOR_MODE_NORMAL + | REGULATOR_MODE_STANDBY, + .valid_ops_mask = REGULATOR_CHANGE_MODE + | REGULATOR_CHANGE_STATUS, + }, +}; + +static struct regulator_init_data rx51_vpll2 = { + .constraints = { + .name = "VSDI_CSI", + .min_uV = 1800000, + .max_uV = 1800000, + .apply_uV = true, + .always_on = true, + .valid_modes_mask = REGULATOR_MODE_NORMAL + | REGULATOR_MODE_STANDBY, + .valid_ops_mask = REGULATOR_CHANGE_MODE + | REGULATOR_CHANGE_STATUS, + }, +}; + static struct regulator_init_data rx51_vsim = { .constraints = { .name = "VMMC2_IO_18", @@ -519,6 +547,46 @@ static struct regulator_init_data rx51_vio = { .consumer_supplies = rx51_vio_supplies, }; +static struct regulator_init_data rx51_vintana1 = { + .constraints = { + .name = "VINTANA1", + .min_uV = 1500000, + .max_uV = 1500000, + .always_on = true, + .valid_modes_mask = REGULATOR_MODE_NORMAL + | REGULATOR_MODE_STANDBY, + .valid_ops_mask = REGULATOR_CHANGE_MODE + | REGULATOR_CHANGE_STATUS, + }, +}; + +static struct regulator_init_data rx51_vintana2 = { + .constraints = { + .name = "VINTANA2", + .min_uV = 2750000, + .max_uV = 2750000, + .apply_uV = true, + .always_on = true, + .valid_modes_mask = REGULATOR_MODE_NORMAL + | REGULATOR_MODE_STANDBY, + .valid_ops_mask = REGULATOR_CHANGE_MODE + | REGULATOR_CHANGE_STATUS, + }, +}; + +static struct regulator_init_data rx51_vintdig = { + .constraints = { + .name = "VINTDIG", + .min_uV = 1500000, + .max_uV = 1500000, + .always_on = true, + .valid_modes_mask = REGULATOR_MODE_NORMAL + | REGULATOR_MODE_STANDBY, + .valid_ops_mask = REGULATOR_CHANGE_MODE + | REGULATOR_CHANGE_STATUS, + }, +}; + static struct si4713_platform_data rx51_si4713_i2c_data __initdata_or_module = { .gpio_reset = RX51_FMTX_RESET_GPIO, }; @@ -767,8 +835,13 @@ static struct twl4030_platform_data rx51_twldata __initdata = { .vaux2 = &rx51_vaux2, .vaux4 = &rx51_vaux4, .vmmc1 = &rx51_vmmc1, + .vpll1 = &rx51_vpll1, + .vpll2 = &rx51_vpll2, .vsim = &rx51_vsim, .vdac = &rx51_vdac, + .vintana1 = &rx51_vintana1, + .vintana2 = &rx51_vintana2, + .vintdig = &rx51_vintdig, .vio = &rx51_vio, }; @@ -838,6 +911,8 @@ static int __init rx51_i2c_init(void) omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2, ARRAY_SIZE(rx51_peripherals_i2c_board_info_2)); omap_register_i2c_bus(3, 400, NULL, 0); + regulator_has_full_constraints(); + return 0; }
The vaux2 (VCSI) regulator is left on by the bootloader in rx-51. Since there the product has shipped and there won't be any bootloader updates to fix this issue, we need to define all the regulators and declare full constraints for the regulator FW. This will allow the regulator FW to disable unused regulators. Also this helps in adding more fine grain regulator support for rx-51 in the future. Thanks for Mark Brown for pointing out the correct solution. Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> --- arch/arm/mach-omap2/board-rx51-peripherals.c | 75 ++++++++++++++++++++++++++ 1 files changed, 75 insertions(+), 0 deletions(-)