[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFo=DwzUqFZzh0tcRiYg6GagL8VrXwpd6PyfdZ+qkYgXqw@mail.gmail.com>
Date: Tue, 28 Mar 2017 11:59:48 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Adrian Hunter <adrian.hunter@...el.com>
Cc: Chaotian Jing <chaotian.jing@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
Jaehoon Chung <jh80.chung@...sung.com>,
Shawn Lin <shawn.lin@...k-chips.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
linux-mediatek@...ts.infradead.org,
srv_heupstream <srv_heupstream@...iatek.com>
Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands
[...]
>> The retry mechanism provided by mmc_wait_for_cmd() and friends really only
>> makes sense for simple commands. In other cases, like this, we need to
>> consider what state the card is in. For __mmc_switch we need to consider
>> whether the card is busy or whether a timing change been made.
>
> I definitely agree. We should remove retries for CMD6 and perhaps also
> for some other cases.
>
> When we have changed the above in __mmc_switch(), the change Chaotian
> suggest gets a different impact, as it would potentially allow a
> re-tuning to happen before the next CMD1to poll for busy or to check
/s/CMD1/CMD13
> the switch status. This isn't okay.
>
> This all sounds to me that Chaotian's issue may not all be related to
> tuning, but to the CMD6 switch sequence itself. However I may be wrong
> - of course. :-)
>
> [...]
>
> Kind regards
> Uffe
Powered by blists - more mailing lists