On Tue, May 17, 2011 at 8:09 AM, Alban Browaeys <prahal@xxxxxxxxx> wrote:
>> On Tue, Mar 29, 2011 at 10:32 AM, Paul Hartman
>> <paul.hartman+maemo at gmail.com> wrote:
>> > I've got three microSD cards. They work fine on my PCs, I've done
>> > read/write tests and data is not corrupted. But, in my N900, two of
>> > the three are not stable, leading to corruption.
>>
>> I've made a simple modification to the omap_hsmmc module and now the
>> errors and corruption seem to be gone completely. I will test some
>> more and see if it lasts. So far so good. Fingers crossed. Knock on
>> wood. :)
>
>
> May I ask you what was this simple modification . Even if it ended not working fully it might
> provide clues.
In linux kernel sources drivers/mmc/host/omap_hsmmc.c replace the
set_data_timeout function with this one:
static void set_data_timeout(struct omap_hsmmc_host *host,
unsigned int timeout_ns,
unsigned int timeout_clks)
{
uint32_t reg;
reg = OMAP_HSMMC_READ(host->base, SYSCTL);
reg &= ~DTO_MASK;
reg |= DTO << DTO_SHIFT;
OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);
}
Basically, it changes it to use the default DTO value of 0xE rather
than trying to calculate dynamic DTO based on the particular SD card
timings and characteristics. I read this advice on the linux-omap
mailing list from someone having the same problem (but with different
hardware).
I don't know if it's a problem in the driver DTO calculation logic, or
bad metadata in the SD cards causing that logic to be flawed. The same
workaround is done in other drivers for standard SD cards, too. Some
question why bother to change the DTO at all, if 0xE works with all of
them.
After a month using it like this, I have no problems. My SD card works
fine, no corruption.
_______________________________________________
maemo-users mailing list
maemo-users@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users
