Openmoko Bug #2349: Too high power consumption in 2.6.32

Openmoko Public Trac bugs at
Wed Sep 15 14:31:09 CEST 2010

#2349: Too high power consumption in 2.6.32
 Reporter:  Q-Master  |          Owner:  openmoko-kernel
     Type:  defect    |         Status:  new            
 Priority:  high      |      Milestone:                 
Component:  kernel    |        Version:                 
 Severity:  major     |       Keywords:                 
 Haspatch:  0         |      Blockedby:                 
Estimated:            |    Patchreview:                 
 Blocking:            |   Reproducible:  always         

Comment(by gena2x):

 All regulators has '*ENA' registers. Each register disable or enable one
 output of our s3c2442. *ENA may be turned on/off or tied to one or more
 PCF's GPIOs, so it will be switched even manually or automatically with
 Regulator in question is cpu core 1.3v (DOWN1)
 CPU has special signal to turn it on/off (PWREN). So it powers DOWN1
 automagically. OFF while suspend and ON on resume (as it is connected to
 GPIO on pmu)
 so, ENA register should just set GPIO and nobody should touch it.

 u-boot does exactly this. (and qi according sources too)

 But kernel has definitions for each register and kernel regulator
 infrastructure tries to manage it.
 So it turns this on manually on boot, but do not turn off in suspend.
 It has special field in platform structure to turn it off in suspend.
 And this seem worked in .29 so, now kernel _should_ turn it on/off while

 So, two problems:
 1. why in hell it touches it at all
 2. why if it ordered to turn it off while suspend to ram it is actually
 not doing this.

 So, problem (1):

 As regulator infrastucture is for manual managing
 (contolling only 1 bit) i think it should just be set to off.
 i mean set to never turn on this bit this will fix (1)

 Proposed patch for (1) here:

 It works fine here.

 Would be good to understand what happened with (2)
 Setting this bit to 1, enables DOWN1 output so it stay enabled while
 suspend independently of PWREN
 and eats that additional milliwats
 by 'manually' i mean contolling it not via GPIO but intead via automatic
 linux regulator infraastructure
 Being even more simple, if you disable that bit and not let regulators
 touch it, you'll get your 5mA.

 my personal kernel suspend still suffers from other problems
 i mean GPS and GSM power_on/power_off things
 i still have to do this

 but i also should note that after powering on/off i have no need to issue
 any commands to modem

Ticket URL: <> <>
openmoko trac

More information about the buglog mailing list