Messages in this thread |  | | Subject | Re: [PATCH 7/7] pinctrl: tegra: Add driver to configure voltage and power state of io pads | | From | Stephen Warren <> | | Date | Tue, 26 Apr 2016 09:31:47 -0600 |
| |
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@nvidia.com> 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.
|  |