Measurements: Massive Display-related power savings
laforge at openmoko.org
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 openmoko.org> [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 openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel