linux-kernel - Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP

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] [day] [month] [year] [list]

Date:	Wed, 10 Jul 2013 10:19:52 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nishanth Menon <nm@...com>
Cc:	Benoît Cousson <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Grygorii Strashko <grygorii.strashko@...com>,
	Taras Kondratiuk <taras@...com>
Subject: Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP

On Tue, Jul 09, 2013 at 11:04:23AM -0500, Nishanth Menon wrote:
> On 07/09/2013 10:29 AM, Mark Brown wrote:

> >This seems like something we should be able to cope with by for example
> >adding a bus for the custom PMIC interface or otherwise finding a way to

> I had considered introducing a custom bus for custom PMIC interface,
> but as you stated below, standard regulators will probably need some
> custom monkeying around.

We should just be able to use the platform bus here.

> >get to the data at runtime based on the compatible string.  This would
> >need some custom code in the regulators but would have the advantage of
> >keeping the data the same at least.  Hrm.

> Ofcourse,this will be to add custom set/get_voltage implementation
> using this "custom API" which we discussed was'nt that good an idea.

No, if the regulator isn't being interacted with directly then it
doesn't need to export any operations - just data.  The operations would
come from the magic SoC hardware that controls the regulator.  The code
in the drivers should be very small, if it isn't there's no point in
doing this.

> >>between PMICs? yep, twl4030 does 4mV/uSec, 6030 can do 6mV/uSec,
> >>TPS62361 can do 32mV/uSec, TWL6035/37 does 0.220mV/uSec

> >Those are ramp rates, they're not I2C I/O limits.  Ramp rates we already
> >know about.  I think what you're saying here is that this latency value
> >is actually about worst case ramp times?

> Arrgh.. my bad. I confused ramp time with I2C transfer timeout
> parameter. I know that I2C bus can be held[1] by PMIC as long as it
> is busy. Some custom ASIC can do some weird stuff I suppose. I dont
> seem to have clear data points in the sketchy TRMs for 6030/2 ,
> 6035, 5030, for these other than to state it is i2c specification
> compliant (/me grumbles). So, I just have emperical value which is a
> bit conservative and seem to work on the devices.

OK, no problem - like we said further up the thread I think adding
something to get the data

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)