[U-Boot] [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card
From: Jerry Huang Chang-Ming.Huang@freescale.com
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
Signed-off-by: Jerry Huang Chang-Ming.Huang@freescale.com CC: Andy Fleming afleming@gmail.com CC: Marek Vasut marex@denx.de --- 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(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 750509d..e73ce03 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -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); diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index f92b662..af644bb 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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)
From: Jerry Huang Chang-Ming.Huang@freescale.com
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.
Signed-off-by: Jerry Huang Chang-Ming.Huang@freescale.com CC: Andy Fleming afleming@gmail.com CC: Marek Vasut marex@denx.de --- 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(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a2f35e3..930a5c5 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -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(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN + | SYSCTL_IPGEN | SYSCTL_CKEN); + mmc->priv = cfg; mmc->send_cmd = esdhc_send_cmd; mmc->set_ios = esdhc_set_ios;
On 05/18/2012 04:57 AM, Chang-Ming.Huang@freescale.com wrote:
From: Jerry Huang Chang-Ming.Huang@freescale.com
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
Best Regards Jerry Huang
-----Original Message----- From: Wood Scott-B07421 Sent: Friday, May 18, 2012 11:55 PM To: Huang Changming-R66093 Cc: u-boot@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
On 05/18/2012 04:57 AM, Chang-Ming.Huang@freescale.com wrote:
From: Jerry Huang Chang-Ming.Huang@freescale.com
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.
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(®s->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(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN | SYSCTL_IPGEN | SYSCTL_CKEN);
Hi, Andy There is not any feedback for very long time, Could it be applied to u-boot?
Best Regards Jerry Huang
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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@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
-----Original Message----- From: Wood Scott-B07421 Sent: Friday, May 18, 2012 11:55 PM To: Huang Changming-R66093 Cc: u-boot@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
On 05/18/2012 04:57 AM, Chang-Ming.Huang@freescale.com wrote:
From: Jerry Huang Chang-Ming.Huang@freescale.com
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.
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(®s->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(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN | SYSCTL_IPGEN | SYSCTL_CKEN);
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Huang Changming-R66093,
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?
Best Regards Jerry Huang
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@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@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
-----Original Message----- From: Wood Scott-B07421 Sent: Friday, May 18, 2012 11:55 PM To: Huang Changming-R66093 Cc: u-boot@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
On 05/18/2012 04:57 AM, Chang-Ming.Huang@freescale.com wrote:
From: Jerry Huang Chang-Ming.Huang@freescale.com
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.
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(®s->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(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN
| SYSCTL_IPGEN | SYSCTL_CKEN);
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Best regards, Marek Vasut
Dear Chang-Ming.Huang@freescale.com,
From: Jerry Huang Chang-Ming.Huang@freescale.com
For FSL low-end processors (VVN2.2)
What's 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
VVN2.3 ?
, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.
Signed-off-by: Jerry Huang Chang-Ming.Huang@freescale.com CC: Andy Fleming afleming@gmail.com CC: Marek Vasut marex@denx.de
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(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a2f35e3..930a5c5 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -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(®s->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
VVN2.2/VVN2.3 is the vendor version number, that is the FSL SDHC IP verion.
Best Regards Jerry Huang
-----Original Message----- From: Marek Vasut [mailto:marex@denx.de] Sent: Saturday, May 19, 2012 12:03 AM To: Huang Changming-R66093 Cc: u-boot@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@freescale.com,
From: Jerry Huang Chang-Ming.Huang@freescale.com
For FSL low-end processors (VVN2.2)
What's 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
VVN2.3 ?
, these bits are reserved, and SDCLKEN is used. And when accessing to these reserved bit, no any impact happened.
Signed-off-by: Jerry Huang Chang-Ming.Huang@freescale.com CC: Andy Fleming afleming@gmail.com CC: Marek Vasut marex@denx.de
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(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a2f35e3..930a5c5 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -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(®s->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
Hi, Andy, There is not any feedback for very long time, Could it be applied to the u-boot?
Best Regards Jerry Huang
-----Original Message----- From: Huang Changming-R66093 Sent: Friday, May 18, 2012 5:57 PM To: u-boot@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 Chang-Ming.Huang@freescale.com
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
Signed-off-by: Jerry Huang Chang-Ming.Huang@freescale.com CC: Andy Fleming afleming@gmail.com CC: Marek Vasut marex@denx.de
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(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 750509d..e73ce03 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -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);diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index f92b662..af644bb 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -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
On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093 r66093@freescale.com 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.
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
Dear Andy Fleming,
On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093
r66093@freescale.com 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:
- We want to change cards and still have mmc commands work
- 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, 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
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
-----Original Message----- From: Andy Fleming [mailto:afleming@gmail.com] Sent: Saturday, July 14, 2012 5:33 AM To: Huang Changming-R66093 Cc: u-boot@lists.denx.de; Marek Vasut Subject: Re: [PATCH 1/2 v2] SDHC/MMC: fix the wrong infomation after change SD card
On Wed, Jul 11, 2012 at 4:29 AM, Huang Changming-R66093 r66093@freescale.com 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:
- We want to change cards and still have mmc commands work
- 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
participants (5)
-
Andy Fleming -
Chang-Ming.Huang＠freescale.com -
Huang Changming-R66093 -
Marek Vasut -
Scott Wood