From: Adrian Hunter <adrian.hunter@intel.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Ulf Hansson <ulf.hansson@stericsson.com>,
linux-mmc <linux-mmc@vger.kernel.org>,
Chris Ball <cjb@laptop.org>,
Johan Rudholm <johan.rudholm@stericsson.com>
Subject: Re: [PATCH 1/3] mmc: core: Remove power_restore bus_ops for mmc and sd
Date: Fri, 05 Apr 2013 11:50:38 +0300 [thread overview]
Message-ID: <515E905E.8090201@intel.com> (raw)
In-Reply-To: <CAPDyKFo=qD+GogV8-PG8+UCtEhc0K2eqS=a94NdqrBhq0oyQEA@mail.gmail.com>
On 04/04/13 17:58, Ulf Hansson wrote:
> On 4 April 2013 14:00, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 04/04/13 14:52, Ulf Hansson wrote:
>>> On 4 April 2013 13:44, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>> On 04/04/13 12:55, Ulf Hansson wrote:
>>>>> On 4 April 2013 10:46, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>>> On 01/03/13 14:47, Ulf Hansson wrote:
>>>>>>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>>>>>>
>>>>>>> The mmc_power_restore|save_host API is only used by SDIO func drivers. SDIO
>>>>>>
>>>>>> NAK - it is also used by eMMC hardware reset i.e. mmc_do_hw_reset()
>>>>>
>>>>> True for eMMC, but for SD card the bus_ops can go away. Thanks for
>>>>> spotting this Adrian!
>>>>>
>>>>> Although, I see some serious problems with the mmc_do_hw_reset
>>>>> function - it could cause eMMC data corruption.
>>>>>
>>>>> Issuing hw reset and doing re-initialization by using the mmc
>>>>> bus_ops->power_restore will mean no consideration is taken to "cache
>>>>> ctrl", "bkops" and "power off notify". I think it must.
>>>>>
>>>>> So the more proper way instead of calling power_restore, should be to
>>>>> use bus_ops->suspend and bus_ops->resume callbacks from the
>>>>> mmc_do_hw_reset function. Additionally if bus_ops->suspend is done
>>>>> successfully, we should be able to skip the actual hw reset and just
>>>>> do bus_ops->resume.
>>>>>
>>>>> Do you have any thoughts on this?
>>>>
>>>> Certainly the bootloader should leave the eMMC is a safe state including:
>>>> flushing the cache or turning it off (why did it turn on?), stopping
>>>> background operations (why did it start them?), disabling power-off
>>>> notification CMD0? (again why it it enable it?)
>>>
>>> Not sure what you mean here. What has a booloader to do with this?
>>
>> When do you think hw reset is used?
>
> Two types is being used.
>
> 1. At the mmc_rescan sequence. At this point mmc_do_hw_reset is _not_
> used. Instead mmc_hw_reset_for_init, which onlcy makes use of
> host->ops->hw_reset, no "power_restore" of course. So this has no
> issues whatsoever with this patch.
>
> 2. At blk request errors, which I thought we were discussing from the
> beginning. In this case mmc_do_hw_reset is used. And it here my
> proposals doing bus_ops->suspend|resume make sense.
>
>
>>
>>>
>>>>
>>>> Note that according to spec. CMD0 anyway clears the cache so you have lost
>>>> your data anyway.
>>>
>>> What I am saying that we can try send "cache ctrl" and "power off
>>> notify" before we send CMD0 / do hw reset. The no data shall be lost.
>>
>> With an uninitialized bus? Or an unresponsive card?
>
> See above.
>
> The bus is never uninitialized.
>
> The card has responded with an error, but that does not have to mean
> that it is completely "unresponsive".
True. Arguably caching should be disabled at the first sign of trouble
and never re-enabled.
However reset could attempt to flush the cache. Then, even if the reset is
successful, an error must still be returned if the flush failed.
next prev parent reply other threads:[~2013-04-05 8:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-01 12:47 [PATCH 0/3] mmc: Use runtime pm for blkdevice Ulf Hansson
2013-03-01 12:47 ` [PATCH 1/3] mmc: core: Remove power_restore bus_ops for mmc and sd Ulf Hansson
2013-04-03 11:08 ` merez
2013-04-04 8:46 ` Adrian Hunter
2013-04-04 9:55 ` Ulf Hansson
2013-04-04 11:44 ` Adrian Hunter
2013-04-04 11:52 ` Ulf Hansson
2013-04-04 12:00 ` Adrian Hunter
2013-04-04 14:58 ` Ulf Hansson
2013-04-05 8:50 ` Adrian Hunter [this message]
2013-03-01 12:47 ` [PATCH 2/3] mmc: core: Add bus_ops for runtime pm callbacks Ulf Hansson
2013-04-03 11:49 ` merez
2013-03-01 12:47 ` [PATCH 3/3] mmc: block: Enable runtime pm for mmc blkdevice Ulf Hansson
2013-03-04 13:48 ` Asutosh Das
2013-03-05 1:39 ` Ulf Hansson
2013-03-05 18:04 ` Asutosh Das
2013-03-06 6:57 ` Ulf Hansson
2013-04-01 8:28 ` Asutosh Das
2013-04-02 10:38 ` Ulf Hansson
2013-04-02 12:37 ` Subhash Jadavani
2013-04-03 11:50 ` merez
2013-03-02 20:00 ` [PATCH 0/3] mmc: Use runtime pm for blkdevice Maya Erez
2013-03-27 13:31 ` Chris Ball
2013-03-27 13:40 ` Arnd Bergmann
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=515E905E.8090201@intel.com \
--to=adrian.hunter@intel.com \
--cc=cjb@laptop.org \
--cc=johan.rudholm@stericsson.com \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=ulf.hansson@stericsson.com \
/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