Skip to contentSkip to conversation

SDIO fixes

PATCH In review Subhash Jadavani 6 participants 24 messages Dec 4, 2012 – Jan 14, 2013 2 messages not in the archive

Subsystems (2)
Arm Qualcomm mailing list MMC, SD and SDIO
lore
Share & tools
lore

Subhash Jadavani

author
#0 lore raw

cover SDIO fixes

This patch-series is having 1 fix for SDIO resume and 2 fixes related to SDIO3.0 card detection

Subhash Jadavani (2):
mmc: sdio: fix resume failure
mmc: sdio: print correct UHS mode during card detection

Sujit Reddy Thumma (1):
mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

 drivers/mmc/core/sdio.c  |   33 ++++++++++++++++++++-------------
 include/linux/mmc/host.h |    8 ++++++++
 2 files changed, 28 insertions(+), 13 deletions(-)
Signature · 2 lines
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
author
#1 lore raw

PATCH 1/3 mmc: sdio: fix resume failure

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +4 -2
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
 	mmc_claim_host(host);
 
 	/* No need to reinitialize powered-resumed nonremovable cards */
-	if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+	if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+		sdio_reset(host);
+		mmc_go_idle(host);
 		err = mmc_sdio_init_card(host, host->ocr, host->card,
 					mmc_card_keep_power(host));
