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

Message-ID: <20130709152954.GF27646@sirena.org.uk>
Date:	Tue, 9 Jul 2013 16:29:54 +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 Mon, Jul 08, 2013 at 12:22:36PM -0500, Nishanth Menon wrote:

> case #1 - TPS62361 has a single SMPS and a single generic i2c bus,
> one can talk on. In this case, you'd associate the regulator device
> in one place - i2cX or on custom SoC hardware interface.

> When used with custom SoC hardware interface, generic tps62361
> regulator which talks regular i2c wont even probe for omap_pmic to
> get the regulator data from tps62361 regulator driver. Even if we
> were to define the generic TPS62361 in dts nodes, it will fail probe
> as it cant access any of it's registers using generic i2c.

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

> >Another option is for the drivers to provide the data and use the
> >helpers for their linear ranges as part of a more complex
> >implementation.

> Having looked at a few regulator driver implementations, there seems
> to be the following combinations:
> a) drivers which have n ranges of linear voltages for incremental selector
> b) drivers with 1 range of linear voltages only for all ranges of selectors
> c) drivers with 1 range of linear voltages and nonlinear voltage
> values for other vsels.

Everything else is just a special case of option a - either there's just
a single range or there's a bunch of ranges each with a single value.  I
suspect that ranges will be the most useful thing for any hardware which
can practically be used by these regulators anyway.

> >OK, that's a bit more fun but I think the kernel wants that information
> >in general anyway since a software cpufreq driver or something might
> >want to make the same latency decisions.  This is what set_voltage_time()
> >is for in part.  But to a first approximation is there really much
> >variation in the numbers?

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

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