Re: [RFC/RFT][PATCH] regulator: palmas: Convert to use regulator_set_voltage_time_sel()
From: Laxman Dewangan
Date: Sun Apr 21 2013 - 04:52:46 EST
On Saturday 20 April 2013 05:42 PM, Axel Lin wrote:
Use regulator_set_voltage_time_sel() instead of open coded.
If rdev->constraints->ramp_delay is specified, the setting will be used in
regulator_set_voltage_time_sel(). And then pmic->ramp_delay[] is not used and
can be removed.
There is a different behavior change here:
regulator_set_voltage_time_sel() always returns
DIV_ROUND_UP(abs(new_volt - old_volt), ramp_delay);
palma_smps_set_voltage_smps_time_sel() actually returns
DIV_ROUND_UP(abs(new_volt - old_volt), modified_ramp_delay);
where the modified_ramp_delay is not exactly specified by
rdev->constraints->ramp_delay but a value from pmic->ramp_delay[id].
So palma_smps_set_voltage_smps_time_sel() may return a smaller delay than
regulator_set_voltage_time_sel() depend on rdev->constraints->ramp_delay value.
I think the delay in both version are *safe* for the operation.
Nack,
This approach does not look good and the reason for which I did not use
this core api here was:
- The palma device support ramp of 10mV/us, 5mV/us and 2.5mV/us. So if
client pass the other than this value then register is programmed to
nearest high value.
In this case, the constraint->ramp_delay is not much accurate with
register level programming and need to update with actual register
programmed. Hence we need to have local equivalent to the register
programmed and use this new value instead of constraints->ramp_delay.
- Second reason is that TPS65913 ES1.0/ES2.0 has the hw errata on which
the output voltage become slow ramp near to final value. TI suggested to
use 1.5x as SWAR. So we need to use the local implementation to adjust this.
The changes for this errata is not there because we will need to read
the version register and Ian has posted the series which is not merged
yet. So waiting for his series to be merged for this errata implementation.
--
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/