linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>>>>

  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).