[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Ilya Yanok]

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);
 
-- 
1.6.0.6

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[alfred steele]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Ilya Yanok]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[alfred steele]

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?

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[alfred steele]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Ilya Yanok]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[alfred steele]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Ilya Yanok]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[alfred steele]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Ilya Yanok]

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.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Andy Fleming]

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

[U-Boot] [PATCH] mmc: it's safe to ignore mmc_send_if_cond() return value

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.