Skip to contentSkip to conversation

SDHC/MMC: fix the wrong infomation after change SD card

PATCH New Chang-Ming.Huang at freescale.com 5 participants 12 messages May 18, 2012 – Jul 30, 2012 MMC, SD and SDIO

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/2 SDHC/MMC: fix the wrong infomation after change SD card

From: Jerry Huang <[email protected]>

When first inserting the SD card to slot, the command "mmcinfo" can display the card information correctly.
But, then removing the SD card or inserting another SD card to slot, the command "mmcinfo" can't display the information correctly.

when we use command "mmcinfo" every time, the driver must initialize the SD card again, instead of assuming the card has been initialized.

Therefore remove the detect codes from mmc_init function. And add the codes to check the mmc_init, only when mmc_init return the right value, driver will print the information.

Below is the error log (SD card removed):
=> mmcinfo
MMC: no card present
Device: FSL_SDHC
Manufacturer ID: 3
OEM: 5344
Name: SD02G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1.8 GiB
Bus Width: 4-bit

CC Andy Fleming <[email protected]>
CC Marek Vasut <[email protected]>

---
changes for v2:
- keep the member has_init
- only remove the detect code

 common/cmd_mmc.c  |    5 ++---
 drivers/mmc/mmc.c |    3 ---
 2 files changed, 2 insertions(+), 6 deletions(-)
common/cmd_mmc.c +2 -3
index 750509d..e73ce03 100644
@@ -131,9 +131,8 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	mmc = find_mmc_device(curr_device);
 
 	if (mmc) {
-		mmc_init(mmc);
-
-		print_mmcinfo(mmc);
+		if (!mmc_init(mmc))
+			print_mmcinfo(mmc);
 		return 0;
 	} else {
 		printf("no mmc device at slot %x\n", curr_device);
drivers/mmc/mmc.c +0 -3
index f92b662..af644bb 100644
@@ -1323,9 +1323,6 @@ int mmc_init(struct mmc *mmc)
 		return NO_CARD_ERR;
 	}
 
-	if (mmc->has_init)
-		return 0;
-
 	err = mmc->init(mmc);
 
 	if (err)
Signature · 1 line
1.7.5.4
#1 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2), in order to detect the SD card, we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.

CC Andy Fleming <[email protected]>
CC Marek Vasut <[email protected]>

---
changes for v2:
- correct the typo
changes for v3:
- enable all clock bits for VVN2.3 and VVN2.2
- use funciton esdhc_setbits32
- tested on p1022ds, p1025rdb, p1020mbg-pc, mpc8536ds, p3041ds

 drivers/mmc/fsl_esdhc.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
drivers/mmc/fsl_esdhc.c +3 -0
index a2f35e3..930a5c5 100644
@@ -491,6 +491,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg)
 	/* First reset the eSDHC controller */
 	esdhc_reset(regs);
 
+	esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN
+				| SYSCTL_IPGEN | SYSCTL_CKEN);
+
 	mmc->priv = cfg;
 	mmc->send_cmd = esdhc_send_cmd;
 	mmc->set_ios = esdhc_set_ios;
Signature · 1 line
1.7.5.4
#2 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

Quoted 8 lines · Chang-Ming.Huang at freescale.com

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2), in order to detect the SD card, we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.

Again, have you talked to a hardware designer and confirmed that there's no impact from setting these bits on chips where they're reserved? Just because you don't notice any obvious impact doesn't mean it's totally safe.

-Scott

#3 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

Best Regards
Jerry Huang

Quoted 18 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: Friday, May 18, 2012 11:55 PM
To: Huang Changming-R66093
Cc: u-boot at lists.denx.de; Marek Vasut; Andy Fleming
Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Quoted 8 lines · Chang-Ming.Huang at freescale.com

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2), in order to detect the SD card, we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.

Quoted 5 lines

Again, have you talked to a hardware designer and confirmed that there's no impact from setting these bits on chips where they're reserved? Just because you don't notice any obvious impact doesn't mean it's totally safe.

Do you read the FSL SDHC driver? If not, please read it first.
Without my this patch, FSL SDHC driver has done it as I mentioned.
The committer provided the patch to support VVN2.3 should talk to the hardware designer, And he think it is safe. Otherwise he should detect the VVN to do the different thing. The below is the code driver enable these bit:
In function set_sysctl:
clk = SYSCTL_PEREN | SYSCTL_CKEN;
in function esdhc_init:
esdhc_write32(&regs->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN);

