From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752332AbdC2C2D (ORCPT ); Tue, 28 Mar 2017 22:28:03 -0400 Received: from mailgw02.mediatek.com ([218.249.47.111]:49311 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751892AbdC2C2C (ORCPT ); Tue, 28 Mar 2017 22:28:02 -0400 Message-ID: <1490754475.22814.43.camel@mhfsdcap03> Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands From: Chaotian Jing To: Ulf Hansson CC: Adrian Hunter , Matthias Brugger , Jaehoon Chung , Shawn Lin , Masahiro Yamada , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , , srv_heupstream Date: Wed, 29 Mar 2017 10:27:55 +0800 In-Reply-To: References: <1490336341-22292-1-git-send-email-chaotian.jing@mediatek.com> <1490336341-22292-2-git-send-email-chaotian.jing@mediatek.com> <13a83728-0031-5683-c371-4b517df32299@intel.com> <1490344369.22814.10.camel@mhfsdcap03> <03d54000-9ced-1b31-df80-d254f02433db@intel.com> <1490348427.22814.19.camel@mhfsdcap03> <1490578500.22814.31.camel@mhfsdcap03> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-03-28 at 11:59 +0200, Ulf Hansson wrote: > [...] > > >> 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. > > just only remove retries ? how to do error handle of CMD6 response CRC error ? > > 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. :-) We had already noticed this issue and do busy check before CMD6 was sent in our host driver. so that for me, the rest work is to do re-tune before the next cmd6... > > > > [...] > > > > Kind regards > > Uffe From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chaotian Jing Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands Date: Wed, 29 Mar 2017 10:27:55 +0800 Message-ID: <1490754475.22814.43.camel@mhfsdcap03> References: <1490336341-22292-1-git-send-email-chaotian.jing@mediatek.com> <1490336341-22292-2-git-send-email-chaotian.jing@mediatek.com> <13a83728-0031-5683-c371-4b517df32299@intel.com> <1490344369.22814.10.camel@mhfsdcap03> <03d54000-9ced-1b31-df80-d254f02433db@intel.com> <1490348427.22814.19.camel@mhfsdcap03> <1490578500.22814.31.camel@mhfsdcap03> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from mailgw02.mediatek.com ([218.249.47.111]:49311 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751892AbdC2C2C (ORCPT ); Tue, 28 Mar 2017 22:28:02 -0400 In-Reply-To: Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Ulf Hansson Cc: Adrian Hunter , Matthias Brugger , Jaehoon Chung , Shawn Lin , Masahiro Yamada , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-mediatek@lists.infradead.org, srv_heupstream On Tue, 2017-03-28 at 11:59 +0200, Ulf Hansson wrote: > [...] > > >> 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. > > just only remove retries ? how to do error handle of CMD6 response CRC error ? > > 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. :-) We had already noticed this issue and do busy check before CMD6 was sent in our host driver. so that for me, the rest work is to do re-tune before the next cmd6... > > > > [...] > > > > Kind regards > > Uffe From mboxrd@z Thu Jan 1 00:00:00 1970 From: chaotian.jing@mediatek.com (Chaotian Jing) Date: Wed, 29 Mar 2017 10:27:55 +0800 Subject: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands In-Reply-To: References: <1490336341-22292-1-git-send-email-chaotian.jing@mediatek.com> <1490336341-22292-2-git-send-email-chaotian.jing@mediatek.com> <13a83728-0031-5683-c371-4b517df32299@intel.com> <1490344369.22814.10.camel@mhfsdcap03> <03d54000-9ced-1b31-df80-d254f02433db@intel.com> <1490348427.22814.19.camel@mhfsdcap03> <1490578500.22814.31.camel@mhfsdcap03> Message-ID: <1490754475.22814.43.camel@mhfsdcap03> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2017-03-28 at 11:59 +0200, Ulf Hansson wrote: > [...] > > >> 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. > > just only remove retries ? how to do error handle of CMD6 response CRC error ? > > 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. :-) We had already noticed this issue and do busy check before CMD6 was sent in our host driver. so that for me, the rest work is to do re-tune before the next cmd6... > > > > [...] > > > > Kind regards > > Uffe