Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1399890

Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch

From Adrian Hunter <adrian.hunter@intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch
Date 2016-05-12 12:40 +0200
Message-ID <rxWc9-3K2-1@gated-at.bofh.it> (permalink)
References <ruYWS-7f4-5@gated-at.bofh.it> <rxxdM-3FS-13@gated-at.bofh.it> <rxSUX-MD-25@gated-at.bofh.it>
Organization Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki

Show all headers | View raw


On 12/05/16 10:00, Chaotian Jing wrote:
> On Wed, 2016-05-11 at 10:50 +0300, Adrian Hunter wrote:
>> On 04/05/16 09:54, Chaotian Jing wrote:
>>> Per JEDEC spec, it is not recommended to use CMD13 to get card status
>>> after speed mode switch. below are two reason about this:
>>> 1. CMD13 cannot be guaranteed due to the asynchronous operation.
>>> Therefore it is not recommended to use CMD13 to check busy completion
>>> of the timing change indication.
>>> 2. After switch to HS200, CMD13 will get response of 0x800, and even the
>>> busy signal gets de-asserted, the response of CMD13 is aslo 0x800.
>>>
>>> this patch drops CMD13 when doing speed mode switch, if host do not
>>> support MMC_CAP_WAIT_WHILE_BUSY and there is no ops->card_busy(),
>>> then the only way is to wait a fixed timeout.
>>
>> This looks like it should be 3 patches:
>> 	1. Change __mmc_switch
>> 	2. Change HS200 and HS400 selection
>> 	3. Change HS selection
>>
>> However there is another problem: card_busy is not the same as busy signal -
>> see below.  So that needs to be sorted out first.
>>
> We should make that card_busy() is the same with busy signal asserted.
> as you know, if card was not in busy state, all data pins should be high
> level as it is pull-up by default. so that's no conflict to check card
> busy signal by DAT0 or DAT0 ~ DAT3.

Potentially SDIO uses DAT1 for card interrupt, so that is a conflict right
there.

Also SDHCI does it backwards (don't ask me why) and considers 0000 to be
busy, so there's another conflict.

Some of the language in the SD and SDHCI specifications seems to indicate
that checking all 4 DAT lines during voltage switch is optional i.e. only 1
of the lines must be checked.  If that is true then we could change all the
drivers over to check just DAT0, and expect that to work for both busy
signalling and SD voltage switch checks.

So it seems to me card_busy still needs to be sorted out first.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch Chaotian Jing <chaotian.jing@mediatek.com> - 2016-05-04 09:00 +0200
  Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode  switch Shawn Lin <shawn.lin@rock-chips.com> - 2016-05-09 05:10 +0200
  Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode  switch Adrian Hunter <adrian.hunter@intel.com> - 2016-05-11 10:00 +0200
    Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed  mode switch Chaotian Jing <chaotian.jing@mediatek.com> - 2016-05-12 09:10 +0200
      Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode  switch Adrian Hunter <adrian.hunter@intel.com> - 2016-05-12 12:40 +0200
        Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed  mode switch Chaotian Jing <chaotian.jing@mediatek.com> - 2016-05-13 04:50 +0200

csiph-web