[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value
Return value of mmc_send_if_cond() can be safely ignored (as it is done in Linux). This makes older cards work with MXC MCI controller.
Signed-off-by: Ilya Yanok yanok@emcraft.com --- drivers/mmc/mmc.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 925f863..64a311d 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -868,10 +868,6 @@ int mmc_init(struct mmc *mmc) /* Test for SD version 2 */ err = mmc_send_if_cond(mmc);
- /* If we got an error other than timeout, we bail */ - if (err && err != TIMEOUT) - return err; - /* Now try to get the SD card's operating condition */ err = sd_send_op_cond(mmc);
Hi Ilya,
/* Now try to get the SD card's operating condition */ err = sd_send_op_cond(mmc);
I am using your set of patches on the MX31 board. I am not getting any command response for the sd_send_op_cond(mmc) called from the mmc. I think you claimed it will work on mxcs including mx3 which i also believed should be true. But the code fails to do a voltage validation for all the cards i tried(normal SD's)
In fact i think there is another issue with the generic mmc code. In my case i have the /* mmc_send_if_cond(mmc);*/ commented out. Please enlighten as to what could be a problem.
Thanks.
Hi Alfred,
alfred steele wrote:
Hi Ilya,
/* Now try to get the SD card's operating condition */ err = sd_send_op_cond(mmc);I am using your set of patches on the MX31 board. I am not getting any command response for the sd_send_op_cond(mmc) called from the mmc. I think you claimed it will work on mxcs including mx3 which i also believed should be true. But the code fails to do a voltage validation for all the cards i tried(normal SD's)
I've only tried my patch on i.MX27 board. I mentioned that it may work on MX3's too cause the kernel driver used as a source works on both MX2 and MX3. You need to do some changes for my driver to work on MX3. Check the pins configuration and if you have MCI clock signal enabled. Also you should use another function to get the clock rate on MX31. Sorry, I can't debug the driver on mx31 now, you should do it yourself. Probably you may also want to discard my generic mmc patches (except for this one) and pull from u-boot-mmc tree instead.
Regards, Ilya.
Thanks for the much waited reply.
I've only tried my patch on i.MX27 board. I mentioned that it may work on MX3's too cause the kernel driver used as a source works on both MX2 and MX3. You need to do some changes for my driver to work on MX3. Check the pins configuration and if you have MCI clock signal enabled.
As a quickstart, I am actually trying to look at the mxcmci_probe() for the init stuff. I hope thats the correct approach for finding the initialization stuff. Another For the GPIOs to set the signals right(data/clk/cmd) , i am using the following chunk of code.
Also
you should use another function to get the clock rate on MX31. Sorry, I can't debug the driver on mx31 now, you should do it yourself.
Apologize if i had menat that in my emails, i never meant that you test it on the mx31 board
Probably
you may also want to discard my generic mmc patches (except for this
one) and pull from u-boot-mmc tree instead.
Would it matter even if i use the patch?
Looks like accidently somehow pressed the send button. Apologize!
Thanks for the much awaited reply.
I've only tried my patch on i.MX27 board. I mentioned that it may work on MX3's too cause the kernel driver used as a source works on both MX2 and MX3. You need to do some changes for my driver to work on MX3. Check the pins configuration and if you have MCI clock signal enabled.
As a quickstart, I am actually trying to look at the mxcmci_probe() for the init stuff. I hope thats the correct approach for finding the initialization stuff.For the GPIOs to set the signals right(data/clk/cmd) , i need to initialize them. The linux mxc_request_iomux() api seems to be a cumbersome although porting it would need removing the IO_ADDRESS and the spinlock stuff. What approach did you have for porting the iomux.c linux code.As for the clock_enable part and attaining the prescaler and the dividers foer clock generation, how did you do it. I can only see a linux api called clock_enable in the probe() routine for the same. However, i did not see anything similar in your patch. Is it in the generic arm code location in uboot(arm/mx27/)?
Another confusion is on the spba_take_ownership() spba_take_ownership(SPBA_SDHC1, SPBA_MASTER_A | SPBA_MASTER_C); What does spba (shared peripheral bus access)do and do i have to play with it for the SDHC. From the manual it doesn't look like so, but is beiong used in the linux board init code. I hope mx27 should be similar.
you should use another function to get the clock rate on MX31. Sorry, I can't debug the driver on mx31 now, you should do it yourself.
Apologize if i had meant that in my email, i never wanted you test it on the mx31 board . I just need some pointers to accelerate the development.
Thanks for your help.
-Alfred.
Hi Alfred,
my English is not perfect really... but I'm actually having hard times trying to understand yours... So I give you my excuses in advance for possible misunderstandings...
alfred steele wrote:
Looks like accidently somehow pressed the send button. Apologize!
Thanks for the much awaited reply.
I've only tried my patch on i.MX27 board. I mentioned that it may work on MX3's too cause the kernel driver used as a source works on both MX2 and MX3. You need to do some changes for my driver to work on MX3. Check the pins configuration and if you have MCI clock signal enabled.
As a quickstart, I am actually trying to look at the mxcmci_probe() for the init stuff. I hope thats the correct approach for finding the initialization stuff.For the GPIOs to set the signals right(data/clk/cmd) , i need to initialize them. The linux mxc_request_iomux() api seems to be a cumbersome although porting it would need removing the IO_ADDRESS and the spinlock stuff.
I believe it's enough to use mx31_gpio_mux() here. You just need to figure out correct arguments. But if you'll port complete iomuxing API from Linux and post it here I think nobody will be unhappy ;)
What approach did you have for porting the iomux.c linux code.As for the clock_enable part and attaining the prescaler and the dividers foer clock generation, how did you do it. I can only see a linux api called clock_enable in the probe() routine for the same.
We don't have clocks API in U-Boot. You need to enable the clock by setting appropriate bit in the clocks control register manually.
However, i did not see anything similar in your patch. Is it in the generic arm code location in uboot(arm/mx27/)?
No, it's in board-specific part.
Another confusion is on the spba_take_ownership() spba_take_ownership(SPBA_SDHC1, SPBA_MASTER_A | SPBA_MASTER_C); What does spba (shared peripheral bus access)do and do i have to play with it for the SDHC. From the manual it doesn't look like so, but is beiong used in the linux board init code. I hope mx27 should be similar.
Hmm... I didn't touch any SPBA setting on mx27... But it may be needed on mx31... Look at the spba_take_ownership() code and if it does somethings with registers try setting registers to the same values from your board code.
you should use another function to get the clock rate on MX31. Sorry, I can't debug the driver on mx31 now, you should do it yourself.
Apologize if i had meant that in my email, i never wanted you test it on the mx31 board . I just need some pointers to accelerate the development.
That's all I can tell you: check pins configuration, check if the clocks are enabled and if mx31 has more than one MMC controller check that you are trying to talk to the one with card connector (or just try other choices).
Regards, Ilya.
Hi,
my English is not perfect really... but I'm actually having hard times trying to understand yours... So I give you my excuses in advance for possible misunderstandings...
IMO too, I know i have a horrible English . Trying to improve;) Pls dont hesitate in asking em to rephrase.
I believe it's enough to use mx31_gpio_mux() here. You just need to figure out correct arguments. But if you'll port complete iomuxing API from Linux and post it here I think nobody will be unhappy ;)
I get it.
We don't have clocks API in U-Boot. You need to enable the clock by setting appropriate bit in the clocks control register manually.
Why do i have to touch the CCM? IIRC, Can't it be controlled with the STR_STP_CLOCK (bit 0). When i read the CCM using md.l it shows the Clock output set to IPG_CLK already which is an input the internally generated MMC_SD_CLK. Please correct me if am wrong. Hmm... I didn't touch any SPBA setting on mx27... But it may be needed
on mx31... Look at the spba_take_ownership() code and if it does somethings with registers try setting registers to the same values from your board code.
I have it set in my code, it does not make any difference . I think it makes sense only for interrupt and dma transfers although i am not sure. Another thing i wasn't sure of was as to where is the endianness and bus width for the host controller getting set in the mx27 code?
That's all I can tell you: check pins configuration, check if the clocks are enabled and if mx31 has more than one MMC controller check that you are trying to talk to the one with card connector (or just try other choices).
Thanks Ilya. Will try.
-Alfred.
Hi Alfred,
alfred steele wrote:
We don't have clocks API in U-Boot. You need to enable the clock by setting appropriate bit in the clocks control register manually.
Why do i have to touch the CCM? IIRC, Can't it be controlled with the STR_STP_CLOCK (bit 0). When i read the CCM using md.l it shows the Clock output set to IPG_CLK already which is an input the internally generated MMC_SD_CLK. Please correct me if am wrong.
Well, I can't really give you some definite answers here... Now I'm concentrated on mx27 and we have separate bits for controlling SDHC clocks here (they are not in CCM but in PCCR0)... Just make sure that you have all needed clocks enabled.
Hmm... I didn't touch any SPBA setting on mx27... But it may be needed
on mx31... Look at the spba_take_ownership() code and if it does somethings with registers try setting registers to the same values from your board code.
I have it set in my code, it does not make any difference . I think it makes sense only for interrupt and dma transfers although i am not sure. Another thing i wasn't sure of was as to where is the endianness and bus width for the host controller getting set in the mx27 code?
I don't think that can be an issue.
That's all I can tell you: check pins configuration, check if the clocks are enabled and if mx31 has more than one MMC controller check that you are trying to talk to the one with card connector (or just try other choices).
Thanks Ilya. Will try.
Trying another controller may be a good option (just don't forget that you need to configure different pins). I faced that problem myself: I was trying to find the card at SDHC0 but it turned out that it's connected to SDHC1... And AFAIR in my case I didn't get answer for OP_COND too (actually not getting answer for OP_COND means that there is no card).
Regards, Ilya.
Hi Ilya,
Just make sure that you have all needed clocks enabled.
Thanks!One thing i forgot mentioning is that when i had adopted your patch on my baseline code, i started getting the infamous 'u64 ' (64 bit) division LINK errors while compiling with EABI rooting out of the clock based calculations.(prescalar and divider etc.) Hence i googled out and found out two patches that fix-arm920t-eabi.patch uboot-eabi-fix-HACK.patch I applied these patches hand edited some files to fix the compilation problem. I know you had some latest patches to use lldiv() instead but how did you get rid of the compile issues without lldiv initially. Are you compiling without EABI?
-Alfred.
Hi Alfred,
alfred steele wrote:
Just make sure that you have all needed clocks enabled.
Thanks!One thing i forgot mentioning is that when i had adopted your patch on my baseline code, i started getting the infamous 'u64 ' (64 bit) division LINK errors while compiling with EABI rooting out of the clock based calculations.(prescalar and divider etc.) Hence i googled out and found out two patches that fix-arm920t-eabi.patch uboot-eabi-fix-HACK.patch I applied these patches hand edited some files to fix the compilation problem. I know you had some latest patches to use lldiv() instead but how did you get rid of the compile issues without lldiv initially. Are you compiling without EABI?
You really should use lldiv() for 64-bit division. I had the same compile issues.
Regards, Ilya.
Dear Ilya Yanok,
In message 1242295389-3682-1-git-send-email-yanok@emcraft.com you wrote:
Return value of mmc_send_if_cond() can be safely ignored (as it is done in Linux). This makes older cards work with MXC MCI controller.
Signed-off-by: Ilya Yanok yanok@emcraft.com
drivers/mmc/mmc.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)
Applied to master. Thanks.
Best regards,
Wolfgang Denk
On Wed, Jun 3, 2009 at 5:15 PM, Wolfgang Denk wd@denx.de wrote:
Dear Ilya Yanok,
In message 1242295389-3682-1-git-send-email-yanok@emcraft.com you wrote:
Return value of mmc_send_if_cond() can be safely ignored (as it is done in Linux). This makes older cards work with MXC MCI controller.
Signed-off-by: Ilya Yanok yanok@emcraft.com
drivers/mmc/mmc.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)
Applied to master. Thanks.
Wolfgang, I have an identical, but different patch from Yauhen Kharuzhy applied to my tree, ready for pulling... I can take it out, but I hope I don't have to back out a bunch of patches. :)
Dear Andy,
In message 2acbd3e40906031657jac92a86y9a0de40c6b1c96bf@mail.gmail.com you wrote:
Wolfgang, I have an identical, but different patch from Yauhen Kharuzhy
That's a funny thing - "identical, but different". really? :-)
applied to my tree, ready for pulling... I can take it out, but I hope I don't have to back out a bunch of patches. :)
Git sorted this out just fine, it seems.
--000e0cd4d83a1e43ed046b7a6c55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Wed, Jun 3, 2009 at 5:15 PM, Wolfgang=
...
Um... please don't send HTML.
Best regards,
Wolfgang Denk
participants (4)
-
alfred steele -
Andy Fleming -
Ilya Yanok -
Wolfgang Denk