[Gta04-owner] Further 3.17 kernel development for GTA04

[NeilBrown]

On Tue, 11 Nov 2014 21:45:30 +0000 Neil Jerram <neil at ossau.homelinux.net>
wrote:

> NeilBrown <neilb at suse.de> writes:
> 
> > One thing you could try is to log the output of
> >
> >   date ; cat /sys/kernel/debug/wakeup_sources
> >
> > immediately before and after writing "mem" to "/sys/power/state".
> > That will tell you how long it was in suspend for, and any change in
> > 'wakeup_sources' might tell you why it woke up ... or might not.
> 
> Here's what I see:
> 
> /root/autolock/autolock.sh started Tue Nov 11 21:31:26 GMT 2014
> + xautolock -disable
> + ls -A /root/autolock/stayalive.d
> + [  ]
> + : Suspending is allowed
> + read AC_ONLINE
> + read USB_ONLINE
> + [ x0 != x1 -a x0 != x1 ]
> + date
> Tue Nov 11 21:31:26 GMT 2014
> + cat /sys/kernel/debug/wakeup_sources
> name		active_count	event_count	wakeup_count	expire_count	active_since	total_time	max_time	last_change	prevent_suspend_time
> gpio-keys-incoming	0		0		0		0		0		0		0		1353		0
> gpio-keys   	0		0		0		0		0		0		0		1301		0
> bq27000-battery	995		995		0		0		0		60369		116		76861067		0
> twl4030_usb 	19		19		0		0		0		141		11		76832346		0
> twl4030_ac  	19		19		0		0		0		76		5		76832339		0
> 48070000.i2c:twl at 48:rtc	0		0		0		0		0		0		0		499		0
> 48070000.i2c:twl at 48:pwrbutton	0		0		0		0		0		0		0		496		0
> musb-hdrc.0.auto	0		0		0		0		0		0		0		466		0
> 49042000.serial	0		0		0		0		0		0		0		365		0
> 49020000.serial	0		0		0		0		0		0		0		364		0
> 4806c000.serial	0		0		0		0		0		0		0		362		0
> 4806a000.serial	0		0		0		0		0		0		0		360		0
> alarmtimer  	0		0		0		0		0		0		0		341		0
> autosleep   	0		0		0		0		0		0		0		160		0
> + echo mem
> sh: echo: I/O error
> + date
> Tue Nov 11 21:34:12 GMT 2014
> + cat /sys/kernel/debug/wakeup_sources
> name		active_count	event_count	wakeup_count	expire_count	active_since	total_time	max_time	last_change	prevent_suspend_time
> gpio-keys-incoming	0		0		0		0		0		0		0		1353		0
> gpio-keys   	0		0		0		0		0		0		0		1301		0
> bq27000-battery	995		995		0		0		0		60369		116		76861067		0
> twl4030_usb 	21		21		0		0		0		306		83		76884318		0
> twl4030_ac  	21		21		0		0		0		183		63		76884297		0
> 48070000.i2c:twl at 48:rtc	0		0		0		0		0		0		0		499		0
> 48070000.i2c:twl at 48:pwrbutton	0		0		0		0		0		0		0		496		0
> musb-hdrc.0.auto	0		0		0		0		0		0		0		466		0
> 49042000.serial	0		0		0		0		0		0		0		365		0
> 49020000.serial	0		0		0		0		0		0		0		364		0
> 4806c000.serial	0		0		0		0		0		0		0		362		0
> 4806a000.serial	0		0		0		0		0		0		0		360		0
> alarmtimer  	0		0		0		0		0		0		0		341		0
> autosleep   	0		0		0		0		0		0		0		160		0
> + xautolock -unlocknow
> + xautolock -enable
> 
> To my untutored eye, 'twl4030_usb' and 'twl4030_ac' indicate something
> to do with charging - but both USB and AC were definitely disconnected
> at the time when this happened.
> 
> Regards,
>         Neil

Hi Neil,
 the date stamps show 2:46 between suspend and resume, so it looks like it
 really did suspend.  How long did you wait until you tapped the screen?

 It might be useful to get the script to turn an LED on/off at suspend,resume
 so you get visible clues of exactly when it is suspended.

 Can you try a few times and see if  2:46 is a common value, or if it varies
 a lot?

 The twl4030_* changes certainly deserve examination.  Those interfaces
 should be completely off at this point.
 I think the  event_count changes on each call to power_supply_changed()
 in drivers/power/twl4030_charger.c.

 You could try
    echo file twl4030_charger.c +p > /sys/kernel/debug/dynamic_debug/control

 which will turn on all the dev_dbg() calls in that file.
 Then you can see if "CHG_PRES irq" or "BCI irq" is called (or neither).
 That will be in 'dmesg' output of course.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20141112/5a822a95/attachment.asc>