Re: [PATCH 1/1] fix card interrupt losing issue on freescale eSDHC
Lin Tony-B19295 b19...@freescale.com writes:
Hi,
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
kernel-boun...@lists.infradead.org] On Behalf Of Uwe Kleine-K?nig
Sent: Wednesday, July 27, 2011 3:47 PM
To: Lin Tony-B19295
Cc: c...@laptop.org; linux-mmc@vger.kernel.org; ker...@pengutronix.de;
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/1] fix card interrupt losing issue on freescale
eSDHC
Hello Tony,
On Mon, Jul 18, 2011 at 01:20:02PM +0800, Tony Lin wrote:
apply workaround for imx eSDHC controller to avoid missing card
interrupt so that SDIO function is workable
Fixing a few typos (but note, I'm not a native speaker):
mmc/sdhci-esdhc-imx: fix losing card interrupt
Apply workaround for the imx eSDHC controller to avoid missing a
card interrupt.
Signed-off-by: ...
Signed-off-by: Tony Lin tony@freescale.com
---
drivers/mmc/host/sdhci-esdhc-imx.c | 39 +++-
---
1 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index a19967d..da77cae 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -32,6 +32,8 @@
#define SDHCI_VENDOR_SPEC_SDIO_QUIRK 0x0002
#define ESDHC_FLAG_GPIO_FOR_CD_WP (1 0)
+
+#define SDHCI_CTRL_D3CD 0x08
/*
* The CMDTYPE of the CMD register (offset 0xE) should be set to
* 11 when the STOP CMD12 is issued on imx53 to abort one @@ -87,14
+89,31 @@ static void esdhc_writel_le(struct sdhci_host *host, u32
val, int reg) {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct pltfm_imx_data *imx_data = pltfm_host-priv;
-
- if (unlikely((reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE)
- (imx_data-flags ESDHC_FLAG_GPIO_FOR_CD_WP)))
- /*
- * these interrupts won't work with a custom card_detect gpio
- * (only applied to mx25/35)
- */
- val = ~(SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT);
+ u32 data;
+
+ if (unlikely((reg == SDHCI_INT_ENABLE || reg ==
SDHCI_SIGNAL_ENABLE))) {
+ if (imx_data-flags ESDHC_FLAG_GPIO_FOR_CD_WP)
+ /*
+ * these interrupts won't work with a custom
+ * card_detect gpio (only applied to mx25/35)
hmm, ok, this was here before, but I wonder about the only applied to
mx25/35 part. How is that meant? I don't see logic to prevent other socs
using this workaround.
Sorry, not so sure about mx25/35 history. But the flag is set only if it's
mx25 or mx35.
You can check the code in esdhc_pltfm_init.
btw, I didn't notice when looking at the patch but this flag has been
renamed and maybe will be gone. See :
- latest commits on this file on mmc for-next:
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=e8cd77e467f7bb1d4b942037c47b087334a484d4
- last patch of the imx mmc fixes for cd/wp:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/052743.html
So, imho, it would be better to use an other way to check for mx25/35 as
current one won't work (at least won't compile but won't work as
intended if the last patch mentionned is merged. There are other systems
using gpio for cd or wp which are not mx25/35).
Arnaud
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Extend sdhci-esdhc-imx card_detect and write_protect support for mx5
Shawn Guo shawn@freescale.com writes: Hi Arnaud, Hi, Would you please give a test on the series, as it fixed the issue you reported? TIA. I've tested it yesterday on my efika platforms and the issue is gone. Moreover, the differents card slot on theses platforms are using each card detect type (internally connected, gpio, no card detect) and they are all working as expected. I'm a little bit annoyed by the polling on the slot without card detect but this has nothing to do with this patchset. Side note: turns out that the driver is using dev_warn when failing to get cd gpio/irq. Given that in theses cases, it jumps to no_card_detect_pin and makes the probe fail, maybe a dev_err would be better ? Tested-by: Arnaud Patard arnaud.pat...@rtp-net.org Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Extend sdhci-esdhc-imx card_detect and write_protect support for mx5
Shawn Guo shawn@freescale.com writes: Hi, On Fri, Jun 10, 2011 at 06:42:48PM +0800, Shawn Guo wrote: The card-present polling within sdhci based driver is very expensive in terms of the impact to system performance. We observe a few system performance issues from Freescale and Linaro on mx5 platforms, which have been proved card polling related. The patch set extends the current sdhci-esdhc-imx card_detect and write_protect support to cover mx5 platforms, and solves above performance issues. Shawn Guo (4): mmc: sdhci: fix interrupt storm from card detection mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared mmc: sdhci-esdhc-imx: remove WP from flag ESDHC_FLAG_GPIO_FOR_CD_WP mmc: sdhci-esdhc-imx: extend card_detect and write_protect support Hi Arnaud, Any chance to play with it yet? Finally managed to build a kernel with this version of the patchset. While I'm not polling anymore, I'm getting a lot of interrupts if the card is not inserted. Theses interrupts are not happening if the card is inserted. I can see things like this in the logs : sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0080 [ of course, the bit of the present state register indicating card presence is equal to 0 ] I've tested the SIGNAL case only. Don't know if switch to GPIO may help. Do you have same kind of issue on your side ? Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Extend sdhci-esdhc-imx card_detect and write_protect support for mx5
Shawn Guo shawn@freescale.com writes: Hi, On Fri, Jun 10, 2011 at 06:42:48PM +0800, Shawn Guo wrote: The card-present polling within sdhci based driver is very expensive in terms of the impact to system performance. We observe a few system performance issues from Freescale and Linaro on mx5 platforms, which have been proved card polling related. The patch set extends the current sdhci-esdhc-imx card_detect and write_protect support to cover mx5 platforms, and solves above performance issues. Shawn Guo (4): mmc: sdhci: fix interrupt storm from card detection mmc: sdhci-esdhc-imx: SDHCI_CARD_PRESENT does not get cleared mmc: sdhci-esdhc-imx: remove WP from flag ESDHC_FLAG_GPIO_FOR_CD_WP mmc: sdhci-esdhc-imx: extend card_detect and write_protect support Hi Arnaud, Any chance to play with it yet? I tried applying the patch 4 (v2) on mmc git and Sascha Hauer's for-next branch and failed. Can you please tell me on which tree should I apply it ? Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: sdhci-esdhc-imx: extend card_detect and write_protect support
Shawn Guo shawn@linaro.org writes: Hi, The patch extends card_detect and write_protect support to get mx5 family and more scenarios supported. The changes include: * Turn platform_data from optional to mandatory * Add cd_types and wp_types into platform_data to cover more use cases * Remove the use of flag ESDHC_FLAG_GPIO_FOR_CD * Adjust machine codes to adopt the platform_data changes Before I go and test theses patches, I'd like to get some clarification. From what I see, you've modified all over the place the code to provide a platform_data, setting wp/cd type to type NONE, as if it was the default you choose. Why this default and not considerer the SIGNAL type being the default ? Is this choice the safest one when one doesn't know what type to choose or can it have some bad side effects ? Also, why didn't you modify the imx*_add_sdhci_esdhc_imx() functions to provide the default platform_data by themselves that if the 2nd argument was NULL instead of modifying all theses machines files ? Last comment: How did you choose the platform_data values ? I mean, for that the cases I'm mainly take care of (efika mx and sb platforms), you choose NONE type, while the code has : MX51_PAD_GPIO1_0__SD1_CD, MX51_PAD_GPIO1_1__SD1_WP, MX51_PAD_GPIO1_7__SD2_WP, MX51_PAD_GPIO1_8__SD2_CD, which means that it would rather be the SIGNAL type if I got it right. Does this mean that you've set the type to NONE for all platforms you didn't know what the answer was ? (I guess/hope that theses 2 questions will be answered by your answers to my previous questions tbh). Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Eric Benard e...@eukrea.com writes: Hi Arnaud, Salut ! On 24/02/2011 12:40, Arnaud Patard (Rtp) wrote: Wolfram Sangw.s...@pengutronix.de writes: Hi, Take #3, changes: * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25) * remove unconditional BROKEN_CARD_DETECTION (leftover) * improved kernel-doc about unused GPIO * added tags from Eric Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a chance to retest on mx51? What about the FSL guys? :) I'm getting a hard freeze on my efika sb and mx once I remove the unconditional BROKEN_CARD_DETECTION flag. I'm still investigating the issue. I'll keep you informed if I find something. may you please test the attached patch. It may give someone with a better knowledge of sdhci than me an idea of what is wrong. I've tested this patch on my efikamx and this patch does solve the issue. I didn't test on the efika smartbook but I guess it'll be fine here too. Thanks. Here are the workaround this patch add : - we can't let enable or disable irq enabled when the card is present/not present, else the irq triger again which explains why you get the freeze - so we must rely on the card presence bit to enable the right interrupt, so, we're getting an interrupt storm, right ? can't it be fixed by setting a different irq type ? - we can't turn the clock off if we want the card detect to work when the card is removed - as a quick workaround this patch prevents sdhci_set_clock from turning off the clocks when the SDHCI_INT_CARD_INSERT interrupt is enabled. Also, I had to change the MX51_PAD_GPIO1_0__SD1_CD pad setting as follows to enable the internal pull up : _MX51_PAD_GPIO1_0__SD1_CD | MUX_PAD_CTRL(PAD_CTL_PUS_22K_UP | PAD_CTL_PKE | PAD_CTL_SRE_FAST | PAD_CTL_DSE_HIGH | PAD_CTL_PUE | PAD_CTL_HYS), It worked without changing this. Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Wolfram Sang w.s...@pengutronix.de writes: Hi, Take #3, changes: * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25) * remove unconditional BROKEN_CARD_DETECTION (leftover) * improved kernel-doc about unused GPIO * added tags from Eric Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a chance to retest on mx51? What about the FSL guys? :) I'm getting a hard freeze on my efika sb and mx once I remove the unconditional BROKEN_CARD_DETECTION flag. I'm still investigating the issue. I'll keep you informed if I find something. Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Wolfram Sang w.s...@pengutronix.de writes: Hi, Hi, Second version of my series, no major changes: * rephrased warnings * collected some tags * rebased to mmc/mmc-next as of today Eric wanted to tested these patches soonish. Thanks to Marc for testing the first three already. Has this been tested on imx51 ? By default (even after applying your patches), the sdhci has quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION set, so we're polling. I've been wondering if it was a good idea to configure for everyone sdhc host card detect pin as gpio 1 1 or gpio 1 8 on imx51, which would mean no more polling. What do you think ? Would it be working or it's just a stupid idea ? Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] SD/MMC driver for MX25/35/51
Wolfram Sang w.s...@pengutronix.de writes: Hi, On Wed, Oct 13, 2010 at 11:28:15AM +0200, Arnaud Patard wrote: it's actually not yet supported by the driver. There is a wp_gpio in struct esdhc_platform_data (arch/arm/plat-mxc/include/mach/esdhc.h) but it's not yet used by the driver. It's all prepared. I finally will have a look into it today. oh, great. I was thinking about doing it but I'll wait for your patches then. I'm sure I need support for WP on GPIO but I may also need support for CD on GPIO so I'll be happy to test any patch you have. Just to keep you updated: Got a bit distracted again but I hope to finish it on Saturday. Looks like a patch for the gpiolib is also needed... ok. Take your time. It turns out that the infos I had were a bit misleading. I've been told the mmc driver was using some gpios and the gpios are GPIO_1_0/1_1 and GPIO_1_7/1_8... which are in fact the esdhc1 and esdhc2 CD and WP. This means : - with proper iomux configuration, WP detection is working fine - I should still be able to test WP on GPIO Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] SD/MMC driver for MX25/35/51
Wolfram Sang w.s...@pengutronix.de writes: Hi, On Wed, Oct 13, 2010 at 10:15:04AM +0200, Eric Bénard wrote: I've tried it on a efika mx (to2 version) and I've a problem with the write-protect. It's on a GPIO and I don't see any way to configure the esdhc-imx driver to use it. Any idea on how it should be done ? it's actually not yet supported by the driver. There is a wp_gpio in struct esdhc_platform_data (arch/arm/plat-mxc/include/mach/esdhc.h) but it's not yet used by the driver. It's all prepared. I finally will have a look into it today. oh, great. I was thinking about doing it but I'll wait for your patches then. I'm sure I need support for WP on GPIO but I may also need support for CD on GPIO so I'll be happy to test any patch you have. Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] SD/MMC driver for MX25/35/51
Wolfram Sang w.s...@pengutronix.de writes: Hi, Here is the hopefully final (famous last words) version of my patch series. The first four are still updates/improvements for sdhci and sdhci-pltfm and are of generic interest, too. Thanks to Eric for the tests on MX25/35. Looking forward to comments/applied-to-mmc-next-messages ;) The series is based on mmc-next as of today and also available at git://git.pengutronix.de/git/wsa/linux-2.6.git pcm043-mmc I've tried it on a efika mx (to2 version) and I've a problem with the write-protect. It's on a GPIO and I don't see any way to configure the esdhc-imx driver to use it. Any idea on how it should be done ? thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
