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

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/