Re: [PATCH v3 2/2] regulator: rk808: add dvs support

From: Chris Zhong
Date: Tue Dec 30 2014 - 21:22:04 EST



On 12/31/2014 01:04 AM, Mark Brown wrote:
On Tue, Dec 30, 2014 at 11:07:14AM +0800, Chris Zhong wrote:
On 12/30/2014 01:25 AM, Mark Brown wrote:
So, this seems a bit odd. What we appear to be doing here is
alternating between the two different voltage setting registers which is
all well and good but makes me wonder why we're bothering - it's a bit
more work than just sticking with one. We do get...
you mean check the old_selector and selector? I think
_regulator_do_set_voltage have done it.
No, I mean that we may as well just always write to the same register
and save a bunch of code.
No, when we pull down DVSn pin, the voltage value is from RK808_BUCK1_ON_VSEL_REG,
and when we pull up DVSn pin, the voltage value if from RK808_BUCK1_ON_VSEL_REG+2.
We want to this dvs function for a better voltage wave, avoid overshoot, if someone do not
need this function, they could remove the setting of DVSn pin in dts file, and at that time,
rk808_regulator will use a same register for setting voltage.


...this but unless the voltage typically ramps much faster than spec
it's never clear to me that we're actually winning by polling the pin
instead of just dead reckoning the time, it's more work for the CPU to
poll the GPIO than to sleep after all.
Actually, it's slower than spec, so I think getting this dvsok pin state
is safer than delay.
Well, that suggests that the spec is wrong which ought to be fixed
anyway oughtn't it? Or are you saying that the delay is inconsistent as
well as slower than advertised?
the spec said 2/4/6/10 mv/us, but the ramp will change depending on the load.
So I think the dvsok pin is more accurate, since it It will soon change, once the
regulator is completed. the delay is a fixed time. it is faster than dvsok pin.



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