My work is just to pick up the codes from the driver and do it again in function fsl_esdhc_initialize:
esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN

                                | SYSCTL_IPGEN | SYSCTL_CKEN);
#4 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

Hi, Andy
There is not any feedback for very long time,
Could it be applied to u-boot?

Best Regards
Jerry Huang

Quoted 58 lines

-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Huang Changming-R66093
Sent: Monday, May 21, 2012 10:35 AM
To: Wood Scott-B07421
Cc: Marek Vasut; u-boot at lists.denx.de; Andy Fleming
Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Best Regards
Jerry Huang

Quoted 18 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: Friday, May 18, 2012 11:55 PM
To: Huang Changming-R66093
Cc: u-boot at lists.denx.de; Marek Vasut; Andy Fleming
Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Quoted 8 lines · Chang-Ming.Huang at freescale.com

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2), in order to detect the SD card, we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.

Quoted 5 lines

Again, have you talked to a hardware designer and confirmed that there's no impact from setting these bits on chips where they're reserved? Just because you don't notice any obvious impact doesn't mean it's totally safe.

Do you read the FSL SDHC driver? If not, please read it first. Without my this patch, FSL SDHC driver has done it as I mentioned. The committer provided the patch to support VVN2.3 should talk to the hardware designer, And he think it is safe. Otherwise he should detect the VVN to do the different thing.
The below is the code driver enable these bit:
In function set_sysctl:
clk = SYSCTL_PEREN | SYSCTL_CKEN;
in function esdhc_init:
esdhc_write32(&regs->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN);

My work is just to pick up the codes from the driver and do it again in function fsl_esdhc_initialize:
esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN

                                | SYSCTL_IPGEN | SYSCTL_CKEN);

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#5 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

Dear Huang Changming-R66093,

Quoted 3 lines

Hi, Andy
There is not any feedback for very long time,
Could it be applied to u-boot?

Could it be we have a maintainer problem and unhappy contributor problem in here?

Quoted 61 lines

Best Regards
Jerry Huang

Quoted 58 lines

-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Huang Changming-R66093
Sent: Monday, May 21, 2012 10:35 AM
To: Wood Scott-B07421
Cc: Marek Vasut; u-boot at lists.denx.de; Andy Fleming
Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Best Regards
Jerry Huang

Quoted 18 lines

-----Original Message-----
From: Wood Scott-B07421
Sent: Friday, May 18, 2012 11:55 PM
To: Huang Changming-R66093
Cc: u-boot at lists.denx.de; Marek Vasut; Andy Fleming
Subject: Re: [U-Boot] [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Quoted 8 lines · Chang-Ming.Huang at freescale.com

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2), in order to detect the SD card, we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.

Quoted 4 lines

Again, have you talked to a hardware designer and confirmed that there's no impact from setting these bits on chips where they're reserved? Just because you don't notice any obvious impact doesn't mean it's totally safe.

Do you read the FSL SDHC driver? If not, please read it first. Without my this patch, FSL SDHC driver has done it as I mentioned. The committer provided the patch to support VVN2.3 should talk to the hardware designer, And he think it is safe. Otherwise he should detect the VVN to do the different thing.
The below is the code driver enable these bit:
In function set_sysctl:
clk = SYSCTL_PEREN | SYSCTL_CKEN;
in function esdhc_init:
esdhc_write32(&regs->sysctl, SYSCTL_HCKEN | SYSCTL_IPGEN);

My work is just to pick up the codes from the driver and do it again in function fsl_esdhc_initialize:
esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN

                                | SYSCTL_IPGEN | SYSCTL_CKEN);

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Best regards,
Marek Vasut

#6 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

In reply to Chang-Ming.Huang at freescale.com

Dear Chang-Ming.Huang at freescale.com,

Quoted 3 lines

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2)

What's VVN2.2 ?

Quoted 5 lines

, in order to detect the SD card,
we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP

VVN2.3 ?

Quoted 23 lines

, these bits are reserved, and SDCLKEN is used.
And when accessing to these reserved bit, no any impact happened.

CC Andy Fleming <[email protected]>
CC Marek Vasut <[email protected]>

---
changes for v2:
- correct the typo
changes for v3:
- enable all clock bits for VVN2.3 and VVN2.2
- use funciton esdhc_setbits32
- tested on p1022ds, p1025rdb, p1020mbg-pc, mpc8536ds, p3041ds

 drivers/mmc/fsl_esdhc.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
drivers/mmc/fsl_esdhc.c +0 -0
index a2f35e3..930a5c5 100644
@@ -491,6 +491,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct

