Ticket #2349 (new defect)

Opened 4 years ago

Last modified 4 years ago

Too high power consumption in 2.6.32

Reported by: Q-Master Owned by: openmoko-kernel
Priority: high Milestone:
Component: kernel Version:
Severity: major Keywords:
Cc: psonek2@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: yes PatchReviewResult:
Reproducible: always

Description

I've checked the power consumtion as PaulFertser? told me using that script:
while true; do cat /sys/class/power_supply/battery/current_now >>/var/log/power.log; sleep 1; done
and suspended/resumed several times, then checked logs.
The results were horrible:
52125
45375
41437
Seems that there's something completely wrong with power consumption
while suspended.
The Neo lives on battery while suspended only for 1 day in best not resumed.
I'm using shr-unstable
root@om-gta02 /var/volatile/log # uname -a
Linux om-gta02 2.6.32.13 #1 PREEMPT Thu Jul 1 06:45:39 CEST 2010 armv4tl

Attachments

dmesg.txt (131.6 KB) - added by Q-Master 4 years ago.
pr2349donot-manage-down1-2.6.32.patch (369 bytes) - added by Treviño 4 years ago.
gena2x's Workaround for 2.6.32

Change History

Changed 4 years ago by Q-Master

comment:1 Changed 4 years ago by lindi

I have om-gta02-2.6.32 a9254be10ac2294ea20165a87c09ea6a and tried to measure this with

# while true; do rtcwake -s 60 -m no ; echo mem >/sys/power/state ; om battery consumption; sleep 10; done
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:52:54 2010

144187
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:54:10 2010

160125
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:55:26 2010

17062
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:56:42 2010

21187
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:57:58 2010

80250
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 16:59:14 2010

96562
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:00:30 2010

112500
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:01:46 2010

136500
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:03:02 2010

152812
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:04:18 2010

17812
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:05:34 2010

17625
rtcwake: wakeup from "no" using /dev/rtc0 at Sat Jul 31 17:06:09 2010

but after a while I was unable to resume even with power button.

What is the recommended way to control wifi power? rfkill support is not enabled in om-gta02-2.6.32 a9254be10ac2294ea20165a87c09ea6a defconfig_gta02

comment:2 Changed 4 years ago by gena2x

I did measurements with multimeter, and found following.

First, i measured qtmoko on nand:

fully loaded qtmoko = 220mA
qtmoko sleeps without deepsleep enabled = 32mA
qtmoko sleeps with deepsleep enabled = 9-18mA

on om-gta02-34, the power consumption with loaded X is 250mA
on om-gta02-34, in suspend, it is 100mA

some additional info: both u-boots draw 350mA while in menu -> strange.

additionally i found that i can't do GSM calls in multimeter configuration in qtmoko.
additionally i found that if i disconnect usb power supply, i can't register to gsm network in multimeter configuration (and can with adding usb power supply), both reliable.

comment:3 Changed 4 years ago by gena2x

It turned out that gsm and gps devices are powered up, but not considered powered up somehow.

To shut em down, i have to do:

cd /sys/bus/platform/devices

echo 1 > gta02-pm-gsm.0/power_on
echo 0 > gta02-pm-gsm.0/power_on

echo 1 > gta02-pm-gps.0/power_on
echo 0 > gta02-pm-gps.0/power_on

after this manipulation, i have 20mA suspend current.

comment:4 Changed 4 years ago by lindi

Ok but 20 mA is still way too much. I get 3 mA under 2.6.29 when all extra devices are off.

comment:5 Changed 4 years ago by lindi

radekp on IRC made the following analysis:

2.6.29
======

138.9

		[  822.405000] soc-audio soc-audio: preparing suspend -> 133.9
-5mA

		[  891.945000] neo1973-pm-gsm neo1973-pm-gsm.0: suspend -> 131.8
		[  895.740000] s3c2440-ts s3c2440-ts: suspend
