From: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Adrian Hunter
<adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities
Date: Thu, 21 Jul 2016 09:39:40 +0300 [thread overview]
Message-ID: <57906E2C.9000200@intel.com> (raw)
In-Reply-To: <578F76DF.1000500-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 20/07/16 16:04, Adrian Hunter wrote:
> On 20/07/16 16:02, Adrian Hunter wrote:
>> On 12/07/16 16:53, Jon Hunter wrote:
>>> The capabilities of the SDHCI host controller are read early during the
>>> SDHCI host initialisation in sdhci_setup_host() and before any
>>> regulators for the host have been requested. This means that if the host
>>> supports some high-speed modes (according to its capabilities register),
>>> but the board cannot because the appropriate voltage regulator is not
>>> available, then the host cannot easily override the capabilities that
>>> are supported.
>>>
>>> To allow a SDHCI host controller to determine if it can support high
>>> speed modes via the presense of the MMC regulators, request the
>>
>> Try not to confuse High Speed mode with UHS modes.
>>
>> presense -> presence
>>
>>> regulators before reading the capabilites of the host controller. This
>>
>> capabilites -> capabilities
>>
>>> will allow the SDHCI host to use the 'reset' callback to take the
>>> appropriate action (set flags, configure registers, etc) before the
>>> capabilities register(s) are read.
>>>
>>> Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
>>> the ability to mask bits in the capabilities register to prevent
>>> certain capabilities from being advertised.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>
>>> Although this is described as a "V2" this patch has been added since
>>> the original patch was posted.
>>>
>>> If the below is deemed not appropriate, then another solution I was
>>> thinking of is to allow the SDHCI host to call 'mmc_regulator_get_supply'
>>> before calling sdhci_setup_host() and then in sdhci_setup_host() check
>>> if any regulators are already present before calling
>>> mmc_regulator_get_supply().
>>
>> And we can still do that later if we need to.
>>
>>>
>>> drivers/mmc/host/sdhci.c | 16 +++++++++++-----
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 2ee8bfa77116..628c4b3558c0 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -3021,6 +3021,17 @@ int sdhci_setup_host(struct sdhci_host *host)
>>>
>>> mmc = host->mmc;
>>>
>>> + /*
>>> + * If there are external regulators, get them. Note
>>> + * this must be done early before resetting the host
>>> + * and reading the capabilities so that the host can
>>> + * take the appropriate action if regulators are not
>>> + * available.
>
> Also you could spread this comment out to 80 columns.
>
>>> + */
>>> + ret = mmc_regulator_get_supply(mmc);
>>> + if (ret == -EPROBE_DEFER)
>>> + return ret;
>>> +
>>> sdhci_read_caps(host);
>>>
>>> override_timeout_clk = host->timeout_clk;
>>> @@ -3253,11 +3264,6 @@ int sdhci_setup_host(struct sdhci_host *host)
>>> mmc_gpio_get_cd(host->mmc) < 0)
>>> mmc->caps |= MMC_CAP_NEEDS_POLL;
>>>
>>> - /* If there are external regulators, get them */
>>> - ret = mmc_regulator_get_supply(mmc);
>>> - if (ret == -EPROBE_DEFER)
>>> - goto undma;
>>
>> All goto's before this now need to goto unreg.
Er, actually they don't!
So apart from the cosmetics above:
Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>
>>> -
>>> /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>>> if (!IS_ERR(mmc->supply.vqmmc)) {
>>> ret = regulator_enable(mmc->supply.vqmmc);
>>>
>>
>>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Adrian Hunter <adrian.hunter@intel.com>
To: Adrian Hunter <adrian.hunter@intel.com>,
Jon Hunter <jonathanh@nvidia.com>,
Ulf Hansson <ulf.hansson@linaro.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Thierry Reding <thierry.reding@gmail.com>,
Alexandre Courbot <gnurou@gmail.com>
Cc: linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities
Date: Thu, 21 Jul 2016 09:39:40 +0300 [thread overview]
Message-ID: <57906E2C.9000200@intel.com> (raw)
In-Reply-To: <578F76DF.1000500@intel.com>
On 20/07/16 16:04, Adrian Hunter wrote:
> On 20/07/16 16:02, Adrian Hunter wrote:
>> On 12/07/16 16:53, Jon Hunter wrote:
>>> The capabilities of the SDHCI host controller are read early during the
>>> SDHCI host initialisation in sdhci_setup_host() and before any
>>> regulators for the host have been requested. This means that if the host
>>> supports some high-speed modes (according to its capabilities register),
>>> but the board cannot because the appropriate voltage regulator is not
>>> available, then the host cannot easily override the capabilities that
>>> are supported.
>>>
>>> To allow a SDHCI host controller to determine if it can support high
>>> speed modes via the presense of the MMC regulators, request the
>>
>> Try not to confuse High Speed mode with UHS modes.
>>
>> presense -> presence
>>
>>> regulators before reading the capabilites of the host controller. This
>>
>> capabilites -> capabilities
>>
>>> will allow the SDHCI host to use the 'reset' callback to take the
>>> appropriate action (set flags, configure registers, etc) before the
>>> capabilities register(s) are read.
>>>
>>> Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
>>> the ability to mask bits in the capabilities register to prevent
>>> certain capabilities from being advertised.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>> ---
>>>
>>> Although this is described as a "V2" this patch has been added since
>>> the original patch was posted.
>>>
>>> If the below is deemed not appropriate, then another solution I was
>>> thinking of is to allow the SDHCI host to call 'mmc_regulator_get_supply'
>>> before calling sdhci_setup_host() and then in sdhci_setup_host() check
>>> if any regulators are already present before calling
>>> mmc_regulator_get_supply().
>>
>> And we can still do that later if we need to.
>>
>>>
>>> drivers/mmc/host/sdhci.c | 16 +++++++++++-----
>>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 2ee8bfa77116..628c4b3558c0 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -3021,6 +3021,17 @@ int sdhci_setup_host(struct sdhci_host *host)
>>>
>>> mmc = host->mmc;
>>>
>>> + /*
>>> + * If there are external regulators, get them. Note
>>> + * this must be done early before resetting the host
>>> + * and reading the capabilities so that the host can
>>> + * take the appropriate action if regulators are not
>>> + * available.
>
> Also you could spread this comment out to 80 columns.
>
>>> + */
>>> + ret = mmc_regulator_get_supply(mmc);
>>> + if (ret == -EPROBE_DEFER)
>>> + return ret;
>>> +
>>> sdhci_read_caps(host);
>>>
>>> override_timeout_clk = host->timeout_clk;
>>> @@ -3253,11 +3264,6 @@ int sdhci_setup_host(struct sdhci_host *host)
>>> mmc_gpio_get_cd(host->mmc) < 0)
>>> mmc->caps |= MMC_CAP_NEEDS_POLL;
>>>
>>> - /* If there are external regulators, get them */
>>> - ret = mmc_regulator_get_supply(mmc);
>>> - if (ret == -EPROBE_DEFER)
>>> - goto undma;
>>
>> All goto's before this now need to goto unreg.
Er, actually they don't!
So apart from the cosmetics above:
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
>>
>>> -
>>> /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
>>> if (!IS_ERR(mmc->supply.vqmmc)) {
>>> ret = regulator_enable(mmc->supply.vqmmc);
>>>
>>
>>
>
>
next prev parent reply other threads:[~2016-07-21 6:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-12 13:53 [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities Jon Hunter
2016-07-12 13:53 ` Jon Hunter
2016-07-12 13:53 ` [PATCH V2 2/2] mmc: tegra: Only advertise UHS modes if IO regulator is present Jon Hunter
2016-07-12 13:53 ` Jon Hunter
[not found] ` <1468331617-22265-2-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-07-12 13:56 ` Jon Hunter
2016-07-12 13:56 ` Jon Hunter
2016-07-21 6:47 ` Adrian Hunter
2016-07-21 6:47 ` Adrian Hunter
2016-07-23 9:38 ` Ulf Hansson
2016-07-23 9:38 ` Ulf Hansson
[not found] ` <1468331617-22265-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-07-20 13:02 ` [PATCH V2 1/2] mmc: sdhci: Request regulators before reading capabilities Adrian Hunter
2016-07-20 13:02 ` Adrian Hunter
2016-07-20 13:04 ` Adrian Hunter
[not found] ` <578F76DF.1000500-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-07-21 6:39 ` Adrian Hunter [this message]
2016-07-21 6:39 ` Adrian Hunter
2016-07-23 9:37 ` Ulf Hansson
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=57906E2C.9000200@intel.com \
--to=adrian.hunter-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.