fsl_esdhc_cfg *cfg) /* First reset the eSDHC controller */

drivers/mmc/fsl_esdhc.c int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg) · line 499

Quoted 8 lines
drivers/mmc/fsl_esdhc.c +3 -0
 	esdhc_reset(regs);
 
+	esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN
+				| SYSCTL_IPGEN | SYSCTL_CKEN);
+
 	mmc->priv = cfg;
 	mmc->send_cmd = esdhc_send_cmd;
 	mmc->set_ios = esdhc_set_ios;

Best regards,
Marek Vasut

#7 lore raw

PATCH v3 2/2 FSL/eSDHC: enable the clock to detect the SD card

VVN2.2/VVN2.3 is the vendor version number, that is the FSL SDHC IP verion.

Best Regards
Jerry Huang

Quoted 58 lines

-----Original Message-----
From: Marek Vasut [mailto:marex at denx.de]
Sent: Saturday, May 19, 2012 12:03 AM
To: Huang Changming-R66093
Cc: u-boot at lists.denx.de; Andy Fleming
Subject: Re: [PATCH 2/2 v3] FSL/eSDHC: enable the clock to detect the SD card

Dear Chang-Ming.Huang at freescale.com,

Quoted 3 lines

From: Jerry Huang <[email protected]>

For FSL low-end processors (VVN2.2)

What's VVN2.2 ?

Quoted 5 lines

, in order to detect the SD card,
we should enable PEREN, HCKEN and IPGEN to enable the clock. Otherwise, after booting the u-boot, and then inserting the SD card, the SD card can't be detected.
For SDHC VVN2.3 IP

VVN2.3 ?

Quoted 23 lines

, these bits are reserved, and SDCLKEN is used.
And when accessing to these reserved bit, no any impact happened.

CC Andy Fleming <[email protected]>
CC Marek Vasut <[email protected]>

---
changes for v2:
- correct the typo
changes for v3:
- enable all clock bits for VVN2.3 and VVN2.2
- use funciton esdhc_setbits32
- tested on p1022ds, p1025rdb, p1020mbg-pc, mpc8536ds, p3041ds

 drivers/mmc/fsl_esdhc.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
drivers/mmc/fsl_esdhc.c index renamed from drivers/mmc/fsl_esdhc.c +0 -0

a2f35e3..930a5c5 100644

drivers/mmc/fsl_esdhc.c +0 -0
@@ -491,6 +491,9 @@ int fsl_esdhc_initialize(bd_t *bis, struct

fsl_esdhc_cfg *cfg) /* First reset the eSDHC controller */

drivers/mmc/fsl_esdhc.c int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg) · line 499

Quoted 8 lines
drivers/mmc/fsl_esdhc.c +3 -0
 	esdhc_reset(regs);
 
+	esdhc_setbits32(&regs->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN
+				| SYSCTL_IPGEN | SYSCTL_CKEN);
+
 	mmc->priv = cfg;
 	mmc->send_cmd = esdhc_send_cmd;
 	mmc->set_ios = esdhc_set_ios;

Best regards,
Marek Vasut

#8 lore raw

PATCH v2 1/2 SDHC/MMC: fix the wrong infomation after change SD card

In reply to Chang-Ming.Huang at freescale.com

Hi, Andy,
There is not any feedback for very long time,
Could it be applied to the u-boot?

Best Regards
Jerry Huang

Quoted 81 lines

-----Original Message-----
From: Huang Changming-R66093
Sent: Friday, May 18, 2012 5:57 PM
To: u-boot at lists.denx.de
Cc: Huang Changming-R66093; Andy Fleming; Marek Vasut
Subject: [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card

From: Jerry Huang <[email protected]>

When first inserting the SD card to slot, the command "mmcinfo" can display the card information correctly.
But, then removing the SD card or inserting another SD card to slot, the command "mmcinfo" can't display the information correctly.

when we use command "mmcinfo" every time, the driver must initialize the SD card again, instead of assuming the card has been initialized.

Therefore remove the detect codes from mmc_init function. And add the codes to check the mmc_init, only when mmc_init return the right value, driver will print the information.

Below is the error log (SD card removed):
=> mmcinfo
MMC: no card present
Device: FSL_SDHC
Manufacturer ID: 3
OEM: 5344
Name: SD02G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1.8 GiB
Bus Width: 4-bit

CC Andy Fleming <[email protected]>
CC Marek Vasut <[email protected]>

---
changes for v2:
- keep the member has_init
- only remove the detect code

 common/cmd_mmc.c  |    5 ++---
 drivers/mmc/mmc.c |    3 ---
 2 files changed, 2 insertions(+), 6 deletions(-)
common/cmd_mmc.c +2 -3
index 750509d..e73ce03 100644
@@ -131,9 +131,8 @@ int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc,
 char * const argv[])
 	mmc = find_mmc_device(curr_device);
 
 	if (mmc) {
-		mmc_init(mmc);
-
-		print_mmcinfo(mmc);
+		if (!mmc_init(mmc))
+			print_mmcinfo(mmc);
 		return 0;
 	} else {
common/cmd_mmc.c +0 -0
 		printf("no mmc device at slot %x\n", curr_device);
drivers/mmc/mmc.c +0 -4
index f92b662..af644bb 100644
@@ -1323,9 +1323,6 @@ int mmc_init(struct mmc *mmc)
 		return NO_CARD_ERR;
 	}
 
