Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
2. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
3. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
4. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
5. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
6. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
7. Re: Openmoko Bug #2349: Too high power consumption in 2.6.32
(Openmoko Public Trac)
--- Begin Message ---
#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
--- End Message ---
--- Begin Message ---
#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 Treviño):
The workaround patch for the 2.6.32 kernel doesn't seem to be valid, since
after applying it the kernel has some suspend issues:
- trying to suspend it while in AC doesn't work
- trying to suspend it after that it has been in AC doesn't work
- after some time it doesn't weak-up from suspend, but it gives me a WSOD
I guess that should be found a better solution, at least for the 2.6.32
kernels...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:15>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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 lars):
Could you specify "does not work" more detailed?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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 Treviño):
Unfortunately I didn't read the logs, since I was not near to a PC, but
simply when requesting to suspend (via apm or GUI) anything happens and
the request get ignored (or freezed, like happens with apm).
So the suspension request neither seems to be accepted by the kernel since
I didn't read anything on the latest dmesg...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:17>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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 psonek):
Please make sure that your problems are relevant to this bug and are
caused by the attached patch. Try compiling without the patch and report
if your problems disappeared.
I am running 2.6.34 with attached patch and i dont have your problems.
Please also tell us which sources are you using, how you compile and which
config are you using. At leasr for your third problem there is already
fix:
http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-
kernel/commit/51201ea5d46e63edec21e3ec976f4ecbd669b651
do you have it in your sources?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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):
Please, do as Radek suggests, your kernel issues unlikely to be related to
this patch. And also - this is _not_ workaround. Why do you think it is?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:19>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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 Treviño):
Replying to [comment:18 psonek]:
> Please make sure that your problems are relevant to this bug and are
caused by the attached patch. Try compiling without the patch and report
if your problems disappeared.
Of course they are... I'm using the SHR 2.6.32 kernel as base, plus I've
added the attached patch [1] (which is basically the one posted by gena2x
ported to the older kernel). Without that I've no issues; using it
> I am running 2.6.34 with attached patch and i dont have your problems.
Please also tell us which sources are you using, how you compile and which
config are you using. At leasr for your third problem there is already
fix:
>
> http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-
kernel/commit/51201ea5d46e63edec21e3ec976f4ecbd669b651
>
> do you have it in your sources?
Yes, of course since that patch is included in the SHR OE configuration...
Replying to [comment:19 gena2x]:
> Please, do as Radek suggests, your kernel issues unlikely to be related
to this patch. And also - this is _not_ workaround. Why do you think it
is?
As I've said, my kernel without this patch works... However, I thought it
was a workaround since you said that the phone should have had turned off
all his peripherals also before of this setting change...
[1] https://docs.openmoko.org/trac/attachment/ticket/2349/pr2349donot-
manage-down1-2.6.32.patch
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2349#comment:20>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
