linux-kernel - Re: [PATCH V3 2/4] regulator: tps62360: add dt support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FAD31A5.7090006@nvidia.com>
Date:	Fri, 11 May 2012 21:05:01 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"lrg@...com" <lrg@...com>, Stephen Warren <swarren@...dia.com>,
	"olof@...om.net" <olof@...om.net>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH V3 2/4] regulator: tps62360: add dt support

On Friday 11 May 2012 08:28 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, May 11, 2012 at 12:08:43PM +0530, Laxman Dewangan wrote:
>
> This looks good overall but I do have a few things with the binding.
>
>> +Optional properties:
>> +- ti,enable-force-pwm: Enable force PWM mode. This is boolean value.
> Hrm, this is fairly generic - it's REGULATOR_MODE_ACTIVE.  But I'm a bit
> unsure about how generic exposing it is in bindings since it's often
> dynamic in the running system, we've really not got any mainline
> examples of something setting a mode.  With modern regulators the mode
> detection stuff in the hardware is generally good enough that there's no
> benefit from doing this, it's suprising to actually see systems that
> benefit.
>

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.
Client can pass the initial mode when they fill constraint at the time 
of registration and it can also give the opportunity to change mode by 
calling regulator_set_mode().
If this is fine then I can create patch for removing this flag from 
platform data and add set_mode/get_mode function.

>> +- 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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/