From: Chaotian Jing <chaotian.jing-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>,
Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfram Sang
<wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Matthias Brugger
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch
Date: Fri, 13 May 2016 10:42:23 +0800 [thread overview]
Message-ID: <1463107343.26133.6.camel@mhfsdcap03> (raw)
In-Reply-To: <57345B14.7030308-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Thu, 2016-05-12 at 13:29 +0300, Adrian Hunter wrote:
> 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.
One thing must point out is that the __mmc_switch() is only for MMC
card. SD/SDIO will never use this interface.
by the way, Per JEDEC SD3.0 spec, below is the quote from spec:
"Completion of voltage switch sequence is checked by high level of
DAT[3:0]. Any bit of DAT[3:0] can be checked depends on ability of the
host."
So that the implement of ops->card_busy() can be changed from check
DAT[3:0] to only check DAT[0].
In fact, for SD/SDIO voltage switch, if switch success, all DAT pins are
high level and if switch failed, all data pins are low level.
>
WARNING: multiple messages have this Message-ID (diff)
From: chaotian.jing@mediatek.com (Chaotian Jing)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch
Date: Fri, 13 May 2016 10:42:23 +0800 [thread overview]
Message-ID: <1463107343.26133.6.camel@mhfsdcap03> (raw)
In-Reply-To: <57345B14.7030308@intel.com>
On Thu, 2016-05-12 at 13:29 +0300, Adrian Hunter wrote:
> 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.
One thing must point out is that the __mmc_switch() is only for MMC
card. SD/SDIO will never use this interface.
by the way, Per JEDEC SD3.0 spec, below is the quote from spec:
"Completion of voltage switch sequence is checked by high level of
DAT[3:0]. Any bit of DAT[3:0] can be checked depends on ability of the
host."
So that the implement of ops->card_busy() can be changed from check
DAT[3:0] to only check DAT[0].
In fact, for SD/SDIO voltage switch, if switch success, all DAT pins are
high level and if switch failed, all data pins are low level.
>
WARNING: multiple messages have this Message-ID (diff)
From: Chaotian Jing <chaotian.jing@mediatek.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
<linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>,
"Sascha Hauer" <kernel@pengutronix.de>
Subject: Re: [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch
Date: Fri, 13 May 2016 10:42:23 +0800 [thread overview]
Message-ID: <1463107343.26133.6.camel@mhfsdcap03> (raw)
In-Reply-To: <57345B14.7030308@intel.com>
On Thu, 2016-05-12 at 13:29 +0300, Adrian Hunter wrote:
> 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.
One thing must point out is that the __mmc_switch() is only for MMC
card. SD/SDIO will never use this interface.
by the way, Per JEDEC SD3.0 spec, below is the quote from spec:
"Completion of voltage switch sequence is checked by high level of
DAT[3:0]. Any bit of DAT[3:0] can be checked depends on ability of the
host."
So that the implement of ops->card_busy() can be changed from check
DAT[3:0] to only check DAT[0].
In fact, for SD/SDIO voltage switch, if switch success, all DAT pins are
high level and if switch failed, all data pins are low level.
>
next prev parent reply other threads:[~2016-05-13 2:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 6:54 [PATCH] mmc: mmc: do not use CMD13 to get status after speed mode switch Chaotian Jing
2016-05-04 6:54 ` Chaotian Jing
2016-05-04 6:54 ` Chaotian Jing
2016-05-09 3:00 ` Shawn Lin
2016-05-09 3:00 ` Shawn Lin
2016-05-11 7:50 ` Adrian Hunter
2016-05-11 7:50 ` Adrian Hunter
2016-05-12 7:00 ` Chaotian Jing
2016-05-12 7:00 ` Chaotian Jing
2016-05-12 7:00 ` Chaotian Jing
2016-05-12 10:29 ` Adrian Hunter
2016-05-12 10:29 ` Adrian Hunter
[not found] ` <57345B14.7030308-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-05-13 2:42 ` Chaotian Jing [this message]
2016-05-13 2:42 ` Chaotian Jing
2016-05-13 2:42 ` Chaotian Jing
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=1463107343.26133.6.camel@mhfsdcap03 \
--to=chaotian.jing-nus5lvnupcjwk0htik3j/w@public.gmane.org \
--cc=adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
--cc=kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
--cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org \
--cc=yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@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.