-	else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
+	} else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
 		/* We may have switched to 1-bit mode during suspend */
 		err = sdio_enable_4bit_bus(host->card);
 		if (err > 0) {
Signature · 2 lines
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
#2 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 18 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 942

Quoted 7 lines
drivers/mmc/core/sdio.c +3 -1
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
        mmc_claim_host(host);
 
        /* No need to reinitialize powered-resumed nonremovable cards */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 11 lines
drivers/mmc/core/sdio.c +1 -3
                err = mmc_sdio_init_card(host, host->ocr, host->card,
                                        mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
                /* We may have switched to 1-bit mode during suspend */
                err = sdio_enable_4bit_bus(host->card);
                if (err > 0) {
--
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

author
#3 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 21 lines · Ulf Hansson
Quoted 20 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
  drivers/mmc/core/sdio.c |    6 ++++--
  1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
         mmc_claim_host(host);
Quoted 7 lines

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 942

Quoted 5 lines
drivers/mmc/core/sdio.c +3 -1
         /* No need to reinitialize powered-resumed nonremovable cards */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Yes, the regulator powering the card is always on in this case which means SDIO VDD is not powered off during the suspend.

Quoted 21 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 11 lines
drivers/mmc/core/sdio.c +1 -3
                 err = mmc_sdio_init_card(host, host->ocr, host->card,
                                         mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
                 /* We may have switched to 1-bit mode during suspend */
                 err = sdio_enable_4bit_bus(host->card);
                 if (err > 0) {
--
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

#4 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 36 lines · Subhash Jadavani
Quoted 24 lines · Ulf Hansson
Quoted 21 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
  drivers/mmc/core/sdio.c |    6 ++++--
  1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
         mmc_claim_host(host);
Quoted 8 lines

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 942

Quoted 5 lines
drivers/mmc/core/sdio.c +3 -1
         /* No need to reinitialize powered-resumed nonremovable cards */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Quoted 3 lines

Yes, the regulator powering the card is always on in this case which means SDIO VDD is not powered off during the suspend.

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow. That could be a more proper way of solving this maybe? What do you think?

Quoted 28 lines
Quoted 26 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 14 lines
drivers/mmc/core/sdio.c +1 -1
                 err = mmc_sdio_init_card(host, host->ocr, host->card,
                                         mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
                 /* We may have switched to 1-bit mode during suspend */

                 err = sdio_enable_4bit_bus(host->card);
                 if (err > 0) {

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

author
#5 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 32 lines · Ulf Hansson
Quoted 31 lines · Subhash Jadavani
Quoted 29 lines · Ulf Hansson
Quoted 18 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
   drivers/mmc/core/sdio.c |    6 ++++--
   1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 942

Quoted 7 lines
drivers/mmc/core/sdio.c +3 -1
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
          mmc_claim_host(host);
 
          /* No need to reinitialize powered-resumed nonremovable cards */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host)) {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Quoted 6 lines
Quoted 3 lines

Yes, the regulator powering the card is always on in this case which means SDIO VDD is not powered off during the suspend.

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow. That could be a more proper way of solving this maybe? What do you think?

Ok.
Basically this would be the suspend/resume sequence with Keep Power flag cleared.

Suspend:
1. Execute Function driver suspend
2. mmc_power_off()
2.1 As this is regulator powering card SDIO VDD line is always on
regulator, it will stay on.

Resume:
1. mmc_power_up()
1.1 Regulator was anyway on so nothing change here.
2. mmc_sdio_init_card() - reinitialize the card
2.1 CMD5 gets the commands response timeout which means card
doesn't respond back.

My understanding is that behaviour seen in 2.1 (resume) is because during suspend, function driver suspend might have done something with the SDIO card (as keep power flag was disabled) and that's the reason during resume, card fails to respond back to CMD5 (unless we send the CMD52 to reset the card). It's an athros SDIO wifi card here.

Quoted 1 line
Quoted 1 line

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow.

Given the above issue, i am not sure how is this suggestion going to help in this case?

Regards,
Subhash

Quoted 25 lines
Quoted 25 lines
Quoted 24 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 14 lines
drivers/mmc/core/sdio.c +1 -1
                  err = mmc_sdio_init_card(host, host->ocr, host->card,
                                          mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
                  /* We may have switched to 1-bit mode during suspend */

                  err = sdio_enable_4bit_bus(host->card);
                  if (err > 0) {

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

#6 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 46 lines · Subhash Jadavani
Quoted 45 lines · Ulf Hansson
Quoted 42 lines · Subhash Jadavani
Quoted 24 lines · Ulf Hansson
Quoted 21 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
   drivers/mmc/core/sdio.c |    6 ++++--
   1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
          mmc_claim_host(host);
Quoted 10 lines

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 944

Quoted 7 lines
drivers/mmc/core/sdio.c +3 -1
          /* No need to reinitialize powered-resumed nonremovable cards
 */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
 {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Yes, the regulator powering the card is always on in this case which means
SDIO VDD is not powered off during the suspend.

Quoted 7 lines
Quoted 3 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow. That could be a more proper way of solving this maybe? What do you think?

Ok.
Basically this would be the suspend/resume sequence with Keep Power flag cleared.

I mean the exact opposite. :-)

mmc_keep_power should be _set_ during suspend/resume sequence.

That will mean at suspend; sdio_disable_4bit_bus will be called and mmc_power_off will not.
At resume, sdio_enable_4bit_bus will be called, without doing mmc_power_up and mmc_sdio_init_card.

Do note that there is no API for the setting mmc_keep_power from a host. It exist only in the SDIO API. (sdio_set_host_pm_flags). So I guess we should invent this API for the host to use.

Quoted 60 lines

Suspend:
1. Execute Function driver suspend
2. mmc_power_off()
2.1 As this is regulator powering card SDIO VDD line is always on
regulator, it will stay on.

Resume:
1. mmc_power_up()
1.1 Regulator was anyway on so nothing change here.
2. mmc_sdio_init_card() - reinitialize the card
2.1 CMD5 gets the commands response timeout which means card doesn't
respond back.

My understanding is that behaviour seen in 2.1 (resume) is because during suspend, function driver suspend might have done something with the SDIO card (as keep power flag was disabled) and that's the reason during resume, card fails to respond back to CMD5 (unless we send the CMD52 to reset the card). It's an athros SDIO wifi card here.

Quoted 2 lines
Quoted 2 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow.

Given the above issue, i am not sure how is this suggestion going to help in this case?

Regards,
Subhash

Quoted 29 lines
Quoted 29 lines
Quoted 27 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 16 lines
drivers/mmc/core/sdio.c +1 -1
                  err = mmc_sdio_init_card(host, host->ocr, host->card,
                                          mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) &&

mmc_card_wake_sdio_irq(host)) {
                  /* We may have switched to 1-bit mode during suspend
*/
                  err = sdio_enable_4bit_bus(host->card);
                  if (err > 0) {

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

author
#7 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 51 lines · Ulf Hansson
Quoted 40 lines · Subhash Jadavani
Quoted 39 lines · Ulf Hansson
Quoted 37 lines · Subhash Jadavani
Quoted 22 lines · Ulf Hansson
Quoted 20 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
    drivers/mmc/core/sdio.c |    6 ++++--
    1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host *host)
           mmc_claim_host(host);
Quoted 9 lines

drivers/mmc/core/sdio.c static int mmc_sdio_resume(struct mmc_host *host) · line 944

Quoted 7 lines
drivers/mmc/core/sdio.c +3 -1
           /* No need to reinitialize powered-resumed nonremovable cards
 */
-       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
+       if (mmc_card_is_removable(host) || !mmc_card_keep_power(host))
 {
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Yes, the regulator powering the card is always on in this case which means
SDIO VDD is not powered off during the suspend.

Quoted 6 lines
Quoted 3 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow. That could be a more proper way of solving this maybe? What do you think?

Ok.
Basically this would be the suspend/resume sequence with Keep Power flag cleared.

I mean the exact opposite. :-)

mmc_keep_power should be _set_ during suspend/resume sequence.

Quoted 8 lines

That will mean at suspend; sdio_disable_4bit_bus will be called and mmc_power_off will not.
At resume, sdio_enable_4bit_bus will be called, without doing mmc_power_up and mmc_sdio_init_card.

Do note that there is no API for the setting mmc_keep_power from a host. It exist only in the SDIO API. (sdio_set_host_pm_flags). So I guess we should invent this API for the host to use.

Thanks Ulf. I got your point. Will try out your suggestion and will update (with patch & result) soon.
On the other hand,
Do you see it's worth to have this current patch as well? I guess it's safe to do sdio_reset() before SDIO card init and we are already playing safe even in mmc_rescan*() by calling sdio_reset() before card detection.

Regards,
Subhash

Quoted 56 lines
Quoted 56 lines

Suspend:
1. Execute Function driver suspend
2. mmc_power_off()
2.1 As this is regulator powering card SDIO VDD line is always on
regulator, it will stay on.

Resume:
1. mmc_power_up()
1.1 Regulator was anyway on so nothing change here.
2. mmc_sdio_init_card() - reinitialize the card
2.1 CMD5 gets the commands response timeout which means card doesn't
respond back.

My understanding is that behaviour seen in 2.1 (resume) is because during suspend, function driver suspend might have done something with the SDIO card (as keep power flag was disabled) and that's the reason during resume, card fails to respond back to CMD5 (unless we send the CMD52 to reset the card). It's an athros SDIO wifi card here.

Quoted 2 lines
Quoted 2 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow.

Given the above issue, i am not sure how is this suggestion going to help in this case?

Regards,
Subhash

Quoted 26 lines
Quoted 26 lines
Quoted 25 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 16 lines
drivers/mmc/core/sdio.c +1 -1
                   err = mmc_sdio_init_card(host, host->ocr, host->card,
                                           mmc_card_keep_power(host));
-       else if (mmc_card_keep_power(host) &&
 mmc_card_wake_sdio_irq(host)) {
+       } else if (mmc_card_keep_power(host) &&

mmc_card_wake_sdio_irq(host)) {
                   /* We may have switched to 1-bit mode during suspend
*/
                   err = sdio_enable_4bit_bus(host->card);
                   if (err > 0) {

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

Acked-by
#8 lore raw

Re: [PATCH v1 1/3] mmc: sdio: fix resume failure

Quoted 73 lines · Subhash Jadavani
Quoted 72 lines · Ulf Hansson
Quoted 51 lines · Subhash Jadavani
Quoted 49 lines · Ulf Hansson
Quoted 46 lines · Subhash Jadavani
Quoted 25 lines · Ulf Hansson
Quoted 22 lines · Subhash Jadavani

If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would be reinitialized during resume but as we are not resetting (CMD52 reset) the SDIO card during this reinitialization, card may fail to respond back to subsequent commands (CMD5 etc...).

This change resets the card before the reinitialization of card during resume.

Signed-off-by Subhash Jadavani <[email protected]>
---
    drivers/mmc/core/sdio.c |    6 ++++--
    1 files changed, 4 insertions(+), 2 deletions(-)
drivers/mmc/core/sdio.c +0 -0
index 2273ce6..34ad4c8 100644
@@ -937,10 +937,12 @@ static int mmc_sdio_resume(struct mmc_host
 *host)
           mmc_claim_host(host);
Quoted 13 lines

drivers/mmc/core/sdio.c

Quoted 10 lines
drivers/mmc/core/sdio.c +0 -0
           /* No need to reinitialize powered-resumed nonremovable

cards
*/
- if (mmc_card_is_removable(host) ||
!mmc_card_keep_power(host))
+ if (mmc_card_is_removable(host) ||
!mmc_card_keep_power(host))
{

drivers/mmc/core/sdio.c +2 -0
+               sdio_reset(host);
+               mmc_go_idle(host);

If the card has lost power, why is this needed? Could it be that the host is not capable of cutting the power to card?

Yes, the regulator powering the card is always on in this case which means
SDIO VDD is not powered off during the suspend.

Quoted 8 lines
Quoted 4 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow. That could be a more proper way of solving this maybe? What do you think?

Ok.
Basically this would be the suspend/resume sequence with Keep Power flag cleared.

I mean the exact opposite. :-)

mmc_keep_power should be _set_ during suspend/resume sequence.

That will mean at suspend; sdio_disable_4bit_bus will be called and mmc_power_off will not.
At resume, sdio_enable_4bit_bus will be called, without doing mmc_power_up and mmc_sdio_init_card.

Quoted 7 lines
Quoted 3 lines

Do note that there is no API for the setting mmc_keep_power from a host. It exist only in the SDIO API. (sdio_set_host_pm_flags). So I guess we should invent this API for the host to use.

Thanks Ulf. I got your point. Will try out your suggestion and will update (with patch & result) soon.

OK, great. You may keep me on cc.

Quoted 5 lines

On the other hand,
Do you see it's worth to have this current patch as well? I guess it's safe to do sdio_reset() before SDIO card init and we are already playing safe even in mmc_rescan*() by calling sdio_reset() before card detection.

That is a valid point. So you have my Ack for this patch!

Quoted 71 lines

Regards,
Subhash

Quoted 66 lines
Quoted 66 lines

Suspend:
1. Execute Function driver suspend
2. mmc_power_off()
2.1 As this is regulator powering card SDIO VDD line is always on
regulator, it will stay on.

Resume:
1. mmc_power_up()
1.1 Regulator was anyway on so nothing change here.
2. mmc_sdio_init_card() - reinitialize the card
2.1 CMD5 gets the commands response timeout which means card
doesn't
respond back.

My understanding is that behaviour seen in 2.1 (resume) is because during suspend, function driver suspend might have done something with the SDIO card (as keep power flag was disabled) and that's the reason during resume,
card fails to respond back to CMD5 (unless we send the CMD52 to reset the card). It's an athros SDIO wifi card here.

Quoted 2 lines
Quoted 2 lines

So in principle the host should be able to notify the protocol layer about that mmc_card_keep_power will always be set somehow.

Given the above issue, i am not sure how is this suggestion going to help in
this case?

Regards,
Subhash

Quoted 32 lines
Quoted 32 lines
Quoted 30 lines

It might be more safe to do this but I would like to understand more, before you get my ack on this patch.

Quoted 19 lines
                   err = mmc_sdio_init_card(host, host->ocr,

host->card,

mmc_card_keep_power(host));
- else if (mmc_card_keep_power(host) &&
mmc_card_wake_sdio_irq(host)) {
+ } else if (mmc_card_keep_power(host) &&

mmc_card_wake_sdio_irq(host)) {
                   /* We may have switched to 1-bit mode during
suspend
*/
                   err = sdio_enable_4bit_bus(host->card);
                   if (err > 0) {

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 5 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kind regards
Ulf Hansson

Acked-by Ulf Hansson <[email protected]>

Kind regards
Ulf Hansson

author
#9 lore raw

PATCH 2/3 mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

In reply to Subhash Jadavani

From: Sujit Reddy Thumma <[email protected]>

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.

Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c  |   22 +++++++++++-----------
 include/linux/mmc/host.h |    8 ++++++++
 2 files changed, 19 insertions(+), 11 deletions(-)
drivers/mmc/core/sdio.c +11 -11
index 34ad4c8..9565d38 100644
@@ -157,10 +157,7 @@ static int sdio_read_cccr(struct mmc_card *card, u32 ocr)
 			if (ret)
 				goto out;
 
-			if (card->host->caps &
-				(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
-				 MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
-				 MMC_CAP_UHS_DDR50)) {
+			if (mmc_host_uhs(card->host)) {
 				if (data & SDIO_UHS_DDR50)
 					card->sw_caps.sd3_bus_mode
 						|= SD_MODE_UHS_DDR50;

@@ -478,8 +475,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
 	 * If the host doesn't support any of the UHS-I modes, fallback on
 	 * default speed.
 	 */
-	if (!(card->host->caps & (MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
-	    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_UHS_DDR50)))
+	if (!mmc_host_uhs(card->host))
 		return 0;
 
 	bus_speed = SDIO_SPEED_SDR12;

@@ -645,11 +641,7 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
 	 * systems that claim 1.8v signalling in fact do not support
 	 * it.
 	 */
-	if ((ocr & R4_18V_PRESENT) &&
-		(host->caps &
-			(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
-			 MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
-			 MMC_CAP_UHS_DDR50))) {
+	if ((ocr & R4_18V_PRESENT) && mmc_host_uhs(host)) {
 		err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180,
 				true);
 		if (err) {

@@ -1022,6 +1014,10 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
 		goto out;
 	}
 
+	if (mmc_host_uhs(host))
+		/* to query card if 1.8V signalling is supported */
+		host->ocr |= R4_18V_PRESENT;
+
 	ret = mmc_sdio_init_card(host, host->ocr, host->card,
 				mmc_card_keep_power(host));
 	if (!ret && host->sdio_irqs)

@@ -1087,6 +1083,10 @@ int mmc_attach_sdio(struct mmc_host *host)
 	/*
 	 * Detect and init the card.
 	 */
+	if (mmc_host_uhs(host))
+		/* to query card if 1.8V signalling is supported */
+		host->ocr |= R4_18V_PRESENT;
+
 	err = mmc_sdio_init_card(host, host->ocr, NULL, 0);
 	if (err) {
 		if (err == -EAGAIN) {
include/linux/mmc/host.h +8 -0
index 23df21e..9be0440 100644
@@ -433,6 +433,14 @@ static inline int mmc_boot_partition_access(struct mmc_host *host)
 	return !(host->caps2 & MMC_CAP2_BOOTPART_NOACC);
 }
 
+static inline int mmc_host_uhs(struct mmc_host *host)
+{
+	return host->caps &
+		(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 |
+		 MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR104 |
+		 MMC_CAP_UHS_DDR50);
+}
+
 #ifdef CONFIG_MMC_CLKGATE
 void mmc_host_clk_hold(struct mmc_host *host);
 void mmc_host_clk_release(struct mmc_host *host);
Signature · 2 lines
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
#10 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 6 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 7 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c  |   22 +++++++++++-----------
 include/linux/mmc/host.h |    8 ++++++++
 2 files changed, 19 insertions(+), 11 deletions(-)
#11 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Bing,

The function mmc_host_uhs() will return false and never set bit[24] (S18R) for SDIO 2.0 cards.

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bing Zhao
Sent: Wednesday, December 05, 2012 5:14 AM
To: Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 5 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 7 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#12 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Jackey,

Quoted 3 lines

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

Quoted 38 lines

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bing Zhao
Sent: Wednesday, December 05, 2012 5:14 AM
To: Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 5 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 7 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#13 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

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.

Thanks,
Jackey

-----Original Message-----
From: Bing Zhao [mailto:[email protected]]
Sent: Thursday, December 06, 2012 3:14 AM
To: Shen, Jackey; Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Jackey,

Quoted 3 lines

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

Quoted 41 lines

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bing Zhao
Sent: Wednesday, December 05, 2012 5:14 AM
To: Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 5 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 7 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#14 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Jackey,

Quoted 4 lines

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

Quoted 65 lines

Thanks,
Jackey

-----Original Message-----
From: Bing Zhao [mailto:[email protected]]
Sent: Thursday, December 06, 2012 3:14 AM
To: Shen, Jackey; Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Jackey,

Quoted 3 lines

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

Quoted 41 lines

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bing Zhao
Sent: Wednesday, December 05, 2012 5:14 AM
To: Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 5 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 7 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#15 lore raw

Re: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Quoted 9 lines · Bing Zhao

Hi Jackey,

Quoted 4 lines

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?

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.
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.

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.

I hope this make sense.

Regards,
Subhash

Quoted 62 lines

Thanks,
Bing

Quoted 58 lines

Thanks,
Jackey

-----Original Message-----
From: Bing Zhao [mailto:[email protected]]
Sent: Thursday, December 06, 2012 3:14 AM
To: Shen, Jackey; Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Jackey,

Quoted 3 lines

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

Quoted 37 lines

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bing Zhao
Sent: Wednesday, December 05, 2012 5:14 AM
To: Subhash Jadavani; [email protected]
Cc: [email protected]; Sujit Reddy Thumma
Subject: RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi,

Quoted 5 lines

From: Sujit Reddy Thumma <[email protected]>

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

Quoted 6 lines
Signed-off-by Sujit Reddy Thumma <[email protected]>
Signed-off-by Subhash Jadavani <[email protected]>
---
  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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#16 lore raw

RE: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Hi Subhash,

Quoted 10 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

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

Quoted 6 lines

I hope this make sense.

Regards,
Subhash

Reviewed-by on v1 2/3
#17 lore raw

Re: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

In reply to Subhash Jadavani

Hi,

2012/12/4 Subhash Jadavani <[email protected]>:

Quoted 7 lines

From: Sujit Reddy Thumma <[email protected]>

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.

Reviewed-by Johan Rudholm <[email protected]>
Reviewed-by
#18 lore raw

Re: [PATCH v1 2/3] mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

Quoted 11 lines · Johan Rudholm

Hi,

2012/12/4 Subhash Jadavani <[email protected]>:

Quoted 7 lines

From: Sujit Reddy Thumma <[email protected]>

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.

Quoted 5 lines
Reviewed-by Johan Rudholm <[email protected]>

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Reviewed-by Ulf Hansson <[email protected]>
author
#19 lore raw

PATCH 3/3 mmc: sdio: print correct UHS mode during card detection

In reply to Subhash Jadavani

When SDIO3.0 card is detected, incorrect bus speed mode is printed as part of card detection print in kernel logs.

This change fixes it so that user won't be confused by looking at incorrect card detection message in logs.

Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
drivers/mmc/core/sdio.c +5 -0
index 9565d38..3a64933 100644
@@ -485,23 +485,27 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
 			bus_speed = SDIO_SPEED_SDR104;
 			timing = MMC_TIMING_UHS_SDR104;
 			card->sw_caps.uhs_max_dtr = UHS_SDR104_MAX_DTR;
+			card->sd_bus_speed = UHS_SDR104_BUS_SPEED;
 	} else if ((card->host->caps & MMC_CAP_UHS_DDR50) &&
 		   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_DDR50)) {
 			bus_speed = SDIO_SPEED_DDR50;
 			timing = MMC_TIMING_UHS_DDR50;
 			card->sw_caps.uhs_max_dtr = UHS_DDR50_MAX_DTR;
+			card->sd_bus_speed = UHS_DDR50_BUS_SPEED;
 	} else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
 		    MMC_CAP_UHS_SDR50)) && (card->sw_caps.sd3_bus_mode &
 		    SD_MODE_UHS_SDR50)) {
 			bus_speed = SDIO_SPEED_SDR50;
 			timing = MMC_TIMING_UHS_SDR50;
 			card->sw_caps.uhs_max_dtr = UHS_SDR50_MAX_DTR;
+			card->sd_bus_speed = UHS_SDR50_BUS_SPEED;
 	} else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
 		    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25)) &&
 		   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_SDR25)) {
 			bus_speed = SDIO_SPEED_SDR25;
 			timing = MMC_TIMING_UHS_SDR25;
 			card->sw_caps.uhs_max_dtr = UHS_SDR25_MAX_DTR;
+			card->sd_bus_speed = UHS_SDR25_BUS_SPEED;
 	} else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
 		    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25 |
 		    MMC_CAP_UHS_SDR12)) && (card->sw_caps.sd3_bus_mode &

@@ -509,6 +513,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
 			bus_speed = SDIO_SPEED_SDR12;
 			timing = MMC_TIMING_UHS_SDR12;
 			card->sw_caps.uhs_max_dtr = UHS_SDR12_MAX_DTR;
+			card->sd_bus_speed = UHS_SDR12_BUS_SPEED;
 	}
 
 	err = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &speed);
Signature · 2 lines
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Acked-by on v1 3/3
#20 lore raw

Re: [PATCH v1 3/3] mmc: sdio: print correct UHS mode during card detection

Quoted 55 lines · Subhash Jadavani

When SDIO3.0 card is detected, incorrect bus speed mode is printed as part of card detection print in kernel logs.

This change fixes it so that user won't be confused by looking at incorrect card detection message in logs.

Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
drivers/mmc/core/sdio.c +5 -2
index 9565d38..3a64933 100644
@@ -485,23 +485,27 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
                        bus_speed = SDIO_SPEED_SDR104;
                        timing = MMC_TIMING_UHS_SDR104;
                        card->sw_caps.uhs_max_dtr = UHS_SDR104_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR104_BUS_SPEED;
        } else if ((card->host->caps & MMC_CAP_UHS_DDR50) &&
                   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_DDR50)) {
                        bus_speed = SDIO_SPEED_DDR50;
                        timing = MMC_TIMING_UHS_DDR50;
                        card->sw_caps.uhs_max_dtr = UHS_DDR50_MAX_DTR;
+                       card->sd_bus_speed = UHS_DDR50_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50)) && (card->sw_caps.sd3_bus_mode &
                    SD_MODE_UHS_SDR50)) {
                        bus_speed = SDIO_SPEED_SDR50;
                        timing = MMC_TIMING_UHS_SDR50;
                        card->sw_caps.uhs_max_dtr = UHS_SDR50_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR50_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25)) &&
                   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_SDR25)) {
                        bus_speed = SDIO_SPEED_SDR25;
                        timing = MMC_TIMING_UHS_SDR25;
                        card->sw_caps.uhs_max_dtr = UHS_SDR25_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR25_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25 |
                    MMC_CAP_UHS_SDR12)) && (card->sw_caps.sd3_bus_mode &

@@ -509,6 +513,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
                        bus_speed = SDIO_SPEED_SDR12;
                        timing = MMC_TIMING_UHS_SDR12;
                        card->sw_caps.uhs_max_dtr = UHS_SDR12_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR12_BUS_SPEED;
        }
 
        err = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0, &speed);
