WSOD solutions??

[Joerg Reisenweber]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/support/attachments/20081204/075f2217/attachment.pgp