From: Subhash Jadavani <subhashj@codeaurora.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v1 1/3] mmc: sdio: fix resume failure
Date: Sat, 08 Dec 2012 11:25:12 +0530 [thread overview]
Message-ID: <50C2D640.6010800@codeaurora.org> (raw)
In-Reply-To: <CAPDyKFoBVFoUXJ48GdOmgzasOP7zvVAkjzCHCZ7ZdUxgJMBSxQ@mail.gmail.com>
On 12/7/2012 8:21 PM, Ulf Hansson wrote:
> On 7 December 2012 13:15, Subhash Jadavani <subhashj@codeaurora.org> wrote:
>> On 12/7/2012 3:40 AM, Ulf Hansson wrote:
>>> On 6 December 2012 16:25, Subhash Jadavani <subhashj@codeaurora.org>
>>> wrote:
>>>> On 12/6/2012 4:03 PM, Ulf Hansson wrote:
>>>>> On 4 December 2012 12:36, Subhash Jadavani <subhashj@codeaurora.org>
>>>>> wrote:
>>>>>> If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
>>>>>> be reinitialized during resume but as we are not resetting
>>>>>> (CMD52 reset) the SDIO card during this reinitialization, card may
>>>>>> fail to respond back to subsequent commands (CMD5 etc...).
>>>>>>
>>>>>> This change resets the card before the reinitialization of card
>>>>>> during resume.
>>>>>>
>>>>>> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
>>>>>> ---
>>>>>> drivers/mmc/core/sdio.c | 6 ++++--
>>>>>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
>>>>>> index 2273ce6..34ad4c8 100644
>>>>>> --- a/drivers/mmc/core/sdio.c
>>>>>> +++ b/drivers/mmc/core/sdio.c
>>>>>> @@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
>>>>>> mmc_claim_host(host);
>>>>>>
>>>>>> /* No need to reinitialize powered-resumed nonremovable cards
>>>>>> */
>>>>>> - if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
>>>>>> + if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
>>>>>> {
>>>>>> + sdio_reset(host);
>>>>>> + mmc_go_idle(host);
>>>>> If the card has lost power, why is this needed? Could it be that the
>>>>> host is not capable of cutting the power to card?
>>>>
>>>> Yes, the regulator powering the card is always on in this case which
>>>> means
>>>> SDIO VDD is not powered off during the suspend.
>>>>
>>> So in principle the host should be able to notify the protocol layer
>>> about that mmc_card_keep_power will always be set somehow.
>>> That could be a more proper way of solving this maybe? What do you think?
>> Ok.
>> Basically this would be the suspend/resume sequence with Keep Power flag
>> cleared.
> I mean the exact opposite. :-)
>
> mmc_keep_power should be _set_ during suspend/resume sequence.
>
> That will mean at suspend; sdio_disable_4bit_bus will be called and
> mmc_power_off will not.
> At resume, sdio_enable_4bit_bus will be called, without doing
> mmc_power_up and mmc_sdio_init_card.
>
> Do note that there is no API for the setting mmc_keep_power from a
> host. It exist only in the SDIO API. (sdio_set_host_pm_flags).
> So I guess we should invent this API for the host to use.
Thanks Ulf. I got your point. Will try out your suggestion and will
update (with patch & result) soon.
On the other hand,
Do you see it's worth to have this current patch as well? I guess it's
safe to do sdio_reset() before SDIO card init and we are already playing
safe even in mmc_rescan*() by calling sdio_reset() before card detection.
Regards,
Subhash
>
>> Suspend:
>> 1. Execute Function driver suspend
>> 2. mmc_power_off()
>> 2.1 As this is regulator powering card SDIO VDD line is always on
>> regulator, it will stay on.
>>
>> Resume:
>> 1. mmc_power_up()
>> 1.1 Regulator was anyway on so nothing change here.
>> 2. mmc_sdio_init_card() - reinitialize the card
>> 2.1 CMD5 gets the commands response timeout which means card doesn't
>> respond back.
>>
>> My understanding is that behaviour seen in 2.1 (resume) is because during
>> suspend, function driver suspend might have done something with the SDIO
>> card (as keep power flag was disabled) and that's the reason during resume,
>> card fails to respond back to CMD5 (unless we send the CMD52 to reset the
>> card). It's an athros SDIO wifi card here.
>>
>>
>>>> So in principle the host should be able to notify the protocol layer
>>>> about that mmc_card_keep_power will always be set somehow.
>> Given the above issue, i am not sure how is this suggestion going to help in
>> this case?
>>
>> Regards,
>> Subhash
>>
>>
>>>>> It might be more safe to do this but I would like to understand more,
>>>>> before you get my ack on this patch.
>>>>>
>>>>>> err = mmc_sdio_init_card(host, host->ocr, host->card,
>>>>>> mmc_card_keep_power(host));
>>>>>> - else if (mmc_card_keep_power(host) &&
>>>>>> mmc_card_wake_sdio_irq(host)) {
>>>>>> + } else if (mmc_card_keep_power(host) &&
>>>>>> mmc_card_wake_sdio_irq(host)) {
>>>>>> /* We may have switched to 1-bit mode during suspend
>>>>>> */
>>>>>> err = sdio_enable_4bit_bus(host->card);
>>>>>> if (err > 0) {
>>>>>> --
>>>>>> --
>>>>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>>>>>> member
>>>>>> of Code Aurora Forum, hosted by The Linux Foundation
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> Kind regards
>>>>> Ulf Hansson
>>>>
next prev parent reply other threads:[~2012-12-08 5:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 11:36 [PATCH v1 0/3] SDIO fixes Subhash Jadavani
2012-12-04 11:36 ` [PATCH v1 1/3] mmc: sdio: fix resume failure Subhash Jadavani
2012-12-06 10:33 ` Ulf Hansson
2012-12-06 15:25 ` Subhash Jadavani
2012-12-06 22:10 ` Ulf Hansson
2012-12-07 12:15 ` Subhash Jadavani
2012-12-07 14:51 ` Ulf Hansson
2012-12-08 5:55 ` Subhash Jadavani [this message]
2012-12-10 12:55 ` Ulf Hansson
2012-12-04 11:36 ` [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence Subhash Jadavani
2012-12-04 21:14 ` Bing Zhao
2012-12-05 5:17 ` Shen, Jackey
2012-12-05 19:13 ` Bing Zhao
2012-12-06 3:21 ` Shen, Jackey
2012-12-06 3:33 ` Bing Zhao
2012-12-06 6:22 ` Subhash Jadavani
2012-12-06 18:48 ` Bing Zhao
2012-12-07 8:42 ` Johan Rudholm
2012-12-07 9:57 ` Ulf Hansson
2012-12-04 11:36 ` [PATCH v1 3/3] mmc: sdio: print correct UHS mode during card detection Subhash Jadavani
2012-12-06 10:41 ` Ulf Hansson
2012-12-26 4:59 ` Shen, Jackey
[not found] ` <50C7271D.2080704@codeaurora.org>
[not found] ` <86988B169C1CD04598F5B80198CCE50E738D93@aphydexd01b>
2012-12-11 12:41 ` FW: [PATCH v1 0/3] SDIO fixes Subhash Jadavani
2013-01-14 19:07 ` Chris Ball
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=50C2D640.6010800@codeaurora.org \
--to=subhashj@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.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).