On Wed, Jan 12, 2011 at 9:48 AM, Steve Sakoman <sakoman@xxxxxxxxx> wrote:
> On Tue, Jan 11, 2011 at 10:17 PM, Ghorai, Sukumar <s-ghorai@xxxxxx> wrote:
>
>> [Ghorai]
>> We also experienced the same issue using 32GB SD card for omap3 and omap4.
>> And the problem is seen is that DTO value (in SYSCTL) is not current
>> in following function.
>>
>> So add the following modification and please update the status.
>> And we will submit proper patch towards the same.
>>
>> static void set_data_timeout(..){
>> ...
>> cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
>> timeout = timeout_ns / cycle_ns;
>> timeout += timeout_clks;
>> + timeout *=2;
>> if (timeout) {
>> ...
>> }
>
> I tried this change. While it seemed to improve things a bit for the
> ADATA card I tested, I was still not able to boot successfully.
>
> I will investigate further. Forcing a value of 14 makes the card
> work. I'll add a printk to see what dto value is computed by your
> patch.
The printk showed that dto was being set in the range 11-13 with your patch.
I still was seeing some corruption occurring with the patch -- but at
a much lower level that without the patch.
Since I knew that the card would definitely work if dto were hard
coded to 14, I next tried bumping the value your patch computed by 1:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9c7c590..09a7e21 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1372,6 +1372,7 @@ static void set_data_timeout(struct omap_hsmmc_host *host,
dto -= 13;
else
dto = 0;
+ dto++;
if (dto > 14)
dto = 14;
}
I've been running fairly intensive testing for the past 6 hours with out issue.
This chunk of code really should be reviewed by an mmc expert -- I
have a feeling that it could be simplified or at least made a bit
easier to understand!
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