--
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Acked-by Ulf Hansson <[email protected]>
Tested-by Acked-by Ulf Hansson
#21 lore raw

RE: [PATCH v1 3/3] mmc: sdio: print correct UHS mode during card detection

Hi,

Tested-by Jackey Shen <[email protected]>

Thanks,
Jackey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ulf Hansson
Sent: Thursday, December 06, 2012 6:42 PM
To: Subhash Jadavani
Cc: [email protected]; [email protected]
Subject: Re: [PATCH v1 3/3] mmc: sdio: print correct UHS mode during card detection

Quoted 58 lines · Subhash Jadavani

When SDIO3.0 card is detected, incorrect bus speed mode is printed as part of card detection print in kernel logs.

This change fixes it so that user won't be confused by looking at incorrect card detection message in logs.

Signed-off-by Subhash Jadavani <[email protected]>
---
 drivers/mmc/core/sdio.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
drivers/mmc/core/sdio.c index renamed from drivers/mmc/core/sdio.c +0 -0

9565d38..3a64933 100644

drivers/mmc/core/sdio.c +4 -0
@@ -485,23 +485,27 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
                        bus_speed = SDIO_SPEED_SDR104;
                        timing = MMC_TIMING_UHS_SDR104;
                        card->sw_caps.uhs_max_dtr = 
 UHS_SDR104_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR104_BUS_SPEED;
        } else if ((card->host->caps & MMC_CAP_UHS_DDR50) &&
                   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_DDR50)) {
                        bus_speed = SDIO_SPEED_DDR50;
                        timing = MMC_TIMING_UHS_DDR50;
                        card->sw_caps.uhs_max_dtr = UHS_DDR50_MAX_DTR;
+                       card->sd_bus_speed = UHS_DDR50_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50)) && (card->sw_caps.sd3_bus_mode &
                    SD_MODE_UHS_SDR50)) {
                        bus_speed = SDIO_SPEED_SDR50;
                        timing = MMC_TIMING_UHS_SDR50;
                        card->sw_caps.uhs_max_dtr = UHS_SDR50_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR50_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25)) &&
                   (card->sw_caps.sd3_bus_mode & SD_MODE_UHS_SDR25)) {
                        bus_speed = SDIO_SPEED_SDR25;
                        timing = MMC_TIMING_UHS_SDR25;
                        card->sw_caps.uhs_max_dtr = UHS_SDR25_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR25_BUS_SPEED;
        } else if ((card->host->caps & (MMC_CAP_UHS_SDR104 |
                    MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_SDR25 |

                    MMC_CAP_UHS_SDR12)) && (card->sw_caps.sd3_bus_mode 
& @@ -509,6 +513,7 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card)
                        bus_speed = SDIO_SPEED_SDR12;
                        timing = MMC_TIMING_UHS_SDR12;
                        card->sw_caps.uhs_max_dtr = UHS_SDR12_MAX_DTR;
+                       card->sd_bus_speed = UHS_SDR12_BUS_SPEED;
        }

        err = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_SPEED, 0,

