On Wed, Jan 12, 2011 at 8:30 PM, Steve Sakoman <sakoman@xxxxxxxxx> wrote:
> 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.
Just to add another data point, Transcend 16GB Class 6 cards will not
work on OMAP3 with an unpatched kernel -- lots of -110 timeout errors.
With the patches above the card does work.
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
