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 for Android: free password hash cracker in your pocket

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

Message-ID: <4FB89AEF.3080107@nvidia.com>
Date:	Sun, 20 May 2012 12:49:11 +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 Saturday 12 May 2012 03:00 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, May 11, 2012 at 09:05:01PM +0530, Laxman Dewangan wrote:
>
>> 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.
>

Just to share  here with our new pmu which we got recently, the 
discharge path behavior is exactly same as what Mark mentioned
It need to be enable always. The pmu auto disable the DISC path in 
normal operation so there is no power dissipation but when it detects 
the en_bit is written 0 or any external control is making the rail to be 
off, it automatically turn on the path so that ramp-down can happen faster.
Just we need to enable this always.

> 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).

--
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/