On 30.5.2011 13:32, Grazvydas Ignotas wrote:
In general I don't think hardcoding highest possible value is a good idea, it might hurt detection times or SDIO operation on faster cards where those timeouts are expected to happen. I'd much prefer this instead: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;...
OK. This is better than current state so please add it if you feel OK with it. Thank you.
When googling the description I see this patch is already committed to many other OMAP linux trees of various projects.
I tried to understand the code computing the dto variable. It looks like it tries to find a position of first highest nonzero bit in the timeout value, then it adds one more if the timeout is not exactly power of two value (i.e. rounding it up to nearest power of two value).
The rest is making it to fit into the DTO field of SYSCTL register which is described as 0x0: TCF x 2^13 0x1: TCF x 2^14 ... 0xE: TCF x 2^27 0xF: Reserved while TCF is the timeout clock base frequency (MMCi.MMCHS_CAPA[5:0] TCF bits) which is hopefully equal to mmc clock frequency (=clk_get_rate(host->fclk) / clkd) for all this to make some sense.
So unless there is off by one bit shift bug in the code, or the TRM or HW is wrong, this looks like the *=2 just adds random safety margin for buggy cards (resulting in dto variable being +1 in the end). Let's hope this margin is big enough for all such cards.
Do you have a card affected by this to test?
Yes, I have one specific card - Transcend Class 10 16GB and see this quite frequently when trying to write to it. No problems to test the fix.
Frantisek