Hi,
could you merge a kernel mmc workaround into next FW hotfix? The issue is described here http://talk.maemo.org/showthread.php?p=1000707#post1000707 and applies to OpenPandora too. See e.g. here http://boards.openpandora.org/index.php?/topic/1592-sd-card-instability/page...
When looking at kernel source http://preview.tinyurl.com/3dp3otd the code still has the complex (and possibly too optimistic) computation in place.
Thanks Frantisek
Hello,
On Mon, May 30, 2011 at 11:32 AM, Frantisek Dufka dufkaf@gmail.com wrote:
Hi,
could you merge a kernel mmc workaround into next FW hotfix? The issue is described here http://talk.maemo.org/showthread.php?p=1000707#post1000707 and applies to OpenPandora too. See e.g. here http://boards.openpandora.org/index.php?/topic/1592-sd-card-instability/page...
Do you have a patch for our tree?
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;...
Do you have a card affected by this to test?
Gražvydas
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
On Mon, May 30, 2011 at 6:43 PM, Frantisek Dufka dufkaf@gmail.com wrote:
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.
Yeah, that code looks correct to me. Maybe it's too precise, most controllers might have some extra room "just in case", and card manufacturers could have started relying on it, who knows. Or it could be some hardware quirk, even one of my cards is affected by this on 2.6.37 where interrupt code has been rewritten, but works fine here on the older 2.6.27 code.
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.
Here, copy this to /boot/uImage: http://notaz.gp2x.de/tmp/uImage_mmc_tout_test
should be HF5 compatible, let me know if it helps.
Gražvydas