Measurements: Massive Display-related power savings

Klaus Kurzmann mok at mnet-online.de
Fri Oct 17 17:51:33 CEST 2008


* Harald Welte <laforge at openmoko.org> [081017 15:42]:
> On Fri, Oct 17, 2008 at 02:47:37PM +0200, Klaus Kurzmann wrote:
> > > it means reduce the max_speed_hz from 10MHz to say 1MHz see if it
> > > impacts it I guess.
> > ok, changed .max_speed_hz to 1 * 1000 * 100, but this doesn't change the
> > behaviour. I still get WSoD after some time in deep-standby state.

> that's sad.

> > Something else to try out ? :-)

> you could verify if the power consumption actually increases after you set it
> from deep-standby to sleep and then to normal.  each of the different states
> should have it's unique power consumption  (you can use the current reading of
> the coulomb counter in the battery, if you make sure that the device doesn't
> power or charge through USB)
I wrote the following script to test it:


-----------------------------------------------------
#!/bin/sh

SYS_JBT6K74=/sys/bus/spi/drivers/jbt6k74/spi2.0/state
SYS_BAT=/sys/class/power_supply/bat/current_now
LOGFILE=/home/root/test.log


log_power()
{
	echo "--- state is $(cat $SYS_JBT6K74)" >> $LOGFILE
	for n in $(seq 0 10); do
		echo "$n: $(cat $SYS_BAT)" >> $LOGFILE
		sleep 5
	done
	echo >> $LOGFILE
}

echo "starting test at $(date)" > $LOGFILE

# get power consumption in normal state
log_power

# switching to sleep
echo -n "sleep" > $SYS_JBT6K74
log_power

# switching to deep-standby
echo -n "deep-standby" > $SYS_JBT6K74
log_power


# switching back to normal
echo -n "normal" > $SYS_JBT6K74
log_power


# switching to deep-standby
echo -n "deep-standby" > $SYS_JBT6K74
log_power

echo >> $LOGFILE
echo "sleeping for 2 minutes" >> $LOGFILE
sleep 120
echo >> $LOGFILE

# switching back to sleep
echo -n "sleep" > $SYS_JBT6K74
log_power


# switching back to normal
echo -n "normal" > $SYS_JBT6K74
log_power

-----------------------------------------------------

and it gives me the following output:

-----------------------------------------------------

starting test at Fri Oct 17 16:37:17 UTC 2008
--- state is normal
0: 184500
1: 183937
2: 180937
3: 181125
4: 181875
5: 182625
6: 172312
7: 119250
8: 120375
9: 96000
10: 95250

--- state is sleep
0: 79125
1: 82875
2: 79125
3: 75562
4: 70687
5: 71812
6: 91687
7: 99375
8: 94875
9: 83062
10: 73875

--- state is deep-standby
0: 86250
1: 77437
2: 72187
3: 70687
4: 75562
5: 90562
6: 96937
7: 94687
8: 81375
9: 72375
10: 79875

--- state is normal
0: 78562
1: 74437
2: 67500
3: 90000
4: 90000
5: 102375
6: 79125
7: 73500
8: 69937
9: 70687
10: 69562

--- state is deep-standby
0: 74625
1: 64875
2: 83250
3: 91125
4: 103312
5: 78562
6: 74812
7: 69375
8: 70875
9: 64500
10: 82500


sleeping for 2 minutes

--- state is sleep
0: 90000
1: 101437
2: 94500
3: 75000
4: 69187
5: 75000
6: 90750
7: 98250
8: 90750
9: 75750
10: 71062

--- state is normal
0: 70875
1: 73500
2: 72000
3: 70875
4: 72937
5: 91125
6: 98250
7: 101062
8: 75375
9: 70125
10: 70312

-----------------------------------------------------

I started the script from the terminal on the freerunner - without
beeing attached to USB.

> Also, is there any difference if you manually transition from deep-standby to
> sleep, and then to normal (not going directly from deep-standby to normal and
> rely on the driver to do the intermediate sleep state) ?
makes no difference.

> Does anybody else observe this behaviour? If I had a device which I can use to
> reproduce the bug, I'd put in the time to get it fixed...


Mok






More information about the openmoko-kernel mailing list