&speed);
--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 4 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Acked-by Ulf Hansson <[email protected]>

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 86988B169C1CD04598F5B80198CCE50E738D93@aphydexd01b

author
#24 lore raw

Hi Chris,

Can i request you to merge following 3 patches to mmc-next? Ulf have acked all 3 patches and Johan Rudholm also reviewed one of them.

Regards,
Subhash

Quoted 33 lines

-------- Original Message --------
Subject: [PATCH v1 0/3] SDIO fixes
Date: Tue, 4 Dec 2012 17:06:17 +0530
From: Subhash Jadavani <[email protected]>
To: [email protected]
CC: [email protected], Subhash Jadavani <[email protected]>

This patch-series is having 1 fix for SDIO resume and 2 fixes related to SDIO3.0 card detection

Subhash Jadavani (2):
mmc: sdio: fix resume failure
mmc: sdio: print correct UHS mode during card detection

Sujit Reddy Thumma (1):
mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

   drivers/mmc/core/sdio.c  |   33 ++++++++++++++++++++-------------
   include/linux/mmc/host.h |    8 ++++++++
   2 files changed, 28 insertions(+), 13 deletions(-)

--
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#25 lore raw

Hi Subhash,

Quoted 6 lines · Subhash Jadavani

This patch-series is having 1 fix for SDIO resume and 2 fixes related to SDIO3.0 card detection

Subhash Jadavani (2):
mmc: sdio: fix resume failure
mmc: sdio: print correct UHS mode during card detection

Quoted 6 lines

Sujit Reddy Thumma (1):
mmc: sdio: Fix SDIO 3.0 UHS-I initialization sequence

   drivers/mmc/core/sdio.c  |   33 ++++++++++++++++++++-------------
   include/linux/mmc/host.h |    8 ++++++++
   2 files changed, 28 insertions(+), 13 deletions(-)

Thanks, pushed all three patches to mmc-next.

- Chris.

Signature · 2 lines
Chris Ball   <[email protected]>   <http://printf.net/>
One Laptop Per Child