From: yongd <yongd@marvell.com>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: Chris Ball <cjb@laptop.org>,
Anton Vorontsov <anton.vorontsov@linaro.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Wolfram Sang <w.sang@pengutronix.de>,
Daniel Drake <dsd@laptop.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Wilson Callan <wilson.callan@savantsystems.com>,
Ben Dooks <ben-linux@fluff.org>, Zhangfei Gao <zgao6@marvell.com>,
Kevin Liu <kliu5@marvell.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 1/3] mmc: esdhc: enable polling to detect card by itself
Date: Tue, 06 Nov 2012 16:49:42 +0800 [thread overview]
Message-ID: <5098CF26.3060202@marvell.com> (raw)
In-Reply-To: <20121105124809.GA27260@S2100-06.ap.freescale.net>
On 2012年11月05日 20:48, Shawn Guo wrote:
> On Mon, Nov 05, 2012 at 11:34:49AM +0800, yongd wrote:
>> From the code logic, without SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, when your card (using
>> GPIO detection) is removed, we can know the card's absence through the fake CARD_PRESENT flag in esdhc_readl_le().
>> As a result, we can quickly return ENOMEDIUM error without command sending. Finally mmc_rescan can know the card
>> is removed.
>>
> Yes, that's the existing implementation, which does not require retry
> sending MMC_SEND_STATUS to know if card is removed.
>
>> On the other hand, with SDHCI_QUIRK_BROKEN_CARD_DETECTION for ESDHC_CD_GPIO, we will just send MMC_SEND_STATUS
>> command (cd_irq->sdhci_tasklet_card->mmc_recan->mmc_sd_detect->mmc_sd_alive), and we will find error since the card
>> is already gone. Finally, we shall also know the card is removed.
>>
>> This is really strange why the removal message shows up together with the next card inserting message.
>> Could u pls tell us more about what actually happened when the card is removed with my patches? Did the GPIO interrupt
>> happen? Was mmc_rescan() called? Did mmc_sd_detect() finally find error when it sent MMC_SEND_STATUS? What step did
>> the card removing procedure arrive at? Really really thanks a lot:-)
>>
> I just tracked it down a little bit. Interesting enough, it depends on
> how I remove the card. If I do it slowly, when the gpio interrupt
> triggers the MMC_SEND_STATUS query, the command can still retrieve
> the card status successfully. Thus driver does not detect the card
> removal. If I remove the card from slot quickly, I can see the removal
> message.
Shawn,
Thanks for your interesting input.
From your info, we can see that on your platform, those pins (including
power, clk, DATA) necessary for MMC_SEND_STATUS transaction still keep
connected for some time just after the GPIO's level changes due to card
removable. And if we remove the card very slowly, such time duration can be
such long that the MMC_SEND_STATUS query can still succeed.
So I think we can add a proper delay(maybe 100ms) before the gpio interrupt
triggers the MMC_SEND_STATUS query, and maybe this can probably fix this issue:-)
> With your patch series, in ESDHC_CD_GPIO case the driver will have
> to send MMC_SEND_STATUS (with retry) to card for knowing its presence.
> This is also an unpleasant behavior comparing to the existing code.
> I think we should query gpio state to know card presence for this case.
>
> Shawn
>
Anyway, I 100% agree with you that for a ESDHC_CD_GPIO card, we shall query gpio
state to know such card's presence rather than sending MMC_SEND_STATUS rudely.
But just as I mentioned before, I don't think using SDHCI_QUIRK_BROKEN_CARD_DETECTION
as the flag to determine whether and how we can know card's presence before sending
command is a proper way.
I haven't gotten any good idea. Do u have any idea on this?
next prev parent reply other threads:[~2012-11-06 8:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 9:30 [PATCH V2 0/3] mmc: remove MMC_CAP_NEEDS_POLL setting in sdhci_add_host yongd
2012-10-30 9:30 ` [PATCH V2 1/3] mmc: esdhc: enable polling to detect card by itself yongd
2012-10-31 15:20 ` Shawn Guo
2012-11-02 12:37 ` yongd
2012-11-05 1:54 ` Shawn Guo
2012-11-05 3:34 ` yongd
2012-11-05 12:48 ` Shawn Guo
2012-11-06 8:49 ` yongd [this message]
2012-11-06 12:52 ` Shawn Guo
2012-11-08 2:46 ` yongd
2012-10-30 9:30 ` [PATCH V2 2/3] mmc: sdhci-s3c: " yongd
2012-10-30 23:11 ` [PATCH V2 0/3] mmc: remove MMC_CAP_NEEDS_POLL setting in sdhci_add_host Anton Vorontsov
2012-10-31 10:07 ` yongd
2012-10-31 10:14 ` yongd
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=5098CF26.3060202@marvell.com \
--to=yongd@marvell.com \
--cc=anton.vorontsov@linaro.org \
--cc=ben-linux@fluff.org \
--cc=cjb@laptop.org \
--cc=dsd@laptop.org \
--cc=kliu5@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@linaro.org \
--cc=w.sang@pengutronix.de \
--cc=wilson.callan@savantsystems.com \
--cc=zgao6@marvell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).