RE: mwifiex card reset
Hi James, > On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote: > > I may have missed something, but doesn't the MMC_POWER_OFF and > > MMC_POWER_ON|UP handling in controller driver help? > > Anyway the clocks/GPIOs/regulators are sort of platform dependent. > > Would it be better putting it in /arch/arm/mach-x/? > > Wouldn't device tree for mmc be better? Yes, device tree is better for defining clocks/GPIO/regulators, etc. But I guess the reset logic (making use of these definitions) cannot be device tree? Regards, Bing > > -- > James Cameron > http://quozl.linux.org.au/ -- 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: mwifiex card reset
Hi Daniel, > > OK so we can't do much anything at mwifiex probe time on SDIO bus > > because it won't probe unless the pins are configured. > > > > Maybe we should have a separate mwifiex-power helper module that just > > manages the reset/idle/regulator pins? Then mwifiex-reset can be > > always loaded and configure things so mwifiex-sdio can probe properly. > > > > And mwifiex-reset helper can also provide the user space interfaces > > for the reset/idle/regulator pins. > > Yes, a helper might be the best solution. It could even be a generic one, that > just takes any number of clocks, reset GPIOs and regulators and takes care > for sequencing them. However, we need to reference that helper from the > mwifiex driver, for two reasons. > > a) we need to make sure the reset helper gets to do its job before the > mwifiex driver scans the SDIO bus, and > > b) the reset helper needs to be called when the mmc host controller wants > to do a card reset. > > Hence, we'll need some sort of internal API for this, and a phandle in dts. I > wonder whether that glue logic might be better off living in the mmc core, as > mwifiex might well be interfaced to other hosts? I may have missed something, but doesn't the MMC_POWER_OFF and MMC_POWER_ON|UP handling in controller driver help? Anyway the clocks/GPIOs/regulators are sort of platform dependent. Would it be better putting it in /arch/arm/mach-x/? Thanks, Bing > > > Thanks, > Daniel
RE: [PATCH v3] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Hi Chris,
> Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
> SD8797 card. Add a quirk to handle this case. The fixup here is
> to issue a dummy CMD52 read to function 0 register 0xff, and this
> dummy read must be right after SDIO_CCCR_INTx is read.
>
> Patch has been verified on a dw_mmc controller (Samsung Chromebook)
> with MMC_CAP_SDIO_IRQ disabled.
Could you please review this patch?
Thanks,
Bing
>
> Reviewed-by: Paul Stewart
> Reviewed-by: Doug Anderson
> Signed-off-by: Bing Zhao
> Acked-by: Ulf Hansson
> ---
> v2: remove mmc_fixup_broken_irq_polling() and add inline
> mmc_card_broken_irq_polling(). (Ulf Hansson)
> invoke the quirk handling after 'ret' value is validated.
> v3: remove unnecessary include for sdio_ops.h (Ulf Hansson)
>
> drivers/mmc/core/quirks.c | 8
> drivers/mmc/core/sdio_irq.c | 11 +++
> include/linux/mmc/card.h| 8 +++-
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c
> index 06ee1ae..6c36fcc 100644
> --- a/drivers/mmc/core/quirks.c
> +++ b/drivers/mmc/core/quirks.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #ifndef SDIO_VENDOR_ID_TI
> #define SDIO_VENDOR_ID_TI0x0097
> @@ -30,6 +31,10 @@
> #define SDIO_DEVICE_ID_STE_CW12000x2280
> #endif
>
> +#ifndef SDIO_DEVICE_ID_MARVELL_8797_F0
> +#define SDIO_DEVICE_ID_MARVELL_8797_F0 0x9128
> +#endif
> +
> /*
> * This hook just adds a quirk for all sdio devices
> */
> @@ -58,6 +63,9 @@ static const struct mmc_fixup mmc_fixup_methods[] = {
> SDIO_FIXUP(SDIO_VENDOR_ID_STE, SDIO_DEVICE_ID_STE_CW1200,
> add_quirk, MMC_QUIRK_BROKEN_BYTE_MODE_512),
>
> + SDIO_FIXUP(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8797_F0,
> +add_quirk, MMC_QUIRK_BROKEN_IRQ_POLLING),
> +
> END_FIXUP
> };
>
> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
> index 3d8ceb4..417d2f0 100644
> --- a/drivers/mmc/core/sdio_irq.c
> +++ b/drivers/mmc/core/sdio_irq.c
> @@ -53,6 +53,17 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
> return ret;
> }
>
> + if (pending && mmc_card_broken_irq_polling(card) &&
> + !(host->caps & MMC_CAP_SDIO_IRQ)) {
> + unsigned char dummy;
> +
> + /* A fake interrupt could be created when we poll SDIO_CCCR_INTx
> + * register with a Marvell SD8797 card. A dummy CMD52 read to
> + * function 0 register 0xff can aviod this.
> + */
> + mmc_io_rw_direct(card, 0, 0, 0xff, 0, &dummy);
> + }
> +
> count = 0;
> for (i = 1; i <= 7; i++) {
> if (pending & (1 << i)) {
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 176fdf8..b730272 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -271,9 +271,10 @@ struct mmc_card {
> #define MMC_QUIRK_INAND_CMD38(1<<6) /* iNAND devices have
> broken CMD38 */
> #define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for
> regular multiblock */
> #define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8)/* Avoid sending 512
> bytes in */
> + /* byte mode */
> #define MMC_QUIRK_LONG_READ_TIME (1<<9) /* Data read time > CSD
> says */
> #define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10) /* Skip secure for
> erase/trim */
> - /* byte mode */
> +#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could
> create a fake
> interrupt */
>
> unsigned interase_size; /* erase size in sectors */
> unsigned interase_shift;/* if erase unit is power 2 */
> @@ -505,6 +506,11 @@ static inline int mmc_card_long_read_time(const struct
> mmc_card *c)
> return c->quirks & MMC_QUIRK_LONG_READ_TIME;
> }
>
> +static inline int mmc_card_broken_irq_polling(const struct mmc_card *c)
> +{
> + return c->quirks & MMC_QUIRK_BROKEN_IRQ_POLLING;
> +}
> +
> #define mmc_card_name(c) ((c)->cid.prod_name)
> #define mmc_card_id(c) (dev_name(&(c)->dev))
>
> --
> 1.8.0
--
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
[PATCH v3] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
SD8797 card. Add a quirk to handle this case. The fixup here is
to issue a dummy CMD52 read to function 0 register 0xff, and this
dummy read must be right after SDIO_CCCR_INTx is read.
Patch has been verified on a dw_mmc controller (Samsung Chromebook)
with MMC_CAP_SDIO_IRQ disabled.
Reviewed-by: Paul Stewart
Reviewed-by: Doug Anderson
Signed-off-by: Bing Zhao
Acked-by: Ulf Hansson
---
v2: remove mmc_fixup_broken_irq_polling() and add inline
mmc_card_broken_irq_polling(). (Ulf Hansson)
invoke the quirk handling after 'ret' value is validated.
v3: remove unnecessary include for sdio_ops.h (Ulf Hansson)
drivers/mmc/core/quirks.c | 8
drivers/mmc/core/sdio_irq.c | 11 +++
include/linux/mmc/card.h| 8 +++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c
index 06ee1ae..6c36fcc 100644
--- a/drivers/mmc/core/quirks.c
+++ b/drivers/mmc/core/quirks.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#ifndef SDIO_VENDOR_ID_TI
#define SDIO_VENDOR_ID_TI 0x0097
@@ -30,6 +31,10 @@
#define SDIO_DEVICE_ID_STE_CW1200 0x2280
#endif
+#ifndef SDIO_DEVICE_ID_MARVELL_8797_F0
+#define SDIO_DEVICE_ID_MARVELL_8797_F0 0x9128
+#endif
+
/*
* This hook just adds a quirk for all sdio devices
*/
@@ -58,6 +63,9 @@ static const struct mmc_fixup mmc_fixup_methods[] = {
SDIO_FIXUP(SDIO_VENDOR_ID_STE, SDIO_DEVICE_ID_STE_CW1200,
add_quirk, MMC_QUIRK_BROKEN_BYTE_MODE_512),
+ SDIO_FIXUP(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8797_F0,
+ add_quirk, MMC_QUIRK_BROKEN_IRQ_POLLING),
+
END_FIXUP
};
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 3d8ceb4..417d2f0 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -53,6 +53,17 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
return ret;
}
+ if (pending && mmc_card_broken_irq_polling(card) &&
+ !(host->caps & MMC_CAP_SDIO_IRQ)) {
+ unsigned char dummy;
+
+ /* A fake interrupt could be created when we poll SDIO_CCCR_INTx
+* register with a Marvell SD8797 card. A dummy CMD52 read to
+* function 0 register 0xff can aviod this.
+*/
+ mmc_io_rw_direct(card, 0, 0, 0xff, 0, &dummy);
+ }
+
count = 0;
for (i = 1; i <= 7; i++) {
if (pending & (1 << i)) {
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 176fdf8..b730272 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -271,9 +271,10 @@ struct mmc_card {
#define MMC_QUIRK_INAND_CMD38 (1<<6) /* iNAND devices have broken
CMD38 */
#define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for regular
multiblock */
#define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8) /* Avoid sending 512 bytes in */
+ /* byte mode */
#define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD
says */
#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10)/* Skip secure for
erase/trim */
- /* byte mode */
+#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could
create a fake interrupt */
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
@@ -505,6 +506,11 @@ static inline int mmc_card_long_read_time(const struct
mmc_card *c)
return c->quirks & MMC_QUIRK_LONG_READ_TIME;
}
+static inline int mmc_card_broken_irq_polling(const struct mmc_card *c)
+{
+ return c->quirks & MMC_QUIRK_BROKEN_IRQ_POLLING;
+}
+
#define mmc_card_name(c) ((c)->cid.prod_name)
#define mmc_card_id(c) (dev_name(&(c)->dev))
--
1.8.0
--
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] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Hi Ulf, > > diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c > > index 06ee1ae..02c94b5 100644 > > --- a/drivers/mmc/core/quirks.c > > +++ b/drivers/mmc/core/quirks.c > > @@ -13,6 +13,9 @@ > > #include > > #include > > #include > > +#include > > + > > +#include "sdio_ops.h" > > So these includes is not needed any more, I guess. Yes, you are right. It will be fixed in v3. Thanks, Bing -- 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
[PATCH v2] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
SD8797 card. Add a quirk to handle this case. The fixup here is
to issue a dummy CMD52 read to function 0 register 0xff, and this
dummy read must be right after SDIO_CCCR_INTx is read.
Patch has been verified on a dw_mmc controller (Samsung Chromebook)
with MMC_CAP_SDIO_IRQ disabled.
Reviewed-by: Paul Stewart
Reviewed-by: Doug Anderson
Signed-off-by: Bing Zhao
---
v2: remove mmc_fixup_broken_irq_polling() and add inline
mmc_card_broken_irq_polling(). (Ulf Hansson)
invoke the quirk handling after 'ret' value is validated.
drivers/mmc/core/quirks.c | 10 ++
drivers/mmc/core/sdio_irq.c | 11 +++
include/linux/mmc/card.h| 8 +++-
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c
index 06ee1ae..02c94b5 100644
--- a/drivers/mmc/core/quirks.c
+++ b/drivers/mmc/core/quirks.c
@@ -13,6 +13,9 @@
#include
#include
#include
+#include
+
+#include "sdio_ops.h"
#ifndef SDIO_VENDOR_ID_TI
#define SDIO_VENDOR_ID_TI 0x0097
@@ -30,6 +33,10 @@
#define SDIO_DEVICE_ID_STE_CW1200 0x2280
#endif
+#ifndef SDIO_DEVICE_ID_MARVELL_8797_F0
+#define SDIO_DEVICE_ID_MARVELL_8797_F0 0x9128
+#endif
+
/*
* This hook just adds a quirk for all sdio devices
*/
@@ -58,6 +65,9 @@ static const struct mmc_fixup mmc_fixup_methods[] = {
SDIO_FIXUP(SDIO_VENDOR_ID_STE, SDIO_DEVICE_ID_STE_CW1200,
add_quirk, MMC_QUIRK_BROKEN_BYTE_MODE_512),
+ SDIO_FIXUP(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8797_F0,
+ add_quirk, MMC_QUIRK_BROKEN_IRQ_POLLING),
+
END_FIXUP
};
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 3d8ceb4..417d2f0 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -53,6 +53,17 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
return ret;
}
+ if (pending && mmc_card_broken_irq_polling(card) &&
+ !(host->caps & MMC_CAP_SDIO_IRQ)) {
+ unsigned char dummy;
+
+ /* A fake interrupt could be created when we poll SDIO_CCCR_INTx
+* register with a Marvell SD8797 card. A dummy CMD52 read to
+* function 0 register 0xff can aviod this.
+*/
+ mmc_io_rw_direct(card, 0, 0, 0xff, 0, &dummy);
+ }
+
count = 0;
for (i = 1; i <= 7; i++) {
if (pending & (1 << i)) {
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 176fdf8..b730272 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -271,9 +271,10 @@ struct mmc_card {
#define MMC_QUIRK_INAND_CMD38 (1<<6) /* iNAND devices have broken
CMD38 */
#define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for regular
multiblock */
#define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8) /* Avoid sending 512 bytes in */
+ /* byte mode */
#define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD
says */
#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10)/* Skip secure for
erase/trim */
- /* byte mode */
+#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could
create a fake interrupt */
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
@@ -505,6 +506,11 @@ static inline int mmc_card_long_read_time(const struct
mmc_card *c)
return c->quirks & MMC_QUIRK_LONG_READ_TIME;
}
+static inline int mmc_card_broken_irq_polling(const struct mmc_card *c)
+{
+ return c->quirks & MMC_QUIRK_BROKEN_IRQ_POLLING;
+}
+
#define mmc_card_name(c) ((c)->cid.prod_name)
#define mmc_card_id(c) (dev_name(&(c)->dev))
--
1.8.0
--
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] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Hi Ulf,
Thanks for your comments.
> > @@ -89,3 +99,14 @@ void mmc_fixup_device(struct mmc_card *card, const
> > struct mmc_fixup *table)
> > }
> > }
> > EXPORT_SYMBOL(mmc_fixup_device);
> > +
> > +void mmc_fixup_broken_irq_polling(struct mmc_card *card)
> > +{
> > + unsigned char dummy;
> > +
> > + /* A fake interrupt could be created when we poll SDIO_CCCR_INTx
> > +* register with a Marvell SD8797 card. A dummy CMD52 read to
> > +* function 0 register 0xff can aviod this.
> > +*/
> > + mmc_io_rw_direct(card, 0, 0, 0xff, 0, &dummy);
> > +}
>
> I would suggest you follow how the other quirks has been implemented,
> thus I don't think you need a separate function just for invoking an
> extra mmc_io_rw_direct, do directly in sdio_irq.c instead.
Will make this change in v2.
> > @@ -47,6 +47,11 @@ static int process_sdio_pending_irqs(struct mmc_host
> > *host)
> > }
> >
> > ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
> > +
> > + if (pending && (card->quirks & MMC_QUIRK_BROKEN_IRQ_POLLING) &&
>
> Suggest you add an mmc_card_broken_irq_poll(), in card.h. Like the
> other quirks are handled.
Sure.
>
> > + !(host->caps & MMC_CAP_SDIO_IRQ))
> > + mmc_fixup_broken_irq_polling(card);
> > +
> > if (ret) {
> > pr_debug("%s: error %d reading SDIO_CCCR_INTx\n",
> >mmc_card_id(card), ret);
> > return ret;
> > }
I will also move the quirk handling down here (after the 'ret' validation).
Thanks,
Bing
--
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
[PATCH] mmc/sdio: add a quirk for broken SDIO_CCCR_INTx polling
Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
SD8797 card. Add a quirk to handle this case. The fixup here is
to issue a dummy CMD52 read to function 0 register 0xff, and this
dummy read must be right after SDIO_CCCR_INTx is read.
Patch has been verified on a dw_mmc controller (Samsung Chromebook)
with MMC_CAP_SDIO_IRQ disabled.
Reviewed-by: Paul Stewart
Reviewed-by: Doug Anderson
Signed-off-by: Bing Zhao
---
drivers/mmc/core/quirks.c | 21 +
drivers/mmc/core/sdio_irq.c | 5 +
include/linux/mmc/card.h| 4 +++-
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c
index 06ee1ae..870bcc3 100644
--- a/drivers/mmc/core/quirks.c
+++ b/drivers/mmc/core/quirks.c
@@ -13,6 +13,9 @@
#include
#include
#include
+#include
+
+#include "sdio_ops.h"
#ifndef SDIO_VENDOR_ID_TI
#define SDIO_VENDOR_ID_TI 0x0097
@@ -30,6 +33,10 @@
#define SDIO_DEVICE_ID_STE_CW1200 0x2280
#endif
+#ifndef SDIO_DEVICE_ID_MARVELL_8797_F0
+#define SDIO_DEVICE_ID_MARVELL_8797_F0 0x9128
+#endif
+
/*
* This hook just adds a quirk for all sdio devices
*/
@@ -58,6 +65,9 @@ static const struct mmc_fixup mmc_fixup_methods[] = {
SDIO_FIXUP(SDIO_VENDOR_ID_STE, SDIO_DEVICE_ID_STE_CW1200,
add_quirk, MMC_QUIRK_BROKEN_BYTE_MODE_512),
+ SDIO_FIXUP(SDIO_VENDOR_ID_MARVELL, SDIO_DEVICE_ID_MARVELL_8797_F0,
+ add_quirk, MMC_QUIRK_BROKEN_IRQ_POLLING),
+
END_FIXUP
};
@@ -89,3 +99,14 @@ void mmc_fixup_device(struct mmc_card *card, const struct
mmc_fixup *table)
}
}
EXPORT_SYMBOL(mmc_fixup_device);
+
+void mmc_fixup_broken_irq_polling(struct mmc_card *card)
+{
+ unsigned char dummy;
+
+ /* A fake interrupt could be created when we poll SDIO_CCCR_INTx
+* register with a Marvell SD8797 card. A dummy CMD52 read to
+* function 0 register 0xff can aviod this.
+*/
+ mmc_io_rw_direct(card, 0, 0, 0xff, 0, &dummy);
+}
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 3d8ceb4..afb00e1 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -47,6 +47,11 @@ static int process_sdio_pending_irqs(struct mmc_host *host)
}
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
+
+ if (pending && (card->quirks & MMC_QUIRK_BROKEN_IRQ_POLLING) &&
+ !(host->caps & MMC_CAP_SDIO_IRQ))
+ mmc_fixup_broken_irq_polling(card);
+
if (ret) {
pr_debug("%s: error %d reading SDIO_CCCR_INTx\n",
mmc_card_id(card), ret);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 176fdf8..08a065b 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -271,9 +271,10 @@ struct mmc_card {
#define MMC_QUIRK_INAND_CMD38 (1<<6) /* iNAND devices have broken
CMD38 */
#define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for regular
multiblock */
#define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8) /* Avoid sending 512 bytes in */
+ /* byte mode */
#define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD
says */
#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10)/* Skip secure for
erase/trim */
- /* byte mode */
+#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could
create a fake interrupt */
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
@@ -531,5 +532,6 @@ extern void mmc_unregister_driver(struct mmc_driver *);
extern void mmc_fixup_device(struct mmc_card *card,
const struct mmc_fixup *table);
+extern void mmc_fixup_broken_irq_polling(struct mmc_card *card);
#endif /* LINUX_MMC_CARD_H */
--
1.8.0
--
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: mwifiex_sdio on chromebook
Hi Alexander, > > Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So > > 50MHz is correct. > > Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at > most. > > > What are you trying to do here? Are you trying to run a mainline kernel on > > your Chromebook? > > Yes. I've got kernel 3.4 from Google Chrome OS. It works ok for > mwifiex_sdio. But I want to run mainline kernel. As of 3.11 it is able > to boot on Chromebook, but WiFi doesn't work. I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree. > > > You said mmc_attach_sdio function fails. The mwifiex_sdio driver and > > the firmware will not be loaded at all. > > Ok, that is clear. > > > CONFIG_MMC_DEBUG=y, and collect the debug logs. > > This way seems not very useful, because there is also internal and > external storage on mmc bus, so log quickly get garbaged with it. Dmesg > seems to be overflowed and forgets early initialization. I have made a > dirty hack to collect some useful info about initialization. I am > attaching it. Please check, if I need to add something. Will it be > useful this way? As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide. http://www.chromium.org/chromium-os/developer-guide Thanks, Bing
RE: mwifiex_sdio on chromebook
CC: linux-mmc Hi Alexander, > Hello. > I am trying to debug the issue with incorrect initialization of WiFi chip on > Samsung ARM Chromebook. And I search for assistance. I have posted my > investigation results on launchpad.net (bug #1247512). Here is > copy: > > Marvell SDIO WiFi chip doesn't get initialized correctly on Chromebook. > After some research I have managed to find that when Linux is doing > initialization, it tries setting clock and power to SDIO controller for that > chip. It > is trying frequences hardcoded in > linux/drivers/mmc/core/core.c: 40, 30, 20, 10 Hz. > Opposed to that, chrome os kernel tries other frequences: 784314Hz and > 5000Hz. The last is staying as working frequency. I don't know, if it is > matter for card what frequency does the host tries to gate. Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So 50MHz is correct. > > When mainline kernel runs mmc_attach_sdio function it should get correct > answer from card and so process card as SDIO. However it fails with timeout > in that function. What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook? > > I wonder if this depends on firmware loading. I see, that chrome os 3.4 > kernel requires firmware. And mainline is probably simply doesn't load it by > default. Currently, I don't know how to check it and how to configure kernel > to load firmware for mwifiex_sdio. You said mmc_attach_sdio function fails. The mwifiex_sdio driver and the firmware will not be loaded at all. > > I am ready to do further research, but I need some assistance. CONFIG_MMC_DEBUG=y, and collect the debug logs. Regards, Bing
RE: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
> I didn't get the same result..In my case, it's working fine. > But as Bing's result, i will check more and share the result. I want to add that my kernel is from "cros/release-R26-3701.B" branch with this HEAD: 4e13a9c CHERRY-PICK: UPSTREAM: loop: prevent bdev freeing while device in use Thanks, Bing -- 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] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
> I think the proposal on the table is to take Seungwon's patches > instead of mine. Assuming they solve your problems, I'm OK with that. > I think he was requesting testing the first of his two patches alone > and then both of his two patches together. Test #1: Swungwon's patch #1 alone [1] Test #2: Swungwon's patch #2 alone [1] Test #3: Swungwon's patch #1 and #2 [1] Test #4: Doug's original patch [2] Test #1 and #3: it doesn't work; system reboots due to kernel hung_task Test #2 and #4: it works; instead of hung_task driver gets CRC error (which is expected) Thanks, Bing [1] https://lkml.org/lkml/2013/4/8/316 [2] https://lkml.org/lkml/2013/3/15/583 -- 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] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Doug, > > I tested Doug's patch on my failing unit. > > > > Without this patch, mmc got hung_task and rebooted eventually. > > With this patch applied, mmc returns CRC error instead of hung_task, and > > the error is handled > gracefully. > > Have you tried one or both or Seungwon's fixes without mine? I only tested your original patch. That was several months ago I think. I still have that unit. Let me know if you want me to try Seungwon's patches. Thanks, Bing > > -Doug -- 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] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR
Hi Seungwon, > > I don't have the failing unit myself, so we'll have to get Bing to try > > the patches. You are suggesting that we try applying both of your > > patches, right? > Did you test the patch? > I wonder that both are good for your side. I tested Doug's patch on my failing unit. Without this patch, mmc got hung_task and rebooted eventually. With this patch applied, mmc returns CRC error instead of hung_task, and the error is handled gracefully. Thanks, Bing > > Thanks, > Seungwon Jeon -- 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 v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi Subhash, > >> sdhci_add_host() reads host controller's capabilities and initialize > >> host->caps of function > >> mmc_host_uhs(). So mmc_host_uhs() only return this cached values. > > So, it does represent host controller's capabilities, not the capabilities > > of the card. > > What happens if I have a UHS capable controller and a 2.0 card? > > The S18R bit will be set in this case, which might cause problem for the > > card? > Hi Bing, > > Why do you see an issue with setting S18R bit when sending CMD5 to > SDIO2.0 compliant card? > If SDIO2.0 card don't support it, return OCR won't have the S18A bit set. Some times ago I ever encountered a problem with CMD52 when I played with an SDIO driver and accidentally set one of the reserved bits to 1. The issue was resolved immediately after I realized it and cleared that bit to 0. This experience makes me thinking that CMD5 S18R might confuse some 2.0 cards, because bit24 is also a reserved bit in 2.0 spec. > We are already doing same thing for SD cards as well (check > mmc_sd_get_cid function). There also even if we set the S18R bit which > sending OCR to non-SD3.0 cards, they respond back with S18A bit cleared. Then it's fair enough to handle SDIO the same way. Thanks for the elaboration. > > If non-SDIO3.0 card misbehaves after receiving the OCR with S18R bit set > then it means card is not compliant to specification properly and in > that case those cards can be handled with QUIRKs. But there is no need > to add any QUIRKs as of now. That sounds reasonable. The quirk for non-compliant cards can be done later when they come up. Regards, Bing > > I hope this make sense. > > Regards, > Subhash > -- 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 v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi Jackey, > Hi Bing, > > sdhci_add_host() reads host controller's capabilities and initialize > host->caps of function > mmc_host_uhs(). So mmc_host_uhs() only return this cached values. So, it does represent host controller's capabilities, not the capabilities of the card. What happens if I have a UHS capable controller and a 2.0 card? The S18R bit will be set in this case, which might cause problem for the card? Thanks, Bing > > Thanks, > Jackey > > -Original Message- > From: Bing Zhao [mailto:bz...@marvell.com] > Sent: Thursday, December 06, 2012 3:14 AM > To: Shen, Jackey; Subhash Jadavani; linux-mmc@vger.kernel.org > Cc: linux-arm-...@vger.kernel.org; Sujit Reddy Thumma > Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization > sequence > > Hi Jackey, > > > Hi Bing, > > > > The function mmc_host_uhs() will return false and never set bit[24] (S18R) > > for SDIO 2.0 cards. > > I thought mmc_host_uhs() will return host controller's capabilities, no? > > Thanks, > Bing > > > > > Thanks, > > Jackey > > > > -Original Message- > > From: linux-mmc-ow...@vger.kernel.org > > [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Bing Zhao > > Sent: Wednesday, December 05, 2012 5:14 AM > > To: Subhash Jadavani; linux-mmc@vger.kernel.org > > Cc: linux-arm-...@vger.kernel.org; Sujit Reddy Thumma > > Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I > > initialization sequence > > > > Hi, > > > > > From: Sujit Reddy Thumma > > > > > > According to UHS-I initialization sequence for SDIO 3.0 cards, the > > > host must set bit[24] (S18R) of OCR register during OCR handshake to > > > know whether the SDIO card is capable of doing 1.8V I/O. > > > > In SDIO 2.0 spec, bit[24] is reserved, "shall be set to 0". > > Setting it to 1 might cause side effect to 2.0 cards. > > Perhaps using a quirk for S18R is more suitable for all combinations. > > > > Regards, > > Bing > > > > > > > > Signed-off-by: Sujit Reddy Thumma > > > Signed-off-by: Subhash Jadavani > > > --- > > > drivers/mmc/core/sdio.c | 22 +++--- > > > include/linux/mmc/host.h |8 > > > 2 files changed, 19 insertions(+), 11 deletions(-) > > > > -- > > 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 > > > > -- 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 v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi Jackey, > Hi Bing, > > The function mmc_host_uhs() will return false and never set bit[24] (S18R) > for SDIO 2.0 cards. I thought mmc_host_uhs() will return host controller's capabilities, no? Thanks, Bing > > Thanks, > Jackey > > -Original Message- > From: linux-mmc-ow...@vger.kernel.org > [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Bing Zhao > Sent: Wednesday, December 05, 2012 5:14 AM > To: Subhash Jadavani; linux-mmc@vger.kernel.org > Cc: linux-arm-...@vger.kernel.org; Sujit Reddy Thumma > Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization > sequence > > Hi, > > > From: Sujit Reddy Thumma > > > > According to UHS-I initialization sequence for SDIO 3.0 cards, the > > host must set bit[24] (S18R) of OCR register during OCR handshake to > > know whether the SDIO card is capable of doing 1.8V I/O. > > In SDIO 2.0 spec, bit[24] is reserved, "shall be set to 0". > Setting it to 1 might cause side effect to 2.0 cards. > Perhaps using a quirk for S18R is more suitable for all combinations. > > Regards, > Bing > > > > > Signed-off-by: Sujit Reddy Thumma > > Signed-off-by: Subhash Jadavani > > --- > > drivers/mmc/core/sdio.c | 22 +++--- > > include/linux/mmc/host.h |8 > > 2 files changed, 19 insertions(+), 11 deletions(-) > > -- > 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 > -- 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 v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence
Hi, > From: Sujit Reddy Thumma > > According to UHS-I initialization sequence for SDIO 3.0 cards, > the host must set bit[24] (S18R) of OCR register during OCR > handshake to know whether the SDIO card is capable of doing > 1.8V I/O. In SDIO 2.0 spec, bit[24] is reserved, "shall be set to 0". Setting it to 1 might cause side effect to 2.0 cards. Perhaps using a quirk for S18R is more suitable for all combinations. Regards, Bing > > Signed-off-by: Sujit Reddy Thumma > Signed-off-by: Subhash Jadavani > --- > drivers/mmc/core/sdio.c | 22 +++--- > include/linux/mmc/host.h |8 > 2 files changed, 19 insertions(+), 11 deletions(-) -- 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] mmc/sdio: don't allow interface to runtime-suspend until probe is finished.
Hi Neil, > In the other case where I do let it suspend early (And it never recovers > without the reset line being toggled) I see: > > [ 2170.100982] mmc_wait_for_cmd 52 -> -110 > [ 2170.105407] mmc_wait_for_cmd 52 -> -110 > [ 2170.110260] mmc_wait_for_cmd 0 -> 0 > [ 2170.115509] mmc_wait_for_cmd 8 -> -110 > [ 2170.119842] mmc_wait_for_cmd 5 -> 0 > [ 2170.123901] mmc_wait_for_cmd 5 -> 0 > [ 2170.127929] mmc_wait_for_cmd 3 -> 0 > [ 2170.131958] mmc_wait_for_cmd 7 -> 0 This works when reset line toggling was applied. > [ 2170.135986] mmc_wait_for_cmd 52 -> 0 > [ 2170.140136] mmc_wait_for_cmd 52 -> 0 > [ 2170.144226] mmc_wait_for_cmd 52 -> 0 > [ 2170.148376] mmc_wait_for_cmd 52 -> 0 > [ 2170.152465] mmc_wait_for_cmd 52 -> 0 > > > which is much the same but then one second later: > > [ 2171.166656] mmc_wait_for_cmd 52 -> 0 > [ 2171.170806] mmc_wait_for_cmd 52 -> 0 > [ 2171.175384] mmc_wait_for_cmd 0 -> 0 > [ 2171.180603] mmc_wait_for_cmd 8 -> -110 > [ 2171.185943] mmc_wait_for_cmd 5 -> -110 Here the CMD5 timeout is expected because SD8686 has already been initialized with CMD5,5,3,7. If you are able to skip re-initialization at this point, like what "powered_resume" does, you will probably get SD8686 continue to run. Regards, Bing > [ 2171.190093] libertas_sdio: probe of mmc1:0001:1 failed with error -16 > > > So this answers Bing Zhao's question - it was CMD5 that timed out and caused > the failure. > > If I just get mmc_wait_for_cmd to hide error -110 for cmd 5 it complains > > [ 26.420440] mmc1: host doesn't support card's voltages > > so that isn't a simple solution :-)
RE: [PATCH] mmc/sdio: don't allow interface to runtime-suspend until probe is finished.
Hi Ohad, > > But shortly there after the extra tracing I put in shows that mmc_power_off > > is called, > > Probably right after libertas' if_sdio_probe() returns ? > > > then mmc_sdio_power_restore calls mmc_send_io_op_cond > > Is that as a result of libertas' if_sdio_power_restore() being called > (i.e. someone/something called 'ifconfig up') ? > > > which again > > returns -110, but now it isn't a problem and the wifi chip keeps working. > > if_sdio_power_restore doesn't check the return value of > pm_runtime_get_sync, so it won't error out, but I wonder how come the > chip still works. > > > So maybe the fact that we error-out in the first case is a problem?? > > It might be nice if Marvell could comment on this, though we can > probably empirically deduce this too. We will get CMD5 R4 only after a PDn (power down line) or RESETn (reset line) toggling. Was it timed out on CMD5 or CMD52? The 2nd enumeration will result CMD5 timeout if SD8686 has been initialized (with CMD5,5,3,7 sequence) already. The 2nd CMD5 timeout should not cause any side effect though. > > > I found that if I pull the reset line down and then let it back up then it > > all works. > > Nice. Joe, did this work out for you too ? > > > So I have run out of ideas. I can make it work by reseting the chip during > > mmc_power_up but I have no idea what is causing the chip to need a reset. > > I wonder why the sdio reset command isn't helpful for you - it did > seem to resolve some issues for Daniel. Maybe you have two different > hardware revisions of the 8686 which behave differently in this > respect ? CMD52 Card Reset (writing bit3=1 to CCCR 0x06) may not reset the SD8686 properly for some systems. The reliable way to reset SD8686 is via RESETn toggling. Regards, Bing > > > However for now I think I'll go with my 'remux' hack. > > Feel free to post it so we can take a look. > > Thanks, > Ohad. -- 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
[PATCH v2] mmc: recognise SDIO cards with SDIO_CCCR_REV 3.00
Table 6-2: CCCR bit Definitions, address 00h
Part E1 SDIO Simplified Specification Version 3.00
Feb. 25, 2011
This patch has been tested with Marvell WLAN device SD8797.
Signed-off-by: Bing Zhao
---
v2: add device name that was used to test this patch in commit log
drivers/mmc/core/sdio.c |2 +-
include/linux/mmc/sdio.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 925bab0..3ab565e 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -111,7 +111,7 @@ static int sdio_read_cccr(struct mmc_card *card)
cccr_vsn = data & 0x0f;
- if (cccr_vsn > SDIO_CCCR_REV_1_20) {
+ if (cccr_vsn > SDIO_CCCR_REV_3_00) {
pr_err("%s: unrecognised CCCR structure version %d\n",
mmc_hostname(card->host), cccr_vsn);
return -EINVAL;
diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h
index 2a2e990..e0b1123 100644
--- a/include/linux/mmc/sdio.h
+++ b/include/linux/mmc/sdio.h
@@ -72,11 +72,13 @@
#define SDIO_CCCR_REV_1_000 /* CCCR/FBR Version 1.00 */
#define SDIO_CCCR_REV_1_101 /* CCCR/FBR Version 1.10 */
#define SDIO_CCCR_REV_1_202 /* CCCR/FBR Version 1.20 */
+#define SDIO_CCCR_REV_3_003 /* CCCR/FBR Version 3.00 */
#define SDIO_SDIO_REV_1_000 /* SDIO Spec Version 1.00 */
#define SDIO_SDIO_REV_1_101 /* SDIO Spec Version 1.10 */
#define SDIO_SDIO_REV_1_202 /* SDIO Spec Version 1.20 */
#define SDIO_SDIO_REV_2_003 /* SDIO Spec Version 2.00 */
+#define SDIO_SDIO_REV_3_004 /* SDIO Spec Version 3.00 */
#define SDIO_CCCR_SD 0x01
--
1.7.4.1
--
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
[PATCH] mmc: recognise SDIO cards with SDIO_CCCR_REV 3.00
Table 6-2: CCCR bit Definitions, address 00h
Part E1 SDIO Simplified Specification Version 3.00
Feb. 25, 2011
Signed-off-by: Bing Zhao
---
drivers/mmc/core/sdio.c |2 +-
include/linux/mmc/sdio.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 925bab0..3ab565e 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -111,7 +111,7 @@ static int sdio_read_cccr(struct mmc_card *card)
cccr_vsn = data & 0x0f;
- if (cccr_vsn > SDIO_CCCR_REV_1_20) {
+ if (cccr_vsn > SDIO_CCCR_REV_3_00) {
pr_err("%s: unrecognised CCCR structure version %d\n",
mmc_hostname(card->host), cccr_vsn);
return -EINVAL;
diff --git a/include/linux/mmc/sdio.h b/include/linux/mmc/sdio.h
index 2a2e990..e0b1123 100644
--- a/include/linux/mmc/sdio.h
+++ b/include/linux/mmc/sdio.h
@@ -72,11 +72,13 @@
#define SDIO_CCCR_REV_1_000 /* CCCR/FBR Version 1.00 */
#define SDIO_CCCR_REV_1_101 /* CCCR/FBR Version 1.10 */
#define SDIO_CCCR_REV_1_202 /* CCCR/FBR Version 1.20 */
+#define SDIO_CCCR_REV_3_003 /* CCCR/FBR Version 3.00 */
#define SDIO_SDIO_REV_1_000 /* SDIO Spec Version 1.00 */
#define SDIO_SDIO_REV_1_101 /* SDIO Spec Version 1.10 */
#define SDIO_SDIO_REV_1_202 /* SDIO Spec Version 1.20 */
#define SDIO_SDIO_REV_2_003 /* SDIO Spec Version 2.00 */
+#define SDIO_SDIO_REV_3_004 /* SDIO Spec Version 3.00 */
#define SDIO_CCCR_SD 0x01
--
1.7.4.1
--
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: MMC runtime PM patches break libertas probe
> On Thu, Jun 2, 2011 at 11:39 AM, Bing Zhao wrote: >>> If we power down the sd8686, and power it up again, without toggling >>> the reset pin at all (e.g. keep it always high), will the card work ? >> >> Yes. The card should work without toggling the reset pin. > > Thanks. > > Just for closure-sake, can you please confirm that the sd8686 requires > sending a CMD5 arg=0 as part of the initialization sequence after > powering it on ? "CMD5 Arg=0" refers to the very first CMD5 sent from host during initialization sequence. This is required because our state machine always expects two CMD5 from host (5, 5, 3, 7, ...). Regards, Bing > (we'd probably add it anyway, but it'd be nice to get a confirmation > about this from you guys) > > Btw, it will be nice to allow cards to avoid sending this if not > required; a simple card quirk will do. wl12xx will definitely use such > a quirk.-- 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: MMC runtime PM patches break libertas probe
Hi Ohad, > If we power down the sd8686, and power it up again, without toggling > the reset pin at all (e.g. keep it always high), will the card work ? Yes. The card should work without toggling the reset pin. Regards, Bing-- 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] sdio: skip initialization on powered resume
Hi Ohad, > -Original Message- > From: Ohad Ben-Cohen [mailto:o...@wizery.com] > Sent: Saturday, January 22, 2011 2:01 PM > To: zhangfei gao > Cc: Nicolas Pitre; Bing Zhao; Sahitya Tummala; linux-mmc@vger.kernel.org; > Michal Miroslaw; Chris Ball; > Andrew Morton; Maxim Levitsky > Subject: Re: [PATCH v2] sdio: skip initialization on powered resume > > On Fri, Jan 21, 2011 at 11:07 AM, zhangfei gao wrote: > > Do you have any updated patch to skip mmc_sdio_init_card in resume back. > > We need such patch in enable host sleep feature for mrvl8787. > > Is mrvl8787 a removable card ? It can be either a removable or non-removable card, depending on what platform is used. > > I'm asking because we already skip mmc_sdio_init_card() for > powered-resumed nonremovable cards (check out commit 3cfc33a "mmc: > sdio: don't reinitialize nonremovable powered-resumed cards"). Thanks for the info. > > I'm not familiar with marvell's cards, but I do remember a thread > mentioning they have dedicated reset GPIOs, and that may suggest they > are nonremovables. If that's the case, simply setting > MMC_CAP_NONREMOVABLE on the relevant slot should do the trick for you. I think this approach works for Zhangfei on his embedded platform on which the 8787 card is non-removable. Regards, Bing -- 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] sdio: skip initialization on powered resume
> -Original Message- > From: Nicolas Pitre [mailto:n...@fluxnic.net] > Sent: Friday, January 21, 2011 6:56 PM > To: Bing Zhao > Cc: zhangfei gao; Sahitya Tummala; linux-mmc@vger.kernel.org; Michal > Miroslaw; Chris Ball; Andrew > Morton; Maxim Levitsky > Subject: RE: [PATCH v2] sdio: skip initialization on powered resume > > On Fri, 21 Jan 2011, Bing Zhao wrote: > > > Hi Zhangfei, > > > > > -Original Message- > > > From: zhangfei gao [mailto:zhangfei@gmail.com] > > > Sent: Friday, January 21, 2011 1:07 AM > > > To: Nicolas Pitre; Bing Zhao > > > Cc: Sahitya Tummala; linux-mmc@vger.kernel.org; Michal Miroslaw; Chris > > > Ball; Andrew Morton; Maxim > > > Levitsky > > > Subject: Re: [PATCH v2] sdio: skip initialization on powered resume > > > > > > On Wed, Sep 15, 2010 at 10:26 PM, Nicolas Pitre wrote: > > > > On Wed, 15 Sep 2010, Bing Zhao wrote: > > > > > > > >> If CMD7 is sent _before_ client driver's resume handler is called, > > > >> while 8686 card is in sleep mode, it will fail. If CMD7 is sent > > > >> _after_ client driver's resume handler is called, it should succeed. > > > > > > > > Maybe that's what we should do in the powered suspend case then. > > > > > > > >> By the way, a patch "mmc: fix all hangs related to mmc/sd card > > > >> insert/removal during suspend/resume" > > > >> (4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e by Maxim Levitsky) has > > > >> removed the call to mmc_detect_change() in mmc_resume_host(). > > > > > > > > If a card is removed while the host is suspended, then this should be > > > > detected. > > > > > > > > > > > > Nicolas > > > > -- > > > > 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 > > > > > > > > > > Hi, Bing > > > > > > Do you have any updated patch to skip mmc_sdio_init_card in resume back. > > > We need such patch in enable host sleep feature for mrvl8787. > > > > I posted a patch that skips mmc_sdio_init_card() with > > MMC_PM_SKIP_RESUME_PROBE flag earlier: > > > > [PATCH v1] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered resume > > http://marc.info/?l=linux-mmc&m=128294262424567&w=2 > > > > Nicolas commented that it's too hackish with this approach. > > http://marc.info/?l=linux-mmc&m=128294738230151&w=2 > > > > Other than that, I couldn't think of a better way to solve the issue here: > > > > In mmc_sdio_init_card() CIS device/vendor IDs are read to check if the > > card has been replaced or not when the system was suspended. But > > reading these IDs will cause CMD52 timeout if the card is in sleep > > state. The function driver can wake up the card by writing to certain > > card specific register, so that the followed SDIO commands (CMD52, > > CMD53, etc.) can go through. But the resume handler of the function > > driver won't be invoked until the IDs get validated. > > Please add the extra explanation above to the commit log so that > the context is not lost. And then > > Acked-by: Nicolas Pitre > > Then this could be revisited eventually when more devices are supported > and a better abstraction to cover their needs could be created. > > > Nicolas Hi Nicolas, Thanks for ack. I'll resend the patch with extra explanation in commit log. Hi Chris, I'll rebase and test the patch based on git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git tree. Should I use "master" or "mmc-next" branch? Thanks, Bing -- 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] sdio: skip initialization on powered resume
Hi Zhangfei, > -Original Message- > From: zhangfei gao [mailto:zhangfei@gmail.com] > Sent: Friday, January 21, 2011 1:07 AM > To: Nicolas Pitre; Bing Zhao > Cc: Sahitya Tummala; linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; > Andrew Morton; Maxim > Levitsky > Subject: Re: [PATCH v2] sdio: skip initialization on powered resume > > On Wed, Sep 15, 2010 at 10:26 PM, Nicolas Pitre wrote: > > On Wed, 15 Sep 2010, Bing Zhao wrote: > > > >> If CMD7 is sent _before_ client driver's resume handler is called, > >> while 8686 card is in sleep mode, it will fail. If CMD7 is sent > >> _after_ client driver's resume handler is called, it should succeed. > > > > Maybe that's what we should do in the powered suspend case then. > > > >> By the way, a patch "mmc: fix all hangs related to mmc/sd card > >> insert/removal during suspend/resume" > >> (4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e by Maxim Levitsky) has > >> removed the call to mmc_detect_change() in mmc_resume_host(). > > > > If a card is removed while the host is suspended, then this should be > > detected. > > > > > > Nicolas > > -- > > 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 > > > > Hi, Bing > > Do you have any updated patch to skip mmc_sdio_init_card in resume back. > We need such patch in enable host sleep feature for mrvl8787. I posted a patch that skips mmc_sdio_init_card() with MMC_PM_SKIP_RESUME_PROBE flag earlier: [PATCH v1] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered resume http://marc.info/?l=linux-mmc&m=128294262424567&w=2 Nicolas commented that it's too hackish with this approach. http://marc.info/?l=linux-mmc&m=128294738230151&w=2 Other than that, I couldn't think of a better way to solve the issue here: In mmc_sdio_init_card() CIS device/vendor IDs are read to check if the card has been replaced or not when the system was suspended. But reading these IDs will cause CMD52 timeout if the card is in sleep state. The function driver can wake up the card by writing to certain card specific register, so that the followed SDIO commands (CMD52, CMD53, etc.) can go through. But the resume handler of the function driver won't be invoked until the IDs get validated. Regards, Bing > > Thanks a lot. -- 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] sdio: skip initialization on powered resume
Hi Sahitya, > -Original Message- > From: Sahitya Tummala [mailto:stumm...@codeaurora.org] > Sent: Tuesday, September 14, 2010 3:16 AM > To: Bing Zhao > Cc: Nicolas Pitre; linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; > Andrew Morton > Subject: RE: [PATCH v2] sdio: skip initialization on powered resume > > Hi Bing, Chris, > > On Tue, 2010-09-07 at 19:10 -0700, Bing Zhao wrote: > > Hi Nicolas, > > > > > -Original Message- > > > From: Nicolas Pitre [mailto:n...@fluxnic.net] > > > Sent: Tuesday, September 07, 2010 6:29 PM > > > To: Bing Zhao > > > Cc: linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; Andrew Morton > > > Subject: RE: [PATCH v2] sdio: skip initialization on powered resume > > > > > > On Tue, 7 Sep 2010, Bing Zhao wrote: > > > > > > > Thanks for the hint. > > > > > > > > The new patch skips reading CCCR, common CIS, and validation of > > > > vendor/device IDs inside mmc_sdio_init_card() when powered_resume is > > > > not zero. > > > > > > Why do you skip the reading of the CIS and IDs validation? That's > > > basically the main reason for still calling mmc_sdio_init_card(). And > > > that only requires CMD 52 so that should be fine. > > > > While the system is suspended, the SDIO card could be in sleep mode (deep > > sleep or IEEE Power Save) > as well. Reading CIS or any other CMD52 will fail if the card happens to be > in sleep at this moment. > If we skip re-initialization (including CCCR/CIS and IDs validation), > mmc_sdio_init_card() returns > success. Then the client driver's resume() handler will be called and the > card can be woken up by > client driver. > > In one of your previous patches, "sdio: don't use CMD[357] as part of a > powered SDIO resume", its mentioned that there is an issue with CMD7 in > mmc_sdio_init_card() that is called during SDIO resume on Marvell 8686. > > But in mmc_resume_host(), there is still a call to mmc_detect_change() > which in turn calls mmc_sdio_detect(), thus sending CMD7 to the card. > Does CMD7 to your card succeed after your client driver resume is > called? If CMD7 is sent _before_ client driver's resume handler is called, while 8686 card is in sleep mode, it will fail. If CMD7 is sent _after_ client driver's resume handler is called, it should succeed. By the way, a patch "mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume" (4c2ef25fe0b847d2ae818f74758ddb0be1c27d8e by Maxim Levitsky) has removed the call to mmc_detect_change() in mmc_resume_host(). Regards, Bing > > Thanks, > Sahitya. > > -- > Sent by a consultant of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora > Forum. > -- 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] sdio: skip initialization on powered resume
Hi Nicolas, > -Original Message- > From: Nicolas Pitre [mailto:n...@fluxnic.net] > Sent: Tuesday, September 07, 2010 6:29 PM > To: Bing Zhao > Cc: linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; Andrew Morton > Subject: RE: [PATCH v2] sdio: skip initialization on powered resume > > On Tue, 7 Sep 2010, Bing Zhao wrote: > > > Thanks for the hint. > > > > The new patch skips reading CCCR, common CIS, and validation of > > vendor/device IDs inside mmc_sdio_init_card() when powered_resume is > > not zero. > > Why do you skip the reading of the CIS and IDs validation? That's > basically the main reason for still calling mmc_sdio_init_card(). And > that only requires CMD 52 so that should be fine. While the system is suspended, the SDIO card could be in sleep mode (deep sleep or IEEE Power Save) as well. Reading CIS or any other CMD52 will fail if the card happens to be in sleep at this moment. If we skip re-initialization (including CCCR/CIS and IDs validation), mmc_sdio_init_card() returns success. Then the client driver's resume() handler will be called and the card can be woken up by client driver. Regards, Bing > > > Nicolas -- 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] sdio: skip initialization on powered resume
Hi Nicolas,
> -Original Message-
> From: Nicolas Pitre [mailto:n...@fluxnic.net]
> Sent: Thursday, September 02, 2010 4:30 PM
> To: Bing Zhao
> Cc: linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; Andrew Morton
> Subject: RE: [PATCH v2] sdio: skip initialization on powered resume
>
> On Thu, 2 Sep 2010, Bing Zhao wrote:
>
> > > Please look at the if() condition, and at the last argument to
> > > mmc_sdio_init_card(), then ponder.
> >
> > You are right. The last argument passed to mmc_sdio_init_card() is zero
> > actually.
> >
> > err = mmc_sdio_init_card(host, host->ocr, host->card, 0);
> >
> > >
> > > I think the proper fix goes _inside_ mmc_sdio_init_card() as there are
> > > certainly still validation checks which are appropriate to perform.
> >
> > When you have a thought for the fix, I can do the testing on my system.
>
> I'm telling you that you should use the powered_resume argument of
> mmc_sdio_init_card() to skip problematic initializations inside
> mmc_sdio_init_card() when powered_resume is not zero. Looking at the
> existing code should give you examples of how powered_resume is used and
> why.
Thanks for the hint.
The new patch skips reading CCCR, common CIS, and validation of vendor/device
IDs inside mmc_sdio_init_card() when powered_resume is not zero.
If it looks okay for you I will resend it as V3.
drivers/mmc/core/sdio.c | 38 +-
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index f332c52..37f64d6 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -434,28 +434,32 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32
ocr,
goto finish;
}
- /*
-* Read the common registers.
-*/
- err = sdio_read_cccr(card);
- if (err)
- goto remove;
+ if (!powered_resume) {
+ /*
+* Read the common registers.
+*/
+ err = sdio_read_cccr(card);
+ if (err)
+ goto remove;
- /*
-* Read the common CIS tuples.
-*/
- err = sdio_read_common_cis(card);
- if (err)
- goto remove;
+ /*
+* Read the common CIS tuples.
+*/
+ err = sdio_read_common_cis(card);
+ if (err)
+ goto remove;
+ }
if (oldcard) {
- int same = (card->cis.vendor == oldcard->cis.vendor &&
- card->cis.device == oldcard->cis.device);
mmc_remove_card(card);
- if (!same)
- return -ENOENT;
- card = oldcard;
+ if (!powered_resume) {
+ int same = (card->cis.vendor == oldcard->cis.vendor &&
+ card->cis.device == oldcard->cis.device);
+ if (!same)
+ return -ENOENT;
+ }
+
return 0;
}
Regards,
Bing
>
>
> Nicolas
--
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] sdio: skip initialization on powered resume
Hi Nicolas,
Thanks for your comments.
> -Original Message-
> From: Nicolas Pitre [mailto:n...@fluxnic.net]
> Sent: Thursday, September 02, 2010 10:54 AM
> To: Bing Zhao
> Cc: linux-mmc@vger.kernel.org; Michal Miroslaw; Chris Ball; Andrew Morton
> Subject: Re: [PATCH v2] sdio: skip initialization on powered resume
>
> On Wed, 1 Sep 2010, Bing Zhao wrote:
>
> > Quoted Michal Miroslaw's comment:
> >
> > Simplified SDIO spec v.2.00 (section 6.14 - Bus State Diagram)
> > suggests, that initialization commands (CMD5, CMD3) are not accepted
> > in CMD state. As the card stays in that state on powered suspend (no
> > resetting CMD52 nor power cycle is issued) then reinitialization
> > should be entirely skipped on resume unless the power was lost between
> > suspend and resume (or card was temporarily removed from the slot).
> >
> > Signed-off-by: Bing Zhao
>
> Comments below.
>
> > + /*
> > +* Simplified SDIO spec v2.00 (section 6.14 - Bus State Diagram)
> > +* suggests that initialization should be skipped on powered resume.
> > +*/
> > + if (!(host->pm_flags & MMC_PM_KEEP_POWER)) {
> > + err = mmc_sdio_init_card(host, host->ocr, host->card,
> > + host->pm_flags & MMC_PM_KEEP_POWER);
> > + }
>
> Please look at the if() condition, and at the last argument to
> mmc_sdio_init_card(), then ponder.
You are right. The last argument passed to mmc_sdio_init_card() is zero
actually.
err = mmc_sdio_init_card(host, host->ocr, host->card, 0);
>
> I think the proper fix goes _inside_ mmc_sdio_init_card() as there are
> certainly still validation checks which are appropriate to perform.
When you have a thought for the fix, I can do the testing on my system.
Thanks,
Bing
>
>
> Nicolas
--
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] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered resume
Hi Wilson, > -Original Message- > From: Wilson Loi [mailto:wls...@gmail.com] > Sent: Wednesday, September 01, 2010 5:33 PM > To: Bing Zhao > Cc: Michał Mirosław; Chris Ball; linux-mmc@vger.kernel.org; Nicolas Pitre; > Andrew Morton > Subject: Re: [PATCH] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered > resume > > It should be necessary for this flags. > Some WLAN card will put itself either into deep sleep or host wake up mode. > They don't need to re-init after resume. The MMC_PM_KEEP_POWER flag can be set in suspend handler before WLAN card is put into any power saving mode. When system resumes re-init attempt will be skipped as MMC_PM_KEEP_POWER is set. Regards, Bing > > > 2010/9/2 Bing Zhao > > > Hi Michal, > > Thanks for your comment. > > > > -Original Message- > > From: Michał Mirosław [mailto:mir...@gmail.com] > > Sent: Wednesday, September 01, 2010 11:40 AM > > To: Chris Ball > > Cc: Bing Zhao; linux-mmc@vger.kernel.org; Nicolas Pitre; Andrew Morton > > Subject: Re: [PATCH] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround > powered resume > > > > 2010/8/27 Chris Ball : > > > Any comments on this patch from the list? > > > > > > From: Bing Zhao > > > Date: Wed, 21 Jul 2010 18:46:55 -0700 > > > > > > Marvell 8686/8688 device will not respond to re-probe attemps > > > in powered resume, if the card is in sleep mode. > > > The added MMC_PM_SKIP_RESUME_PROBE flag is checked so that > > > call to mmc_sdio_init_card() can be skipped. > > [patch cut] > > > > Simplified SDIO spec v.2.00 (section 6.14 - Bus State Diagram) > > suggests, that initialization commands (CMD5, CMD3) are not accepted > > in CMD state. As the card stays in that state on powered suspend (no > > resetting CMD52 nor power cycle is issued) then reinitialization > > should be entirely skipped on resume unless the power was lost between > > suspend and resume (or card was temporarily removed from the slot). > > > With that said, skipping initialization on powered resume is needed in > general. We can just > check MMC_PM_KEEP_POWER flag to skip the card initialization. > > I will send the updated patch. > > Regards, > > Bing > > > > > > Best Regards, > > Michał Mirosław > -- > 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 > > > > > > -- > Best regards, > Wilson > http://blog.roodo.com/wlsloi -- 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
[PATCH v2] sdio: skip initialization on powered resume
Quoted Michal Miroslaw's comment:
Simplified SDIO spec v.2.00 (section 6.14 - Bus State Diagram)
suggests, that initialization commands (CMD5, CMD3) are not accepted
in CMD state. As the card stays in that state on powered suspend (no
resetting CMD52 nor power cycle is issued) then reinitialization
should be entirely skipped on resume unless the power was lost between
suspend and resume (or card was temporarily removed from the slot).
Signed-off-by: Bing Zhao
---
Changes since v1:
* Subject changed (was "add MMC_PM_SKIP_RESUME_PROBE to...")
* No need to introduce new flag MMC_PM_SKIP_RESUME_PROBE
* Add Michal Miroslaw's comment as patch description
drivers/mmc/core/sdio.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index f332c52..64d2471 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -605,15 +605,23 @@ static int mmc_sdio_suspend(struct mmc_host *host)
static int mmc_sdio_resume(struct mmc_host *host)
{
- int i, err;
+ int i, err = 0;
BUG_ON(!host);
BUG_ON(!host->card);
/* Basic card reinitialization. */
mmc_claim_host(host);
- err = mmc_sdio_init_card(host, host->ocr, host->card,
-(host->pm_flags & MMC_PM_KEEP_POWER));
+
+ /*
+* Simplified SDIO spec v2.00 (section 6.14 - Bus State Diagram)
+* suggests that initialization should be skipped on powered resume.
+*/
+ if (!(host->pm_flags & MMC_PM_KEEP_POWER)) {
+ err = mmc_sdio_init_card(host, host->ocr, host->card,
+ host->pm_flags & MMC_PM_KEEP_POWER);
+ }
+
if (!err) {
/* We may have switched to 1-bit mode during suspend. */
err = sdio_enable_4bit_bus(host->card);
--
1.5.3.6
--
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] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered resume
Hi Michal, Thanks for your comment. > -Original Message- > From: Michał Mirosław [mailto:mir...@gmail.com] > Sent: Wednesday, September 01, 2010 11:40 AM > To: Chris Ball > Cc: Bing Zhao; linux-mmc@vger.kernel.org; Nicolas Pitre; Andrew Morton > Subject: Re: [PATCH] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered > resume > > 2010/8/27 Chris Ball : > > Any comments on this patch from the list? > > > > From: Bing Zhao > > Date: Wed, 21 Jul 2010 18:46:55 -0700 > > > > Marvell 8686/8688 device will not respond to re-probe attemps > > in powered resume, if the card is in sleep mode. > > The added MMC_PM_SKIP_RESUME_PROBE flag is checked so that > > call to mmc_sdio_init_card() can be skipped. > [patch cut] > > Simplified SDIO spec v.2.00 (section 6.14 - Bus State Diagram) > suggests, that initialization commands (CMD5, CMD3) are not accepted > in CMD state. As the card stays in that state on powered suspend (no > resetting CMD52 nor power cycle is issued) then reinitialization > should be entirely skipped on resume unless the power was lost between > suspend and resume (or card was temporarily removed from the slot). With that said, skipping initialization on powered resume is needed in general. We can just check MMC_PM_KEEP_POWER flag to skip the card initialization. I will send the updated patch. Regards, Bing > > Best Regards, > Michał Mirosław -- 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
[PATCH] sdio: add MMC_PM_SKIP_RESUME_PROBE to workaround powered resume
Marvell 8686/8688 device will not respond to re-probe attemps
in powered resume, if the card is in sleep mode.
The added MMC_PM_SKIP_RESUME_PROBE flag is checked so that
call to mmc_sdio_init_card() can be skipped.
Signed-off-by: Bing Zhao
---
drivers/mmc/core/sdio.c | 18 +++---
drivers/mmc/host/sdhci-pci.c |3 ++-
include/linux/mmc/pm.h |1 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index bd2755e..dc03939 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -606,15 +606,27 @@ static int mmc_sdio_suspend(struct mmc_host *host)
static int mmc_sdio_resume(struct mmc_host *host)
{
- int i, err;
+ int i, err = 0;
BUG_ON(!host);
BUG_ON(!host->card);
/* Basic card reinitialization. */
mmc_claim_host(host);
- err = mmc_sdio_init_card(host, host->ocr, host->card,
-(host->pm_flags & MMC_PM_KEEP_POWER));
+
+ /*
+* For a powered resume, Marvell 8686/8688 device will not respond
+* to re-initialization attemps if the card is in sleep mode.
+* The MMC_PM_SKIP_RESUME_PROBE flag is added as a workaround here.
+* This is a temporary measure until a fully thought-through
+* solution is elaborated.
+*/
+ if (!(host->pm_flags & MMC_PM_KEEP_POWER) ||
+ !(host->pm_flags & MMC_PM_SKIP_RESUME_PROBE)) {
+ err = mmc_sdio_init_card(host, host->ocr, host->card,
+ host->pm_flags & MMC_PM_KEEP_POWER);
+ }
+
if (!err) {
/* We may have switched to 1-bit mode during suspend. */
err = sdio_enable_4bit_bus(host->card);
diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
index e021431..4f793f8 100644
--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -703,7 +703,8 @@ static struct sdhci_pci_slot * __devinit
sdhci_pci_probe_slot(
goto unmap;
}
- host->mmc->pm_caps = MMC_PM_KEEP_POWER | MMC_PM_WAKE_SDIO_IRQ;
+ host->mmc->pm_caps = MMC_PM_KEEP_POWER | MMC_PM_WAKE_SDIO_IRQ
+ | MMC_PM_SKIP_RESUME_PROBE;
ret = sdhci_add_host(host);
if (ret)
diff --git a/include/linux/mmc/pm.h b/include/linux/mmc/pm.h
index d37aac4..7dbb630 100644
--- a/include/linux/mmc/pm.h
+++ b/include/linux/mmc/pm.h
@@ -26,5 +26,6 @@ typedef unsigned int mmc_pm_flag_t;
#define MMC_PM_KEEP_POWER (1 << 0)/* preserve card power during
suspend */
#define MMC_PM_WAKE_SDIO_IRQ (1 << 1)/* wake up host system on SDIO
IRQ assertion */
+#define MMC_PM_SKIP_RESUME_PROBE (1 << 2)/* skip the attempt to
reidentify the card in powered resume */
#endif
--
1.5.3.6
--
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 077/232] sdio: fix read buffer overflow
Hi, > -Original Message- > From: libertas-dev-boun...@lists.infradead.org > [mailto:libertas-dev-boun...@lists.infradead.org] On > Behalf Of Jonathan Cameron > Sent: Thursday, October 01, 2009 7:12 AM > To: David Vrabel > Cc: linux-mmc@vger.kernel.org; a...@linux-foundation.org; > roel.kl...@gmail.com; libertas- > d...@lists.infradead.org > Subject: Re: [patch 077/232] sdio: fix read buffer overflow > > David Vrabel wrote: > > David Vrabel wrote: > >> It's harmless if the tuple contains fewer so I think we should just try > >> and parse as many strings as possible. Does this patch fix your > >> regression? > > > > I spelt the field name wrong in the comment. Use this patch instead, > > please. > Works for me, so Tested-by: Jonathan Cameron > > I guess it's just a question of posting it as a normal patch and seeing if > anyone screams. This patch works for me too. Tested-by: Bing Zhao Thanks, Bing > > Thanks, > > Jonathan > > ___ > libertas-dev mailing list > libertas-...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/libertas-dev -- 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
