>> @@ -805,6 +854,12 @@ static int tegra_sdhci_init_pinctrl_info(struct device 
>> *dev,
>>              return -1;
>>      }
>>  
>> +    tegra_host->pinctrl_state_1v8_drv = pinctrl_lookup_state(
>> +                            tegra_host->pinctrl_sdmmc, "sdmmc-1v8-drv");
>> +
>> +    tegra_host->pinctrl_state_3v3_drv = pinctrl_lookup_state(
>> +                            tegra_host->pinctrl_sdmmc, "sdmmc-3v3-drv");
>
>If this truly is optional, then I suggest we do something like this
>instead:

On tegra210, these settings are part of pinmux so using pinctrl to pinmux 
device node with existing properties pull-up and pull-down strength to 
configure timeout values.
On tegra186 and later, these settings are part of sdmmc controller itself so 
using existing pullup and pulldown timeout properties within sdmmc device node 
itself.

>From sdhci driver perspective, if pinctrl state exists (which is the case of 
>tegra210), it uses it to configure drive settings otherwise (tegra186 & 
>tegra194) it configures drive settings in pad register with in sdmmc domain 
>itself.
So in away presence of sdmmc-1v8-drv and sdmmc-3v3-drv state is optional as 
they apply only for tegra210.
>From sdhci-tegra drive perspective,  it shouldn't return error on absence of 
>these states as these states are not used for tegra186 and tegra194 and 
>instead use drive strengths time out properties.
Will add check in drive to return error on absence of both sdmmc-3v3-drv, 
sdmmc-1v8-drv pinctrl states along with drive settings properties with in sdmmc 
device node...

>
>       tegra_host->pinctrl_state_1v8_drv = pinctrl_lookup_state(...);
>       if (IS_ERR(tegra_host->pinctrl_state_1v8_drv)) {
>               err = PTR_ERR(tegra_host->pinctrl_state_1v8_drv);
>
>               if (err == -ENODEV)
>                       tegra_host->pinctrl_state_1v8_drv = NULL;
>               else
>                       return err;
>       }
>
>With that we can use the much simpler condition everywhere:
>
>       if (tegra_host->pinctrl_state_1v8_drv)
>               ...
>
>Thierry

Reply via email to