-2mA

		[  912.935000] generic-bl generic-bl.1: suspend -> 106.6
-25mA

		[  945.305000] platform glamo-2d.0: suspend -> 86.8
-20mA

		[ 1074.795000] s3c2440-usbgadget s3c2440-usbgadget: suspend -> 80.9
		[ 1074.795000] gta02_udc_command S3C2410_UDC_P_DISABLE
-6mA

		[ 1091.810000] platform s3c2410-wdt: LATE suspend
		[ 1091.810000] pm_counter 186
		[ 1091.810000] s3c-ohci s3c-ohci: LATE suspend -> 9.4
-71mA

2.6.34
======

124.9

		[ 1293.525000] soc-audio soc-audio: preparing suspend -> 119.6
-5mA

		[ 1541.720000] s3c24xx-ts s3c2440-ts: suspend -> 116.6
-3mA

		[ 1550.310000] spi_s3c24xx_gpio spi_s3c24xx_gpio.0: suspend -> 100.6
		[ 1553.105000] glamo3362 glamo3362.0: suspend
-16mA

		[ 1886.550000] s3c2410-wdt s3c2410-wdt: LATE suspend -> 30.2
		[ 1889.345000] s3c2410-ohci s3c2410-ohci: LATE suspend
		[ 1889.345000] PM: late suspend of devices complete after 267905.559 msecs
-70mA



In 2.6.29 missing in 2.6.32
===========================

		[  912.935000] generic-bl generic-bl.1: suspend -> 106.6
-25mA

		[ 1074.795000] s3c2440-usbgadget s3c2440-usbgadget: suspend -> 80.9
		[ 1074.795000] gta02_udc_command S3C2410_UDC_P_DISABLE
-6mA

comment:6 Changed 4 years ago by lindi

  • Cc psonek2@… added

comment:7 Changed 4 years ago by lars

In 2.6.32/2.6.34 the generic-bl driver was replaced with the pcf50633-bl driver. Which does basically the same but integrates nicer into the core pcf50633 driver.

I guess it would be interesting to see the regulator states of the pcf50633 at the end of suspend. This needs some kernel hacking though maybe adding a late suspend callback to the regulator driver.

comment:8 Changed 4 years ago by lindi

As radekp is not able to create an account to trac I'm forwarding pcf register dumps:

2.6.29

