All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 08 Nov 2012 10:46:06 +0800	[thread overview]
Message-ID: <509B1CEE.6090306@marvell.com> (raw)
In-Reply-To: <20121106125253.GC27643@S2100-06.ap.freescale.net>

On 2012年11月06日 20:52, Shawn Guo wrote:
> On Tue, Nov 06, 2012 at 04:49:42PM +0800, yongd wrote:
>>  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.
>>
> I was not removing the card as slowly as you think. It's actually
> a normal speed.  That's why I thought your patch breaks the
> card-detection functionality before I found the cause.
>
>> 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:-)
>>
> I do not think it's a proper fixing.
Anyway, u can try such delay like msleep(100) in cd_irq() before calling
tasklet_schedule(&sdhost->card_tasklet). Yes, this is not a proper fix even
it works:-)
>
> <snip>
>
>> 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?
>>
> I guess what we need is to call mmc_gpio_get_cd() trying to know card's
> presence before sending MMC_SEND_STATUS command.  sdhci-esdhc-imx
> driver will surely need some changes to cope with that.
>
> Shawn
>
Yes, gpio card detection should better use the existing framework 
offered by slot-gpio.
Then the fake-card-present will be unnecessary. BTW, sdhci-s3c.c also 
dose not use slot-gpio,
and then it also adds some tricky logic for gpio detection. U can check 
sdhci_s3c_notify_change(),
which dynamically set/clear SDHCI_QUIRK_BROKEN_CARD_DETECTION. This 
patch adding
mmc_gpio_get_cd(), bec9d4e5939987053169a9bb48fc58b6a2d3e237, mentioned 
this 1stly.

But using SDHCI_QUIRK_BROKEN_CARD_DETECTION to do such judging in 
sdhci_request()
is still not proper. I think this is the root causing such above 
workarounds.

So I am thinking of adding a new operation like get_card_presence into 
sdhci_ops,
and then different host drivers can implement differently by themselves, 
eg, for
sdhci-esdhc-imx.c,

static bool esdhc_get_card_presence(struct sdhci_host *host)
{
bool present = true;

if (detection_type == ESDHC_CD_CONTROLLER)
present = sdhci_readl(host, SDHCI_PRESENT_STATE) & SDHCI_CARD_PRESENT;
else if (detection_type == ESDHC_CD_GPIO) {
if (gpio_get_value(boarddata->cd_gpio))
/* no card, if a valid gpio says so... */
present = false;
}

return present;
}


But this will also cause lots of host drivers corresponding changes. Oh, 
still inconvenient:-(
Any better ideas?


  reply	other threads:[~2012-11-08  2:46 UTC|newest]

Thread overview: 15+ 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-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
2012-11-06 12:52               ` Shawn Guo
2012-11-08  2:46                 ` yongd [this message]
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=509B1CEE.6090306@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 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.