Hash: SHA1

Somebody in the thread at some point said:
| Thanks for the link, seems to be quite valuable to me as it explains the
| background quite well!
|     Something similar has been happening with SD cards on the OLPC laptop
|     (another example of hardware specifically designed for the FOSS world)
|     for at least the last six months.  Last time I checked, there was
|     no real fix.
| Well, from recent comments it looks like a 400ms delay (yuck!) in
| drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as
| Andy already suggested) seems to be related to the resume cycle.
|     Has been a major pain for people who want to multiboot  --
|      forces them to use storage devices that don't fit inside the case.
|     http://dev.laptop.org/ticket/6532
| At least it doesn't look like a HW issue with the card, then.

Yes when we originally had this problem I found OLPC had it and indeed
Eee PC at that time.  What "cured" it for us was removing the low level
debug config option in the kernel, but that really is all about changing
timing too.

There's another complicated problem that can be related about the
relationship between the PMU and the Glamo.  The PMU device is only
created really late in boot because it is on I2C bus.  That means it is
suspended very early in suspend, yanking a lot of power rails (including
the CPU core power!  But it goes on long enough from caps) before the
MMC stack has a chance to talk to the card and close it down gently.

Although suspend / resume has been acting well these last weeks it is
fragile and we'll be doing a lot more work on it.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


Openmoko community mailing list

Reply via email to