Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1387489 > unrolled thread

Re: [PATCH 7/7] pinctrl: tegra: Add driver to configure voltage and power state of io pads

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 7/7] pinctrl: tegra: Add driver to configure voltage and  power state of io pads Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-26 15:50 +0200
    Re: [PATCH 7/7] pinctrl: tegra: Add driver to configure voltage and  power state of io pads Stephen Warren <swarren@wwwdotorg.org> - 2016-04-26 17:40 +0200

#1387489 — Re: [PATCH 7/7] pinctrl: tegra: Add driver to configure voltage and power state of io pads

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.

[toc] | [next] | [standalone]

#1387631

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web