From: David Brown <hidden> Date: 2011-02-15 23:49:04
On Tue, Feb 15 2011, Russell King - ARM Linux wrote:
This patch is for RFC only; it needs splitting up somewhat. However, I
wanted to get it out there for some comment.
Just for kicks, I applied this and ran it on an MSM target (8x50). It
seems to cause lots of:
mmc0: Data timeout
mmc0: Controller has been re-initialized
...
mmc0: Data CRC error
and I can post more if you would find them interesting. Eventually the
MSM mmc driver derefernces a null pointer in the interrupt code.
It's also possible this is finding problems in our SDCC driver.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, Feb 15 2011, Russell King - ARM Linux wrote:
quoted
This patch is for RFC only; it needs splitting up somewhat. ?However, I
wanted to get it out there for some comment.
Just for kicks, I applied this and ran it on an MSM target (8x50). ?It
seems to cause lots of:
?mmc0: Data timeout
?mmc0: Controller has been re-initialized
?...
?mmc0: Data CRC error
and I can post more if you would find them interesting. ?Eventually the
MSM mmc driver derefernces a null pointer in the interrupt code.
It's also possible this is finding problems in our SDCC driver.
The SDCC is obviously an MMCI derivate, VHDL hacking
on top of ARMs source code for PL180/PL181.
Why do you insist on maintaining a forked driver?
Please consider switching to using mmci.c like everyone else.
The quirks we have in place for U300, Nomadik and Ux500
should show you the way for how to do this (yes we did the
same thing, hacking the ARM VHDL).
If I remember correctly I could even see that some early
Android sources were using Russells mmci.c driver before this
fork was created.
Yours,
Linus Walleij
From: Russell King - ARM Linux <hidden> Date: 2011-02-19 15:00:06
On Tue, Feb 15, 2011 at 03:49:04PM -0800, David Brown wrote:
On Tue, Feb 15 2011, Russell King - ARM Linux wrote:
quoted
This patch is for RFC only; it needs splitting up somewhat. However, I
wanted to get it out there for some comment.
Just for kicks, I applied this and ran it on an MSM target (8x50). It
seems to cause lots of:
mmc0: Data timeout
mmc0: Controller has been re-initialized
...
mmc0: Data CRC error
and I can post more if you would find them interesting. Eventually the
MSM mmc driver derefernces a null pointer in the interrupt code.
That doesn't look right. If resetting the MMC controller results in all
state being lost, it presumably means the card gets powered down too.
If that happens, the card needs to be reinitialized from scratch again,
and I don't see how that happens in this driver.
Nothing in this patch should cause data timeouts to appear where they
weren't already appearing before the patch - the patch only changes
what happens after an error occurs, so you must already be encountering
errors on the interface before you applied this patch.
Hi Russell King,
On Sat, 2011-02-19 at 15:00 +0000, Russell King - ARM Linux wrote:
On Tue, Feb 15, 2011 at 03:49:04PM -0800, David Brown wrote:
quoted
On Tue, Feb 15 2011, Russell King - ARM Linux wrote:
quoted
This patch is for RFC only; it needs splitting up somewhat. However, I
wanted to get it out there for some comment.
Just for kicks, I applied this and ran it on an MSM target (8x50). It
seems to cause lots of:
mmc0: Data timeout
mmc0: Controller has been re-initialized
...
mmc0: Data CRC error
and I can post more if you would find them interesting. Eventually the
MSM mmc driver derefernces a null pointer in the interrupt code.
That doesn't look right. If resetting the MMC controller results in all
state being lost, it presumably means the card gets powered down too.
If that happens, the card needs to be reinitialized from scratch again,
and I don't see how that happens in this driver.
Nothing in this patch should cause data timeouts to appear where they
weren't already appearing before the patch - the patch only changes
what happens after an error occurs, so you must already be encountering
errors on the interface before you applied this patch.
This patch sends CMD22 (mmc_sd_num_wr_blocks()) for SD cards after a
write command. This function relies on csd->tacc_ns and csd->tacc_clks
for setting timeout values. But for SDHC cards, these CSD values are not
read and will always be 0. The host driver will only use the timeout
values sent by upper layers and thus in this case we are writing 0 to
MMCIDATATIMER. This is the reason for getting data timeout error for
CMD22. Before sending CMD22 if I add mmc_set_data_timeout(), then it is
working fine for me because mmc_set_data_timeout() uses hardcoded
timeout values for SDHC cards.
All other SD read commands are also using mmc_set_data_timeout() to set
the timeout values - mmc_sd_switch(), mmc_app_sd_status() and
mmc_app_send_scr(). I think it is a problem in mmc_sd_num_wr_blocks to
use CSD contents for timeout values for all types of SD cards.
--
Thanks,
Sahitya.
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.