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

[nm@ti.com (Nishanth Menon)]

On 07/09/2013 10:29 AM, Mark Brown wrote:
> 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

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.

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

I am at a stalemate as to where we should go from here.

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

True, but slightly different topic though.

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


[1] http://www.i2c-bus.org/clock-generation-stretching-arbitration/
-- 
Regards,
Nishanth Menon