Openmoko Bug #2349: Too high power consumption in 2.6.32
Openmoko Public Trac
bugs at docs.openmoko.org
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
GPIO.
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
suspend/resume.
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:
http://www.bsdmn.com/openmoko/pr2349donot_manage_down1.diff
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: <https://docs.openmoko.org/trac/ticket/2349#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list