From: Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> To: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> Cc: "grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org" <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>, "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>, "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>, "lrg-l0cyMroinI0@public.gmane.org" <lrg-l0cyMroinI0@public.gmane.org>, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>, "olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org" <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>, "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>, "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH V3 2/4] regulator: tps62360: add dt support Date: Fri, 11 May 2012 22:30:02 +0100 [thread overview] Message-ID: <20120511213001.GD29835@opensource.wolfsonmicro.com> (raw) In-Reply-To: <4FAD31A5.7090006-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> [-- Attachment #1: Type: text/plain, Size: 2164 bytes --] On Fri, May 11, 2012 at 09:05:01PM +0530, Laxman Dewangan wrote: > Yaah, I think this flag can map directly to REGULATOR_MODE_FAST. If > I understand PWM mode properly then this is used when high current > load is require or fast switching on load current is require. By > enabling force PWM enable, hw will not switch to PFM mode based on > load current. > I think if we map the regulator mode to FAST as the force PWM enable > and NORMAL as force PWM =0 then it will be generic. Yes, this is pretty much exactly what _FAST means. With modern hardware the forced PWM mode just isn't needed, a modern regulator is able to respond sufficiently quickly to changes in the output load. Mode switching from software was generally found to be impractical for DCDC convertors as the load requirements change so quickly and without software control that by the time you respond from software you can't switch out of a lower power mode into a higher current one it's too late. > >>+- ti,enable-vout-discharge: Enable output discharge. This is boolean value. > >This I think we should definitely add a framework feature for this and > >make into a generic property, it's a very standard feature and more > >normally set unconditionally. > I think this is not require to enable always otherwise there may be > power dissipation from this path always, just when we off the rail > (disable rail or when go to shutdown so that the voltage output can > go down faster). > Should we add "unsigned en_discharge:1" in regulator init data but > did not get how core driver can use this flag specially when > shutdown? Oh, now you say this I think I remember discussing this with you before! This is pretty unusual for such hardware. Normally there's something in the digital block so that the discharge is only enabled if the regulator is disabled, if it's enabled then the discharge would automatically be taken off since actively discharging while enabled doesn't make sense and may in fact be actively harmful. If the hardware doesn't do that then I'd expect the driver to take care of this if it implements the framework feature (once the framework feature is added). [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com> To: Laxman Dewangan <ldewangan@nvidia.com> Cc: "grant.likely@secretlab.ca" <grant.likely@secretlab.ca>, "rob.herring@calxeda.com" <rob.herring@calxeda.com>, "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>, "lrg@ti.com" <lrg@ti.com>, Stephen Warren <swarren@nvidia.com>, "olof@lixom.net" <olof@lixom.net>, "devicetree-discuss@lists.ozlabs.org" <devicetree-discuss@lists.ozlabs.org>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org> Subject: Re: [PATCH V3 2/4] regulator: tps62360: add dt support Date: Fri, 11 May 2012 22:30:02 +0100 [thread overview] Message-ID: <20120511213001.GD29835@opensource.wolfsonmicro.com> (raw) In-Reply-To: <4FAD31A5.7090006@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 2164 bytes --] On Fri, May 11, 2012 at 09:05:01PM +0530, Laxman Dewangan wrote: > Yaah, I think this flag can map directly to REGULATOR_MODE_FAST. If > I understand PWM mode properly then this is used when high current > load is require or fast switching on load current is require. By > enabling force PWM enable, hw will not switch to PFM mode based on > load current. > I think if we map the regulator mode to FAST as the force PWM enable > and NORMAL as force PWM =0 then it will be generic. Yes, this is pretty much exactly what _FAST means. With modern hardware the forced PWM mode just isn't needed, a modern regulator is able to respond sufficiently quickly to changes in the output load. Mode switching from software was generally found to be impractical for DCDC convertors as the load requirements change so quickly and without software control that by the time you respond from software you can't switch out of a lower power mode into a higher current one it's too late. > >>+- ti,enable-vout-discharge: Enable output discharge. This is boolean value. > >This I think we should definitely add a framework feature for this and > >make into a generic property, it's a very standard feature and more > >normally set unconditionally. > I think this is not require to enable always otherwise there may be > power dissipation from this path always, just when we off the rail > (disable rail or when go to shutdown so that the voltage output can > go down faster). > Should we add "unsigned en_discharge:1" in regulator init data but > did not get how core driver can use this flag specially when > shutdown? Oh, now you say this I think I remember discussing this with you before! This is pretty unusual for such hardware. Normally there's something in the digital block so that the discharge is only enabled if the regulator is disabled, if it's enabled then the discharge would automatically be taken off since actively discharging while enabled doesn't make sense and may in fact be actively harmful. If the hardware doesn't do that then I'd expect the driver to take care of this if it implements the framework feature (once the framework feature is added). [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-11 21:30 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-11 6:38 [PATCH V3 0/4] regulator: tps62360: support dts and enable for tegra-cardhu Laxman Dewangan 2012-05-11 6:38 ` Laxman Dewangan 2012-05-11 6:38 ` [PATCH V3 1/4] regulator: tps62360: make init_data of platform data to pointer Laxman Dewangan 2012-05-11 6:38 ` Laxman Dewangan 2012-05-11 15:09 ` Mark Brown 2012-05-11 6:38 ` [PATCH V3 2/4] regulator: tps62360: add dt support Laxman Dewangan 2012-05-11 6:38 ` Laxman Dewangan 2012-05-11 14:58 ` Mark Brown [not found] ` <20120511145833.GG3960-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 2012-05-11 15:35 ` Laxman Dewangan 2012-05-11 15:35 ` Laxman Dewangan [not found] ` <4FAD31A5.7090006-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2012-05-11 21:30 ` Mark Brown [this message] 2012-05-11 21:30 ` Mark Brown 2012-05-20 7:19 ` Laxman Dewangan 2012-05-20 7:19 ` Laxman Dewangan 2012-05-11 20:36 ` Mark Brown 2012-05-11 6:38 ` [PATCH V3 3/4] ARM: tegra: config: enable REGULATOR_TPS62360 Laxman Dewangan 2012-05-11 6:38 ` Laxman Dewangan 2012-05-11 6:38 ` [PATCH V3 4/4] ARM: dt: tegra: cardhu: register core regulator tps62360 Laxman Dewangan 2012-05-11 6:38 ` Laxman Dewangan
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=20120511213001.GD29835@opensource.wolfsonmicro.com \ --to=broonie-yzvpicuk2aatku/dhu1wvuem+bqzidxxqq4iyu8u01e@public.gmane.org \ --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \ --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \ --cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \ --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \ --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=lrg-l0cyMroinI0@public.gmane.org \ --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \ --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \ --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.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.