On 04/26/2016 07:32 AM, Laxman Dewangan wrote:
On Friday 15 April 2016 05:17 PM, Laxman Dewangan wrote:
On Friday 15 April 2016 04:45 PM, Linus Walleij wrote:
On Fri, Apr 15, 2016 at 11:55 AM, Laxman Dewangan
<ldewangan@xxxxxxxxxx> wrote:
On Friday 15 April 2016 02:55 PM, Linus Walleij wrote:
If the pin could actually set a voltage level it would have a
regulator.
I don't believe that. I think it is selecting one of two rails which
could theoretically hold two totally different voltages.
And that is what power-source is about.
The IO rails connected to PMIC rail and connection does not get change.
We change the voltage of PMIC rails via regulator calls. And then
configure
pads for the new voltage.
Aha I get it! So you adjust something in the I/O-cell so that it is
adapted
for the new voltage.
OK that seems to be something new. I suspect
power-voltage-select = <n>; where N i in uV would solve this?
(We should use uV since regulators use this.)
Thanks for new property. I will make the unit and type same as the
regulator framework.
We have the ops for configuring the pin config as
int (*pin_config_group_set) (struct pinctrl_dev *pctldev,
unsigned selector,
unsigned long *configs,
unsigned num_configs);
The config is 32 bit, upper 16 for config argument and and lower 16 for
the config param.
So we can not accommodate 3300000uV until we change it to mV i.e. 3300mV.
So on interface, we can read uV from DT but when making config, we can
translate it to mV before passing to pin_config_group_set.
A SoC-specific enum would make more sense. It would avoid any
translation. There's no need for a generic value since the available set
of options is SoC-specific, the data source is SoC-specific, and there's
no need for any code besides the SoC-specific driver to interpret the
value in any way at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