[21474690.400000] pcf50633_suspend: 13 84 80 00 00 00 00 80 00 00 00 00 00 d3 aa 4a 
[21474690.400000] 15 47 ff 01 00 00 00 00 02 08 6b 01 00 0a 1b 02 
[21474690.400000] 00 1a 2f 21 00 1a 09 21 02 00 05 05 11 18 02 18 
[21474690.400000] 02 15 30 17 00 15 00 15 02 17 01 00 00 ff 3f 00 
[21474690.400000] 00 07 63 e7 28 19 ff 00 00 03 00 30 00 80 19 00 
[21474690.400000] 00 08 00 00 7e 0a 00 f2 00 43 22 00 06 01 01 00 
[21474690.400000] 7f 7f 3f 07 3f 1f ff 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 86 a3 d9 0c 17 a2 1a 80 ba 
[21474690.400000] 02 b0 03 07 00 01 00 01 f4 fe 39 63 ff 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[21474690.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

2.6.34

[  195.615000] pcf50633_suspend: 13 84 80 00 00 00 00 80 00 00 00 00 00 d3 aa 4a
[  195.615000] 15 47 ff 01 00 00 00 00 02 08 6b 01 00 0a 1b 03
[  195.615000] 00 1a 2f 21 00 1a 09 21 3f 00 05 03 11 18 02 18
[  195.615000] 02 15 30 17 00 15 00 15 02 18 00 00 00 ff 3f 00
[  195.615000] 00 07 23 e7 28 19 ff 00 00 03 00 30 00 80 19 00
[  195.615000] 00 08 00 00 7e 0a 00 f2 00 20 29 00 06 01 01 00
[  195.615000] 7f 7f 3f 07 3f 1f ff 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 86 a3 d9 0c 17 a2 1a 80 ba
[  195.615000] 02 b0 03 07 00 01 00 01 f4 fe 39 63 ff 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  195.615000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


comment:9 Changed 4 years ago by lars

Hm, the only difference i could find is that on 2.6.29 the mmc is powered while on 2.6.34 it is not.

comment:10 Changed 4 years ago by lindi

  • Reproducible always deleted
  • Priority changed from normal to highest
  • Severity changed from major to blocker

I powered my gta02V5 with only usb and added a 0.5 ohm resistor to the usb Vcc. I then got a friend measure the voltage over that resistor with picoscope. The following screenshot shows how the phone goes to suspend and wakes from it (everything is off except the backlight which is at maximum):

http://lindi.iki.fi/lindi/openmoko/consumption/fr-2.6.29-suspend1.png

comment:11 Changed 4 years ago by lindi

  • Reproducible set to always
  • Priority changed from highest to high
  • Severity changed from blocker to major

Hrm, sorry for changing flags.

comment:12 Changed 4 years ago by lindi

Here are some current measurements done with usb and 0.1 ohm resistor (I said 0.5 ohm previously but that was false info):

kernel is 2.6.29

suspend 0.9 mV 45 mW
idle 3.7 mV 185 mW
backlight255_black 20.3 mV 1015 mW
backlight255_white 19.1mV 955 mW
backlight127_black 8.8 mV 440 mW
backlight127_white 7.6 mV 380 mW
backlight12_black 7.2 mV 360 mW
backlight12_white 5.9 mV 295 mW
while true;do :;done 7.2mV 360 mW
speaker-test -t sine, max volume 23.5 mV 1175 mW
redled255 4.1 mV 205 mW
blueled255 3.7 mV 185 mW
orange255 4.0 mV 200 mW
cat /dev/acclerometer-top 4.0 mV 200 mW
cat /dev/acclerometer-bottom 4.0 mV 200 mW

comment:13 Changed 4 years ago by gena2x

It's in PMU register 0x1F, setting it to 2 fixes suspend current.

I'm trying to write patch now.

comment:14 Changed 4 years ago 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

Changed 4 years ago by Treviño

gena2x's Workaround for 2.6.32

comment:15 Changed 4 years ago 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...

comment:16 Changed 4 years ago by lars

Could you specify "does not work" more detailed?

comment:17 Changed 4 years ago 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...

comment:18 follow-up: ↓ 20 Changed 4 years ago 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?

comment:19 Changed 4 years ago 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?

comment:20 in reply to: ↑ 18 Changed 4 years ago by Treviño

Replying to 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 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

comment:21 Changed 4 years ago by gena2x

... since you said that the phone should have had turned off all his peripherals also
before of this setting change.

heh, you didn't got why i did that.

After boot, it is expected that GSM and GPS is off, until you turn them on. But instead, i have to do that operation to really turn then off. Or i am getting more mA in suspend.

May be this related to my u-boot which is doing something with serial ports. And this is separate problem.

comment:22 Changed 4 years ago by RuiSeabra

I tried uImage-2.6.32.22-oe3.3+gitr6+a9254be10ac2294ea20165a87c09ea6afcf66d94-r0-om-gta02.bin from http://build.shr-project.org/shr-kms/ and it's been working fine for me for a half a day already.

I'm not sure I can notice any real differences but at least wifi, texting and calling works.

comment:23 Changed 4 years ago by TimoJyrinki

  • HasPatchForReview set

comment:24 Changed 4 years ago by lindi

2.6.34 ec52149c715232584731e3630 from radekp's branch shows pretty consistently 2437 uA as the current_now right after resume. If this is really true it is a nice improvement, 2.6.29 shows 3000 uA => We consume 19% less :-)

Note: See TracTickets for help on using tickets.