[PATCH] [JBT6K74] add framebuffer blanking notifier

[Harald Welte]

On Wed, Oct 08, 2008 at 12:57:28PM +0100, Andy Green wrote:
> | What does that mean for userland? AFAICT echo "1"
> |> /sys/class/backlight/whatever/bl_power should give the maximum power
> | savings -- no?

no. this is just the backlight. doesn't switch off the actual generation
of the LCM data signal (high frequency signals consume a lot of power),
and we have the constant reads from glamo-internal SDRAM for screen refresh,
too).  Also, doesn't switch of the LCM ASIC (JBT6K74).

> No, backlight is looking after backlight only, which is strictly a PMU
> regulator action; whereas framebuffer blanking is an opportunity to
> coordinate multiple areas.

exactly.

> Harald's larger concept is that under the umbrella of the framebuffer
> blanking, we not only use the existing connection to control of
> backlight there to take that down, but we take the opportunity to turn
> off other video related circuitry (ie, Glamo) which is otherwise still
> blaring away into the dark LCM.

yes. exactly.  The only way how to reliably blank the screen involving all the
related hardware is by using the ioctl() interface for framebuffer blanking.

This is what the xglamo already does, so on a standard linux+xglamo/kdrive/xorg
system, the flow will be:

1) xserver decides it wants to blank
2) xserver issues blanking ioctl (first state 2, then 3, then 4)
3) fb_blank of glamo driver is executed
   * i'll be working on a patch that disables the LCD controller
     clocks (particularly the pixel clock) to save power (we have a potential
     of about 20mW here)
4) jbt7k74 is put into deep power down via notifier chain
5) backlight is blanked via notifier chain

this is the standard interface, and we should use it that way, I guess.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone