All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chaotian Jing <chaotian.jing@mediatek.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	srv_heupstream <srv_heupstream@mediatek.com>
Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands
Date: Wed, 29 Mar 2017 10:27:55 +0800	[thread overview]
Message-ID: <1490754475.22814.43.camel@mhfsdcap03> (raw)
In-Reply-To: <CAPDyKFo=DwzUqFZzh0tcRiYg6GagL8VrXwpd6PyfdZ+qkYgXqw@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Chaotian Jing <chaotian.jing@mediatek.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org,
	srv_heupstream <srv_heupstream@mediatek.com>
Subject: Re: [PATCH] mmc: core: Do not hold re-tuning during CMD6 commands
Date: Wed, 29 Mar 2017 10:27:55 +0800	[thread overview]
Message-ID: <1490754475.22814.43.camel@mhfsdcap03> (raw)
In-Reply-To: <CAPDyKFo=DwzUqFZzh0tcRiYg6GagL8VrXwpd6PyfdZ+qkYgXqw@mail.gmail.com>

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



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: core: Do not hold re-tuning during CMD6 commands
Date: Wed, 29 Mar 2017 10:27:55 +0800	[thread overview]
Message-ID: <1490754475.22814.43.camel@mhfsdcap03> (raw)
In-Reply-To: <CAPDyKFo=DwzUqFZzh0tcRiYg6GagL8VrXwpd6PyfdZ+qkYgXqw@mail.gmail.com>

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

  reply	other threads:[~2017-03-29  2:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24  6:18 mmc: core: Do not hold re-tuning during CMD6 commands Chaotian Jing
2017-03-24  6:18 ` Chaotian Jing
2017-03-24  6:18 ` Chaotian Jing
2017-03-24  6:19 ` [PATCH] " Chaotian Jing
2017-03-24  6:19   ` Chaotian Jing
2017-03-24  6:19   ` Chaotian Jing
2017-03-24  7:52   ` Adrian Hunter
2017-03-24  7:52     ` Adrian Hunter
2017-03-24  7:52     ` Adrian Hunter
2017-03-24  8:32     ` Chaotian Jing
2017-03-24  8:32       ` Chaotian Jing
2017-03-24  8:32       ` Chaotian Jing
2017-03-24  9:19       ` Adrian Hunter
2017-03-24  9:19         ` Adrian Hunter
2017-03-24  9:40         ` Chaotian Jing
2017-03-24  9:40           ` Chaotian Jing
2017-03-24  9:40           ` Chaotian Jing
2017-03-24 10:49           ` Ulf Hansson
2017-03-24 10:49             ` Ulf Hansson
2017-03-24 10:49             ` Ulf Hansson
2017-03-27  1:35             ` Chaotian Jing
2017-03-27  1:35               ` Chaotian Jing
2017-03-27  1:35               ` Chaotian Jing
2017-03-28  8:30               ` Ulf Hansson
2017-03-28  8:30                 ` Ulf Hansson
2017-03-28  8:30                 ` Ulf Hansson
2017-03-28  9:01                 ` Adrian Hunter
2017-03-28  9:01                   ` Adrian Hunter
2017-03-28  9:01                   ` Adrian Hunter
2017-03-28  9:58                   ` Ulf Hansson
2017-03-28  9:58                     ` Ulf Hansson
2017-03-28  9:58                     ` Ulf Hansson
2017-03-28  9:59                     ` Ulf Hansson
2017-03-28  9:59                       ` Ulf Hansson
2017-03-28  9:59                       ` Ulf Hansson
2017-03-29  2:27                       ` Chaotian Jing [this message]
2017-03-29  2:27                         ` Chaotian Jing
2017-03-29  2:27                         ` Chaotian Jing
2017-03-28  9:59                   ` Chaotian Jing
2017-03-28  9:59                     ` Chaotian Jing
2017-03-28  9:59                     ` Chaotian Jing
2017-03-29 10:33                 ` Ulf Hansson
2017-03-29 10:33                   ` Ulf Hansson
2017-03-29 10:33                   ` Ulf Hansson
2017-03-29 10:36                   ` Chaotian Jing
2017-03-29 10:36                     ` Chaotian Jing
2017-03-29 10:36                     ` 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=1490754475.22814.43.camel@mhfsdcap03 \
    --to=chaotian.jing@mediatek.com \
    --cc=adrian.hunter@intel.com \
    --cc=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=ulf.hansson@linaro.org \
    --cc=yamada.masahiro@socionext.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 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.