From: vaibhav.hiremath@linaro.org (Vaibhav Hiremath)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages
Date: Mon, 14 Sep 2015 18:17:03 +0530 [thread overview]
Message-ID: <55F6C1C7.8030107@linaro.org> (raw)
In-Reply-To: <55F6C080.8000604@linaro.org>
On Monday 14 September 2015 06:11 PM, Vaibhav Hiremath wrote:
>
>
> On Monday 14 September 2015 04:04 PM, Ulf Hansson wrote:
>> On 14 September 2015 at 11:42, Vaibhav Hiremath
>> <vaibhav.hiremath@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.
>
>
> Not sure, how I can propagate "call coming from MMC/SD" to both
> regulator and pinctrl.
> Probably pinctrl would already know, but then it doesn't know the
> voltage settings.
>
> Let me spend some time, but atleast at this point I am not sure.
>
>>
On the side note,
Lets park this patch aside, till I get back with better option.
It would be nice if you could review other patches, let them notget
blocked due to this.
Thanks,
Vaibhav
next prev parent reply other threads:[~2015-09-14 12:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 19:32 [RFC 0/3] mmc: sdhci: pass signal voltage as an argument to ->voltage_switch() Vaibhav Hiremath
2015-09-01 19:32 ` [RFC 1/3] mmc: sdhci: pass signal_voltage as an argument to voltage_switch callback Vaibhav Hiremath
2015-09-01 19:32 ` [RFC 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages Vaibhav Hiremath
2015-09-02 7:04 ` Jisheng Zhang
2015-09-02 8:19 ` Vaibhav Hiremath
2015-09-02 8:26 ` Jisheng Zhang
2015-09-02 11:43 ` Vaibhav Hiremath
2015-09-14 9:30 ` Ulf Hansson
2015-09-14 9:42 ` Vaibhav Hiremath
2015-09-14 10:34 ` Ulf Hansson
2015-09-14 12:41 ` Vaibhav Hiremath
2015-09-14 12:47 ` Vaibhav Hiremath [this message]
2015-10-02 10:00 ` Linus Walleij
2015-09-01 19:32 ` [RFC 3/3] mmc: sdhci-pxav3: Add ->voltage_switch callback support Vaibhav Hiremath
[not found] ` <55E6FEF5.9080905@rock-chips.com>
2015-09-02 14:32 ` Vaibhav Hiremath
2015-09-03 18:35 ` Vaibhav Hiremath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F6C1C7.8030107@linaro.org \
--to=vaibhav.hiremath@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).