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