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-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
