Measurements: Massive Display-related power savings

Harald Welte laforge at
Fri Oct 17 11:24:32 CEST 2008

On Wed, Oct 15, 2008 at 04:21:38PM +0200, Klaus Kurzmann wrote:
> * Michael 'Mickey' Lauer <mickey at> [081015 14:22]:
> > Am Wednesday 15 October 2008 06:38:01 schrieb Mike (mwester):
> > > > FSO should switch the backlight control from the sysfs method to the
> > > > fbdev-ioctl method.  It's backwards compatible to old kernels (which will
> > > > just backlight-blank) and future-compatible with kernels that add the
> > > > jbt6k74 notifier and glamo fb_blank() patches.
> > Already done, thanks to a patch from Harald and some refactoring.
> > While doing this, I encountered a strange thing. One of my FreeRunners does 
> > not recover from a BLANK ioctl anymore. The backlight turns on but the 
> > display does not show any pixels. I have to reboot to make it work again. 
> > Could that be connected to that infamous WSOD resume bug?
> I think so. I get a WSoD on every resume, when suspended for more than a
> minute. And since the frameworkd uses the new fb for blanking the screen
> I get it on un-blanking as well.
> If I comment out the changes in fb_notifier_callback (jbt6k74.c) the
> WSoD goes away...

This seems like the jbt6k74 switch from deep-standby to sleep to normal is not
working like it should.  Can you try using the sysfs nodes (echo "normal" or
"deep-standby" or "sleep" > state) and see what happens?

The timing values we got from the LCM vendor were _really_ crappy and we used
to have this problem ages ago with GTA01.  When I complained that the modules
were out of spec, the LCM vendor just sent an updated data sheet with more
sloppy (slower) timings.  I altered the code and it worked on all the devices
that I had access to.

Maybe the SPI timings are now even lower.  You might want to try that.

- Harald Welte <laforge at>         
Software for the world's first truly open Free Software mobile phone

More information about the openmoko-kernel mailing list