[RFC 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

Ulf Hansson ulf.hansson at linaro.org
Mon Sep 14 03:34:32 PDT 2015


On 14 September 2015 at 11:42, Vaibhav Hiremath
<vaibhav.hiremath at linaro.org> wrote:
>
>
> On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:
>>
>> [...]
>>
>>>>>>
>>>>>> Could this be implemented by regulator API? From patch set 3/3, the
>>>>>> pxa1928
>>>>>> voltage_switch hook is to operate the IO pad registers, this seems not
>>>>>> belong
>>>>>> to the SDHC IP core.
>>>>>>
>>>>>
>>>>> Not quite sure whether regulator would be right fit for this.
>>>>
>>>>
>>>>
>>>>   From the patche[3/3], this can be achieved by abstracting the IO PAD
>>>> as
>>>> regulators
>>>> then, we may not need to touch the core sdhci.c. But I'm not sure
>>>> whether
>>>> this
>>>> is the good solution or not.
>>>
>>>
>>>
>>> Exactly...
>>>
>>>> sdhci Maintainers and experts may have better
>>>> suggestions.
>>>>
>>>
>>> Thats is the reason I stamped it as a RFC :)
>>>
>>
>> [...]
>>
>>  From an mmc core perspective it would be preferred if you implement
>> this as a regulator (vqmmc).
>>
>> Especially since we will soon have an API for how to set the I/O
>> voltages - and the intelligence within that API is not something we
>> would like to implement for each and every host driver.
>> https://lkml.org/lkml/2015/8/31/367
>>
>
>
> I would still consider this as a regulator specific and may not address
> the IO configuration within the SoC which are module specific.
> The API regulator_set_voltage_triplet() will not have intelligence to
> differentiate whether the call is coming from MMC or somewhere else.
>
> Note that, the IO pad voltage configuration which I am referring to is
> MMC specific and applicable only when pad is configured in MMC mode. So
> technically it is not simply common pad voltage configuration.
>
>
> And I am still not sure regulator framework would be right fit for
> this. Pinctrl would have been right fit, but...since I saw f_sdh30
> driver is already doing this, which is easy fit; so adopted the same.

Pinctrl would work as well, or perhaps a combination of both pinctrl
and a regulator.

What I don't like is the solution you have suggested in patch3.

Kind regards
Uffe



More information about the linux-arm-kernel mailing list