[Gta04-owner] The status of suspend.

[NeilBrown]

Hi,
  I've been trying to make progress with suspend over the last week and made
  disconcerting little headway.  So I thought I would summarise were I am up
  to and then leave it for a while.

  I would particularly be interested if anyone can reproduce my results.
  That will confirm that the power drain isn't due to a problem (a short?) on
  my board.

  Also if anyone has access to infrared imaging I would love to see images of
  the board in different power states - particularly when suspended.  That
  might give a hint as to where the power is going, but would be fun to look
  at anyway.


  I've been measuring current drain by taking a time stamp (date +%s) and
  charge-stamp (cat /sys/class/power_supply/bq27000-battery/charge_now)
  before and after a reasonable period of time in some state (about 30
  minutes) and then calculating average current using

    (start_charge - end_charge)/((end_time - start_time)/3600)

  To measure current while the device is running I just add
     cat /sys/class/power_supply/twl4030_usb/current_now 
   and
     cat /sys/class/power_supply/bq27000-battery/current_now 

  The above result in numbers of uA.  However I am reporting in mA because
  that is a much more realistic precision.

  Some measurements:
    Powered off:                            8mA
    On:                                   330mA
    suspend (wifi/BT/GPS not forced off)   95mA
    suspend (wifi/BT/GPS off)              87mA


  The '87' is way too high - it should be about 10mA I think.

  Immediately after resume I get messages:

[ 1853.089477] Powerdomain (core_pwrdm) didn't enter target state 1
[ 1853.104553] Powerdomain (usbhost_pwrdm) didn't enter target state 1

  So it seems like some usb thing isn't being turned off properly.  I think
  'core' is always on if anything else is on.

  I read here:
    http://processors.wiki.ti.com/index.php/OMAP35x_and_AM/DM37x_Low_Power_Standby_Support
  that excluding USB was needed once to demonstrate low power so I recompiled
  the kernel with no USB support and tried again.
  The bad messages went away and I got

        Successfully put all powerdomains to target state

  But current drain was  115mA !!!!!
  Presumably something else wasn't being turned off - maybe something in the
  TWL4030 which also plays a role in USB.


  Previously I had problems with more power domains:

[ 1853.058227] Powerdomain (cam_pwrdm) didn't enter target state 1
[ 1853.068603] Powerdomain (dss_pwrdm) didn't enter target state 1
[ 1853.078979] Powerdomain (per_pwrdm) didn't enter target state 1
[ 1853.089477] Powerdomain (core_pwrdm) didn't enter target state 1
[ 1853.104553] Powerdomain (usbhost_pwrdm) didn't enter target state 1

  I fixed some of this by adding the CONFIG option
   CONFIG_OMAP_RESET_CLOCKS=y

  So maybe some usb-related clock is still running so that module
  won't turn off.  Or something.

  Before setting OMAP_RESET_CLOCKS the power drain in suspend was 
  97mA, so that config option saved about 10mA.  I can't guess how much
  we will save if USB can get sorted out, but I'd be surprised if it is the
  fill 77mA that I am looking for.

  I tested with and without the twl4030_scripts in the board file and they
  make no difference at all.  I'm guessing that until core_pwrdm is turned
  off, the signal isn't sent to the twl4030 to power things down.

  So to all the early adopters with a board to play with:  If you have time
  I would really appreciate if it you could reproduce these results and
  confirm that the power drain is a general problem.

  I've been trying to think if ways to narrow down where the power drain
  might be and the only thing I can think of is to get an Infra-red image of
  the device in the three states:  on, suspend, off - and then look to see
  what the differences are.  Any suggestions how?


Another suspend related problem is that the RTC alarm doesn't wake from
suspend reliably.  The power button, AUX button, USB plug/unplug and
serial-line activity all do, but not the alarm.

I test this with (Assuming RTC is in UTC)

  hwclock -w  # make sure RTC is in sync with system.
  date +%s --date="+30seconds" > /sys/class/rtc/rtc0/wakealarm 
  echo mem > /sys/power/state

  # wait 30 seconds

It should wake up after 30 seconds and sometimes it does but mostly it
doesn't.  I've watched the commands writing to the RTC controller and it
all looks good but it just doesn't work.  And the same chip (the TWL4030)
with the one interrupt line is responsible for waking up from power-button
and USB connections.  So I'm stumped.

After trying the above the RTC alarm seems to be very sick.  Running
   hwclock
(which sets an alarm for the next second to synch with) will hang even
if you reset the RTC alarm with
   echo 0 > /sys/class/rtc/rtc0/wakealarm

So something weird there.  The RTC alarm definitely works as "hwclock" uses
it and that normally works.  But somehow going into suspend confuses it.

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20111230/e47e10e1/attachment.bin>