Am Mi 3. Dezember 2008 schrieb Ruediger Helge Wolf: > Hi... > > >> [WSOD] > > > FYI: Harald Welte (the original author of this code) suspects this to > > be a timing problem / command ordering problem when reenabling the > > display. I have a device that exposes this problem at runtime which > > he's going to inspect on the 27th of this month. > > > Any news? Anything we can help with? Further investigations? What about > the FIC guys, do they know about the issue?
We are aware of the problem. Last few days we did all sorts of timing tweaking inside driver, to the extent of lowering SPI-CLOCK, and compared datasheet of JBT6K74 with timing setup in driver. Impact on WSOD was nonexistent. Command ordering seems a somewhat less probable source of this issue, as it's the same that is executed on device-init during boot and we don't see any WSOD there. Also command ordering isn't very likely to yield random result, like we see in WSOD issue. Futher findings: The problem seems to be specific to the particular LCM, as swapping the LCM of a device with 95% WSOD resulted in 40 consecutive resumes without WSOD. The "no deep_suspend" patch didn't work for us -> it's a problem often triggered by but not directly caused by deep_suspend. Further plans: modify driver to take down the complete LCM via LDO6 instead of entering deep_suspend. This seems to be the more reasonable approach for saving power while LCM disabled anyway, and it might cure WSOD as the LCM is powered up from suspend-mode the same way as on boot. Side-effects still under investigation (sneak currents, any persistent data lost during power down, timing issues for LCM coming up) cheers jOERG
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ support mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/support