-	if (mmc->has_init)
-		return 0;
-
 	err = mmc->init(mmc);
 
 	if (err)
--

1.7.5.4

#9 lore raw

PATCH v2 1/2 SDHC/MMC: fix the wrong infomation after change SD card

Quoted 3 lines · On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093 <[email protected]>…

Hi, Andy,
There is not any feedback for very long time,
Could it be applied to the u-boot?

I'm afraid I have to reject this patch. We need to find a better solution to the two problems:

1) We want to change cards and still have mmc commands work
2) We don't want eMMC devices to be slowed down by constantly re-initializing their cards.

Normally, I would err on the side of #1, but there's a simple workaround. If you replace the card, execute "mmc rescan", and the card will be reinitialized. Please let me know if that workaround doesn't work. I hope, in the future, we'll have some code which makes both possible, by being able to detect that a card has been changed, but for now I think the current system is reasonably satisfactory to both cases #1 and #2.

Andy

#10 lore raw

PATCH v2 1/2 SDHC/MMC: fix the wrong infomation after change SD card

Dear Andy Fleming,

Quoted 14 lines

On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093

Quoted 3 lines · <[email protected]> wrote:

Hi, Andy,
There is not any feedback for very long time,
Could it be applied to the u-boot?

I'm afraid I have to reject this patch. We need to find a better solution to the two problems:

1) We want to change cards and still have mmc commands work
2) We don't want eMMC devices to be slowed down by constantly re-initializing their cards.

Quoted 7 lines

Normally, I would err on the side of #1, but there's a simple workaround. If you replace the card, execute "mmc rescan", and the card will be reinitialized. Please let me know if that workaround doesn't work. I hope, in the future, we'll have some code which makes both possible, by being able to detect that a card has been changed, but for now I think the current system is reasonably satisfactory to both cases #1 and #2.

Andy, I don't want to be a bastard, but do you happen to be overloaded? Or what is the exact reason your replies to patches are so slow?

Best regards,
Marek Vasut

#11 lore raw

PATCH v2 1/2 SDHC/MMC: fix the wrong infomation after change SD card

In reply to Andy Fleming

Hi, Andy
Could you give some reason why eMMC device will be so slowed down by re-initialization? I think eMMC device is initialized only once, except it invoke 'mmc_init' many times.

The workaround "mmc rescan" works when replace the card.
But if one card is removed, then use "mmcfinfo": there is no card present, while the previous card information is displayed, I don't' think it make sense. => mmc rescan
MMC: no card present
=> mmcinfo
MMC: no card present
Device: FSL_SDHC
Manufacturer ID: 2
OEM: 544d
Name: SD04G
Tran Speed: 50000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit

Best Regards
Jerry Huang

Quoted 31 lines

-----Original Message-----
From: Andy Fleming [mailto:afleming at gmail.com]
Sent: Saturday, July 14, 2012 5:33 AM
To: Huang Changming-R66093
Cc: u-boot at lists.denx.de; Marek Vasut
Subject: Re: [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card

Quoted 3 lines · On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093 <[email protected]>…

Hi, Andy,
There is not any feedback for very long time,
Could it be applied to the u-boot?

I'm afraid I have to reject this patch. We need to find a better solution to the two problems:

1) We want to change cards and still have mmc commands work
2) We don't want eMMC devices to be slowed down by constantly re-initializing their cards.

Normally, I would err on the side of #1, but there's a simple workaround. If you replace the card, execute "mmc rescan", and the card will be reinitialized. Please let me know if that workaround doesn't work. I hope, in the future, we'll have some code which makes both possible, by being able to detect that a card has been changed, but for now I think the current system is reasonably satisfactory to both cases #1 and #2.

Andy