2010-07-15 09:00:55     BF522 hibernate wake from i2c keypad controller

Document created by Aaronwu Employee on Aug 22, 2013
Version 1Show Document
  • View in full screen mode

2010-07-15 09:00:55     BF522 hibernate wake from i2c keypad controller

Michael Dean (UNITED STATES)

Message: 91297   

 

Hi,

 

I am currently trying to get hibernate working on the BF522.   I am running the SVN trunk (2.6.34.2010R1-pre-sv).    Our hardware uses the adp5588 keyboard controller and we need to wake the processor from hibernate.     The KEY_INT# line is being run to a GPIO  input and the 5588 driver is configured to use it.    The signal is also run into an AND gate along with a WIFI_INT# signal.  The output of the AND gate is run into PG15 on the BF522 for the hibernate wakeup.    I have been able to hibernate the system, and it will wake up on a key press, but only once.   The second time I try to enter hibernate there is no current change and the log says it took 5 times as long.    I have noticed that the KEY_INT# does not seem to be getting serviced and stays low from the first hibernate.    I have also used rtcwake and can only hibernate correctly once that way also (

 

Is this the correct  way for the hardware to be setup to wake using a i2c keyboard controller?  The adp5588 is setup to be edge triggered so it seems like having the same irq line be the INT and the WAKE could be a problem.

 

Also, is hibernate working in 2010R1?    Has anyone else been able to hibernate/wake repeatedly?    Even when I enter hibernate the system is still pulling 18ma.    CLKBUF is being driven and I would like to shut it off but have not been able to figure out the correct way or place to do this.

 

Any ideas?

 

Thanks

QuoteReplyEditDelete

 

 

2010-07-15 09:37:39     Re: BF522 hibernate wake from i2c keypad controller

Mike Frysinger (UNITED STATES)

Message: 91301   

 

what exactly are you running on the board to make it hibernate ?  please show some output from your terminal.

QuoteReplyEditDelete

 

 

2010-07-15 10:12:19     BF522 hibernate wake from i2c keypad controller

Michael Hennerich (GERMANY)

Message: 91310    This might be addresses by using an level sensitive IRQ for the ADP5588.

So on resume the IRQ will be serviced and thus the WAKE signal will go inactive.

 

Hibernate should work on 2010R1.

If you like to turn CLKBUF OFF - place some code in arch/Blackfin/mach-common/pm.c

QuoteReplyEditDelete

 

 

2010-07-15 12:59:55     Re: BF522 hibernate wake from i2c keypad controller

Michael Dean (UNITED STATES)

Message: 91315   

 

my board is currently down so i can't get a log.   I am using "rtcwake -s 30 -m mem" and "echo mem > /sys/power/state" to enter hibernate.    The processor is driving EXT_WAKE# to out PMU to shutdown VDDINT.

 

Even using rtcwake, i can only enter hibernate and wake back up once.   The second time, you never see EXT_WAKE# go low even though the log looks the same (but it does say it took longer to enter hibernate, about 5x longer).

 

The wakeup using the adp5588 seems to be slightly different and i will try changing the irq to level vs edge when my board is back up.

 

I had tried adding the following to pm.c but did not see the clkbuf shutoff.

 

ADI_SYSCTRL_VALUES hibernate;

hibernate.uwVrCtl = bfin_read_VR_CTL();

 

hibernate.uwVrCtl &= CLKBUFOE;

 

bfrom_SysControl( SYSCTRL_WRITE | SYSCTRL_VRCTL, &hibernate, NULL);

 

do_hibernate(wakeup | vr_wakeup);

 

Thanks,

 

Michael

QuoteReplyEditDelete

 

 

2010-07-15 13:02:12     Re: BF522 hibernate wake from i2c keypad controller

Michael Dean (UNITED STATES)

Message: 91316   

 

Sorry, that was dumb, i see the possible clkbuf issue...

 

hibernate.uwVrCtl &= ~CLKBUFOE;

QuoteReplyEditDelete

 

 

2010-07-16 09:50:29     Re: BF522 hibernate wake from i2c keypad controller

Michael Dean (UNITED STATES)

Message: 91348   

 

Here is some output of back to back hibernates.   The first hibernate seems to work.  The second does not (at least the same current drop does not occur) and takes 5x longer.    The KEY_INT# is not being used in this test.

 

root:/> rtcwake -s 10 -m mem

wakeup from "mem" at Mon Feb 16 04:46:57 1970

[   24.156000] PM: Syncing filesystems ... done.

[   24.200000] Freezing user space processes ... (elapsed 0.02 seconds) done.

[   24.224000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[   24.244000] Suspending console(s) (use no_console_suspend to debug)

[   25.384000] PM: suspend of devices complete after 1128.000 msecs

[   25.384000] PM: late suspend of devices complete after 0.001 msecs

[   25.384000] PM: early resume of devices complete after 0.001 msecs

[   25.584000] PM: resume of devices complete after 200.000 msecs

[   25.604000] Restarting tasks ... done.

[   25.624000] wm8990: SND_SOC_BIAS_STANDBY

 

 

root:/> rtcwake -s 10 -m mem

wakeup from "mem" at Mon Feb 16 04:47:44 1970

[   67.080000] PM: Syncing filesystems ... done.

[   67.084000] Freezing user space processes ... (elapsed 0.01 seconds) done.

[   67.104000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[   67.124000] Suspending console(s) (use no_console_suspend to debug)

[   72.328000] PM: suspend of devices complete after 5200.000 msecs

[   72.328000] PM: late suspend of devices complete after 0.001 msecs

[   72.328000] PM: early resume of devices complete after 0.001 msecs

[   72.528000] PM: resume of devices complete after 200.000 msecs

[   72.548000] Restarting tasks ... done.

[   72.568000] wm8990: SND_SOC_BIAS_STANDBY

root:/>

 

 

I have turned off CLKBUF by adding this in pm.c:

 

wakeup &= ~CLKBUFOE;

 

But I don't know how to turn it back on when we resume.  Using bfrom_SysControl does not seem to work even though it returns 0x00000000.   Am I doing/trying something wrong here?

 

Thanks

 

 

 

QuoteReplyEditDelete

 

 

2010-07-16 11:42:54     Re: BF522 hibernate wake from i2c keypad controller

Mike Frysinger (UNITED STATES)

Message: 91355   

 

dont use the syscontrol functions

QuoteReplyEditDelete

 

 

2010-07-28 07:51:44     Re: BF522 hibernate wake from i2c keypadcontroller

Michael Hennerich (GERMANY)

Message: 91812    I verified that hibernate works on BF522/4/6.

See below tests PG15 and RTC successfully wakes up the core.

I measured VDDINT as well as IDDHIBERNATE.

Once the core is in hibernate VROUT/EXTWAKE asserts and successfully turns down VDDINT.

Therefore IDDHIBERNATE=0 too. (hibernate only influences core current).

What you turn off using the EXT_WAKE signal on your board is up to you.

 

Please use the BF526-EZBRD as an reference for your external voltage regulator circuit.

Suspend time of devices depend on the devices registered with the device core.

Basically the drivers loaded or compiled into your kernel image.

 

 

PG15 (PHYINT) wakeup test:

 

root:/> echo mem > sys/power/state

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 0.001 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs

Restarting tasks ... done.

 

root:/> echo mem > sys/power/state

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 4.000 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs

Restarting tasks ... done.

root:/> echo mem > sys/power/state

 

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 4.000 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs

Restarting tasks ... done.

 

root:/> echo mem > sys/power/state

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 4.000 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs

Restarting tasks ... done.

 

 

RTC wakeup:

 

root:/> rtcwake -s10 -mmem

wakeup from "mem" at Sat Jan 3 02:17:06 1970

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 5004.000 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs

Restarting tasks ... done.

 

root:/> rtcwake -s10 -mmem

wakeup from "mem" at Sat Jan 3 02:17:23 1970

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.01 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 5004.000 msecs

PM: late suspend of devices complete after 0.001 msecs

PM: early resume of devices complete after 0.001 msecs

PM: resume of devices complete after 16.000 msecs Restarting tasks ... done.

 

root:/> version

kernel: Linux release 2.6.34.1-ADI-2010R1-pre-svn8986, build #13820 Wed Jul 28 09:29:34 CEST 2010

toolchain: bfin-uclinux-gcc release gcc version 4.3.5 (ADI-trunk/svn-4717)

user-dist: release svn-9715, build #5133 Wed Jul 28 09:29:07 CEST 2010

 

root:/> cat /proc/cpuinfo

processor : 0

vendor_id : Analog Devices

cpu family : 0x27e4

model name : ADSP-BF526 400(MHz CCLK) 80(MHz SCLK) (mpu off)

stepping : 0

cpu MHz : 400.000/80.000

bogomips : 794.62

Calibration : 397312000 loops

cache size : 16 KB(L1 icache) 32 KB(L1 dcache) 0 KB(L2 cache)

dbank-A/B : cache/cache

external memory : cacheable in instruction cache external memory : cacheable (write-back) in data cache

icache setup : 4 Sub-banks/4 Ways, 32 Lines/Way

dcache setup : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way

board name : ADI BF526-EZBRD

board memory : 65536 kB (0x(null) -> 0x04000000)

kernel memory : 64508 kB (0x00001000 -> 0x03f00000)

 

root:/> reboot

Flash device refused suspend due to active operation (state 0) Restarting system.

 

U-Boot 2010.06-svn2356 (ADI-2010R1-pre) (Jul 28 2010 - 09:40:58)

 

CPU: ADSP bf526-0.0 (Detected Rev: 0.0) (parallel flash boot)

Board: ADI BF526 EZ-Board board

Support:   blackfin.uclinux.org/

Clock: VCO: 400 MHz, Core: 400 MHz, System: 80 MHz

RAM: 64 MiB

Flash: 4 MiB

In: serial

Out: serial

Err: serial

KGDB: [on serial] ready

Net: bfin_mac

Hit any key to stop autoboot: 0

bfin>

QuoteReplyEditDelete

 

 

2010-07-28 12:04:48     Re: BF522 hibernate wake from i2c keypadcontroller

Michael Dean (UNITED STATES)

Message: 91818   

 

Thanks Michael,

 

I have not used the direct entry into hibernate as much as the rtcwake.    What I am seeing is the the first time I use rtcwake to enter hibernate is different than any time after the first resume but my log looks very similar to yours.

 

The first time I see EXT_WAKE go low and it takes about 1200 ms.    After it resumes and I try it again, I DO NOT see EXT_WAKE go low and it takes about 5000 ms.     In the test you ran it also looks like it was taking 5 seconds to enter hibernate using the rtc.      "PM: suspend of devices complete after 5004.000 msecs"

 

Can you verify that EXT_WAKE is driven in the rtcwake cases where it takes 5000 ms to enter hibernate?

 

Why is it taking 5000 ms to enter hibernate using the rtc?

 

Thanks,

 

Michael

QuoteReplyEditDelete

 

 

2010-07-29 05:00:27     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Hennerich (GERMANY)

Message: 91869    > I have not used the direct entry into hibernate as much as the rtcwake.

> What I am seeing is the the first time I use rtcwake to enter hibernate

> is different than any time after the first resume butmy log looks very

> similar to yours.

 

> The first time I see EXT_WAKE go low and it takes about 1200 ms. After

> it resumes and I try it again, I DO NOT see EXT_WAKE go low and it

> takes about 5000 ms. In the test you ran it also looks like it was

> taking 5 seconds to enter hibernate using the rtc. "PM: suspend of

> devices complete after 5004.000 msecs"

 

Let's see what is going on -

Enable printk timing information as well as PM verbose debugging:

 

root:/> rtcwake -s20 -mmem

wakeup from "mem" at Sat Jan 3 03:46:19 1970

[ 15.124000] PM: Syncing filesystems ... done.

[ 15.136000] Freezing user space processes ... (elapsed 0.01 seconds) done.

[ 15.160000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[ 15.184000] Suspending console(s) (use no_console_suspend to debug)

[ 16.096000] PM: suspend of devices complete after 896.000 msecs

[ 16.096000] PM: late suspend of devices complete after 0.001 msecs

[ 16.096000] PM: early resume of devices complete after 0.001 msecs

[ 16.112000] PM: resume of devices complete after 16.000 msecs

[ 16.116000] Restarting tasks ... done.

 

root:/>

 

FROM dmesg:

 

[ 15.124000] PM: Syncing filesystems ... done.

[ 15.132000] PM: Preparing system for mem sleep

[ 15.132000] PM: Adding info for No Bus:vcs63

[ 15.132000] PM: Adding info for No Bus:vcsa63

[ 15.136000] Freezing user space processes ... (elapsed 0.01 seconds) done.

[ 15.160000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[ 15.184000] PM: Entering mem sleep

[ 15.184000] Suspending console(s) (use no_console_suspend to debug)

[ 15.200000] platform bfin dpmc.0: preparing suspend

[ 15.200000] rtc-bfin rtc-bfin: preparing suspend, may wakeup

[ 15.200000] musb_hdrc musb_hdrc.0: preparing suspend, may wakeup

[ 15.200000] bfin_mii_bus bfin_mii_bus.0: preparing suspend

[ 15.200000] bfin_mac bfin_mac.0: preparing suspend

[ 15.200000] bfin-spi bfin-spi.0: preparing suspend

[ 15.200000] bfin-uart bfin-uart.1: preparing suspend

[ 15.200000] i2c-bfin-twi i2c-bfin-twi.0: preparing suspend

[ 15.200000] physmap-flash physmap-flash.0: preparing suspend

[ 15.200000] nop_usb_xceiv nop_usb_xceiv: preparing suspend

[ 15.200000] usb usb1: preparing type suspend, may wakeup

[ 15.200000] bfin-wdt bfin-wdt: preparing suspend

[ 15.200000] bfin-wdt bfin-wdt: suspend

[ 15.200000] rtc rtc0: legacy class suspend

[ 15.200000] Generic PHY 0:01: suspend

[ 15.200000] mtd mtd2ro: legacy class suspend

[ 15.200000] mtd mtd2: legacy class suspend

[ 15.200000] mtd mtd1ro: legacy class suspend

[ 15.200000] mtd mtd1: legacy class suspend

[ 15.200000] mtd mtd0ro: legacy class suspend

[ 15.200000] mtd mtd0: legacy class suspend

[ 15.200000] nop_usb_xceiv nop_usb_xceiv: suspend

[ 15.200000] i2c i2c-0: suspend

[ 15.200000] spi spi0.1: legacy suspend

[ 15.200000] physmap-flash physmap-flash.0: suspend

[ 15.200000] i2c-bfin-twi i2c-bfin-twi.0: suspend

[ 15.200000] bfin-uart bfin-uart.1: suspend

[ 15.200000] bfin-spi bfin-spi.0: suspend

[ 15.200000] bfin_mac bfin_mac.0: suspend

[ 15.200000] bfin_mii_bus bfin_mii_bus.0: suspend

[ 15.200000] usb usb1: type suspend, may wakeup

[ 15.200000] musb_hdrc musb_hdrc.0: suspend, may wakeup

[ 15.200000] rtc-bfin rtc-bfin: suspend, may wakeup

[ 15.284000] musb_conn_timer_handler 277: state is a_idle

[ 16.096000] platform bfin dpmc.0: suspend

[ 16.096000] PM: suspend of devices complete after 896.000 msecs

[ 16.096000] bfin-wdt bfin-wdt: LATE suspend

[ 16.096000] Generic PHY 0:01: LATE suspend

[ 16.096000] usb usb1: LATE type suspend, may wakeup

[ 16.096000] nop_usb_xceiv nop_usb_xceiv: LATE suspend

[ 16.096000] i2c i2c-0: LATE suspend

[ 16.096000] physmap-flash physmap-flash.0: LATE suspend

[ 16.096000] i2c-bfin-twi i2c-bfin-twi.0: LATE suspend

[ 16.096000] bfin-uart bfin-uart.1: LATE suspend

[ 16.096000] bfin-spi bfin-spi.0: LATE suspend

[ 16.096000] bfin_mac bfin_mac.0: LATE suspend

[ 16.096000] bfin_mii_bus bfin_mii_bus.0: LATE suspend

[ 16.096000] musb_hdrc musb_hdrc.0: LATE suspend, may wakeup

[ 16.096000] rtc-bfin rtc-bfin: LATE suspend, may wakeup

[ 16.096000] platform bfin dpmc.0: LATE suspend

[ 16.096000] PM: late suspend of devices complete after 0.001 msecs

[ 16.096000] platform bfin dpmc.0: EARLY resume

[ 16.096000] rtc-bfin rtc-bfin: EARLY resume

[ 16.096000] musb_hdrc musb_hdrc.0: EARLY resume

[ 16.096000] bfin_mii_bus bfin_mii_bus.0: EARLY resume

[ 16.096000] bfin_mac bfin_mac.0: EARLY resume

[ 16.096000] bfin-spi bfin-spi.0: EARLY resume

[ 16.096000] bfin-uart bfin-uart.1: EARLY resume

[ 16.096000] i2c-bfin-twi i2c-bfin-twi.0: EARLY resume

[ 16.096000] physmap-flash physmap-flash.0: EARLY resume

[ 16.096000] i2c i2c-0: EARLY resume

[ 16.096000] nop_usb_xceiv nop_usb_xceiv: EARLY resume

[ 16.096000] usb usb1: EARLY type resume

[ 16.096000] Generic PHY 0:01: EARLY resume

[ 16.096000] bfin-wdt bfin-wdt: EARLY resume

[ 16.096000] PM: early resume of devices complete after 0.001 msecs

[ 16.096000] platform bfin dpmc.0: resume

[ 16.096000] rtc-bfin rtc-bfin: resume

[ 16.096000] musb_hdrc musb_hdrc.0: resume

[ 16.096000] bfin_mii_bus bfin_mii_bus.0: resume

[ 16.096000] bfin_mac bfin_mac.0: resume

[ 16.096000] bfin-spi bfin-spi.0: resume

[ 16.096000] bfin-uart bfin-uart.1: resume

[ 16.096000] i2c-bfin-twi i2c-bfin-twi.0: resume

[ 16.096000] physmap-flash physmap-flash.0: resume

[ 16.096000] spi spi0.1: legacy resume

[ 16.096000] i2c i2c-0: resume

[ 16.096000] nop_usb_xceiv nop_usb_xceiv: resume

[ 16.096000] usb usb1: type resume

[ 16.112000] musb_hub_control 356: port status 00000100

[ 16.112000] mtd mtd0: legacy class resume

[ 16.112000] mtd mtd0ro: legacy class resume

[ 16.112000] mtd mtd1: legacy class resume

[ 16.112000] mtd mtd1ro: legacy class resume

[ 16.112000] mtd mtd2: legacy class resume

[ 16.112000] mtd mtd2ro: legacy class resume

[ 16.112000] Generic PHY 0:01: resume

[ 16.112000] rtc rtc0: legacy class resume

[ 16.112000] bfin-wdt bfin-wdt: resume

[ 16.112000] PM: resume of devices complete after 16.000 msecs

[ 16.112000] bfin-wdt bfin-wdt: completing resume

[ 16.112000] usb usb1: completing type resume

[ 16.112000] nop_usb_xceiv nop_usb_xceiv: completing resume

[ 16.112000] physmap-flash physmap-flash.0: completing resume

[ 16.112000] i2c-bfin-twi i2c-bfin-twi.0: completing resume

[ 16.112000] bfin-uart bfin-uart.1: completing resume

[ 16.112000] bfin-spi bfin-spi.0: completing resume

[ 16.112000] bfin_mac bfin_mac.0: completing resume

[ 16.112000] bfin_mii_bus bfin_mii_bus.0: completing resume

[ 16.112000] musb_hdrc musb_hdrc.0: completing resume

[ 16.112000] rtc-bfin rtc-bfin: completing resume

[ 16.112000] platform bfin dpmc.0: completing resume

[ 16.116000] PM: Finishing wakeup.

[ 16.116000] Restarting tasks ... done.

[ 16.284000] musb_conn_timer_handler 277: state is a_idle

[ 17.284000] musb_conn_timer_handler 277: state is a_idle

 

root:/> rtcwake -s20 -mmem

wakeup from "mem" at Sat Jan 3 03:46:38 1970

[ 31.100000] PM: Syncing filesystems ... done.

[ 31.108000] Freezing user space processes ... (elapsed 0.01 seconds) done.

[ 31.132000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[ 31.156000] Suspending console(s) (use no_console_suspend to debug)

[ 36.164000] PM: suspend of devices complete after 5004.000 msecs

[ 36.164000] PM: late suspend of devices complete after 0.001 msecs

[ 36.164000] PM: early resume of devices complete after 0.001 msecs

[ 36.180000] PM: resume of devices complete after 16.000 msecs

[ 36.184000] Restarting tasks ... done.

root:/>

 

FROM dmesg:

[ 31.100000] PM: Syncing filesystems ... done.

[ 31.108000] PM: Preparing system for mem sleep

[ 31.108000] Freezing user space processes ... (elapsed 0.01 seconds) done.

[ 31.132000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.

[ 31.156000] PM: Entering mem sleep

[ 31.156000] Suspending console(s) (use no_console_suspend to debug)

[ 31.160000] platform bfin dpmc.0: preparing suspend

[ 31.160000] rtc-bfin rtc-bfin: preparing suspend, may wakeup

[ 31.160000] musb_hdrc musb_hdrc.0: preparing suspend, may wakeup

[ 31.160000] bfin_mii_bus bfin_mii_bus.0: preparing suspend

[ 31.160000] bfin_mac bfin_mac.0: preparing suspend

[ 31.160000] bfin-spi bfin-spi.0: preparing suspend

[ 31.160000] bfin-uart bfin-uart.1: preparing suspend

[ 31.160000] i2c-bfin-twi i2c-bfin-twi.0: preparing suspend

[ 31.160000] physmap-flash physmap-flash.0: preparing suspend

[ 31.160000] nop_usb_xceiv nop_usb_xceiv: preparing suspend

[ 31.160000] usb usb1: preparing type suspend, may wakeup

[ 31.160000] bfin-wdt bfin-wdt: preparing suspend

[ 31.160000] bfin-wdt bfin-wdt: suspend

[ 31.160000] rtc rtc0: legacy class suspend

[ 31.160000] Generic PHY 0:01: suspend

[ 31.160000] mtd mtd2ro: legacy class suspend

[ 31.160000] mtd mtd2: legacy class suspend

[ 31.160000] mtd mtd1ro: legacy class suspend

[ 31.160000] mtd mtd1: legacy class suspend

[ 31.160000] mtd mtd0ro: legacy class suspend

[ 31.160000] mtd mtd0: legacy class suspend

[ 31.160000] nop_usb_xceiv nop_usb_xceiv: suspend

[ 31.160000] i2c i2c-0: suspend

[ 31.160000] spi spi0.1: legacy suspend

[ 31.160000] physmap-flash physmap-flash.0: suspend

[ 31.160000] i2c-bfin-twi i2c-bfin-twi.0: suspend

[ 31.160000] bfin-uart bfin-uart.1: suspend

[ 31.164000] usb usb1: type suspend, may wakeup

[ 31.164000] bfin-spi bfin-spi.0: suspend

[ 31.164000] bfin_mac bfin_mac.0: suspend

[ 31.164000] bfin_mii_bus bfin_mii_bus.0: suspend

[ 31.164000] musb_hdrc musb_hdrc.0: suspend, may wakeup

[ 31.164000] rtc-bfin rtc-bfin: suspend, may wakeup

[ 31.284000] musb_conn_timer_handler 277: state is a_idle

[ 32.284000] musb_conn_timer_handler 277: state is a_idle

[ 33.284000] musb_conn_timer_handler 277: state is a_idle

[ 34.284000] musb_conn_timer_handler 277: state is a_idle

[ 35.284000] musb_conn_timer_handler 277: state is a_idle

[ 36.164000] platform bfin dpmc.0: suspend

[ 36.164000] PM: suspend of devices complete after 5004.000 msecs

[ 36.164000] bfin-wdt bfin-wdt: LATE suspend

[ 36.164000] Generic PHY 0:01: LATE suspend

[ 36.164000] usb usb1: LATE type suspend, may wakeup

[ 36.164000] nop_usb_xceiv nop_usb_xceiv: LATE suspend

[ 36.164000] i2c i2c-0: LATE suspend

[ 36.164000] physmap-flash physmap-flash.0: LATE suspend

[ 36.164000] i2c-bfin-twi i2c-bfin-twi.0: LATE suspend

[ 36.164000] bfin-uart bfin-uart.1: LATE suspend

[ 36.164000] bfin-spi bfin-spi.0: LATE suspend

[ 36.164000] bfin_mac bfin_mac.0: LATE suspend

[ 36.164000] bfin_mii_bus bfin_mii_bus.0: LATE suspend

[ 36.164000] musb_hdrc musb_hdrc.0: LATE suspend, may wakeup

[ 36.164000] rtc-bfin rtc-bfin: LATE suspend, may wakeup

[ 36.164000] platform bfin dpmc.0: LATE suspend

[ 36.164000] PM: late suspend of devices complete after 0.001 msecs

[ 36.164000] platform bfin dpmc.0: EARLY resume

[ 36.164000] rtc-bfin rtc-bfin: EARLY resume

[ 36.164000] musb_hdrc musb_hdrc.0: EARLY resume

[ 36.164000] bfin_mii_bus bfin_mii_bus.0: EARLY resume

[ 36.164000] bfin_mac bfin_mac.0: EARLY resume

[ 36.164000] bfin-spi bfin-spi.0: EARLY resume

[ 36.164000] bfin-uart bfin-uart.1: EARLY resume

[ 36.164000] i2c-bfin-twi i2c-bfin-twi.0: EARLY resume

[ 36.164000] physmap-flash physmap-flash.0: EARLY resume

[ 36.164000] i2c i2c-0: EARLY resume

[ 36.164000] nop_usb_xceiv nop_usb_xceiv: EARLY resume

[ 36.164000] usb usb1: EARLY type resume

[ 36.164000] Generic PHY 0:01: EARLY resume

[ 36.164000] bfin-wdt bfin-wdt: EARLY resume

[ 36.164000] PM: early resume of devices complete after 0.001 msecs

[ 36.164000] platform bfin dpmc.0: resume

[ 36.164000] rtc-bfin rtc-bfin: resume

[ 36.164000] musb_hdrc musb_hdrc.0: resume

[ 36.164000] bfin_mii_bus bfin_mii_bus.0: resume

[ 36.164000] bfin_mac bfin_mac.0: resume

[ 36.164000] bfin-spi bfin-spi.0: resume

[ 36.164000] bfin-uart bfin-uart.1: resume

[ 36.164000] i2c-bfin-twi i2c-bfin-twi.0: resume

[ 36.164000] physmap-flash physmap-flash.0: resume

[ 36.164000] spi spi0.1: legacy resume

[ 36.164000] i2c i2c-0: resume

[ 36.164000] nop_usb_xceiv nop_usb_xceiv: resume

[ 36.164000] usb usb1: type resume

[ 36.180000] musb_hub_control 356: port status 00000100

[ 36.180000] mtd mtd0: legacy class resume

[ 36.180000] mtd mtd0ro: legacy class resume

[ 36.180000] mtd mtd1: legacy class resume

[ 36.180000] mtd mtd1ro: legacy class resume

[ 36.180000] mtd mtd2: legacy class resume

[ 36.180000] mtd mtd2ro: legacy class resume

[ 36.180000] Generic PHY 0:01: resume

[ 36.180000] rtc rtc0: legacy class resume

[ 36.180000] bfin-wdt bfin-wdt: resume

[ 36.180000] PM: resume of devices complete after 16.000 msecs

[ 36.180000] bfin-wdt bfin-wdt: completing resume

[ 36.180000] usb usb1: completing type resume

[ 36.180000] nop_usb_xceiv nop_usb_xceiv: completing resume

[ 36.180000] physmap-flash physmap-flash.0: completing resume

[ 36.180000] i2c-bfin-twi i2c-bfin-twi.0: completing resume

[ 36.180000] bfin-uart bfin-uart.1: completing resume

[ 36.180000] bfin-spi bfin-spi.0: completing resume

[ 36.180000] bfin_mac bfin_mac.0: completing resume

[ 36.180000] bfin_mii_bus bfin_mii_bus.0: completing resume

[ 36.180000] musb_hdrc musb_hdrc.0: completing resume

[ 36.180000] rtc-bfin rtc-bfin: completing resume

[ 36.180000] platform bfin dpmc.0: completing resume

[ 36.184000] PM: Finishing wakeup.

[ 36.184000] Restarting tasks ... done.

[ 36.284000] musb_conn_timer_handler 277: state is a_idle

[ 37.284000] musb_conn_timer_handler 277: state is a_idle

[ 38.284000] musb_conn_timer_handler 277: state is a_idle

[ 39.284000] musb_conn_timer_handler 277: state is a_idle

[ 40.284000] musb_conn_timer_handler 277: state is a_idle

[ 41.284000] musb_conn_timer_handler 277: state is a_idle

 

 

Interesting - where is the 5sec delay coming from?

 

[ 31.164000] rtc-bfin rtc-bfin: suspend, may wakeup

[ 31.284000] musb_conn_timer_handler 277: state is a_idle

[ 32.284000] musb_conn_timer_handler 277: state is a_idle

[ 33.284000] musb_conn_timer_handler 277: state is a_idle

[ 34.284000] musb_conn_timer_handler 277: state is a_idle

[ 35.284000] musb_conn_timer_handler 277: state is a_idle

 

musb_conn_timer_handler is irrelevant

- its only something that snips in while we are in bfin_rtc_sync_pending()

 

I wonder too - why we wait 5secs before we check RTC_ISTAT_WRITE_PENDING again.

Mike would know more here.

 

 

/**

* bfin_rtc_sync_pending - make sure pending writes have complete

*

* Wait for the previous write to a RTC register to complete.

* Unfortunately, we can't sleep here as that introduces a race condition when

* turning on interrupt events. Consider this:

* - process sets alarm

* - process enables alarm

* - process sleeps while waiting for rtc write to sync

* - interrupt fires while process is sleeping

* - interrupt acks the event by writing to ISTAT

* - interrupt sets the WRITE PENDING bit

* - interrupt handler finishes

* - process wakes up, sees WRITE PENDING bit set, goes to sleep

* - interrupt fires while process is sleeping

* If anyone can point out the obvious solution here, i'm listening :). This

* shouldn't be an issue on an SMP or preempt system as this function should

* only be called with the rtc lock held.

*

* Other options:

* - disable PREN so the sync happens at 32.768kHZ ... but this changes the

* inc rate for all RTC registers from 1HZ to 32.768kHZ ...

* - use the write complete IRQ

*/

/*

static void bfin_rtc_sync_pending_polled(void)

{

while (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_WRITE_COMPLETE))

if (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_WRITE_PENDING))

break;

bfin_write_RTC_ISTAT(RTC_ISTAT_WRITE_COMPLETE);

}

*/

static DECLARE_COMPLETION(bfin_write_complete);

static void bfin_rtc_sync_pending(struct device *dev)

{

dev_dbg_stamp(dev);

while (bfin_read_RTC_ISTAT() & RTC_ISTAT_WRITE_PENDING)

wait_for_completion_timeout(&bfin_write_complete, HZ * 5);

dev_dbg_stamp(dev);

}

 

> Can you verify that EXT_WAKE is driven in the rtcwake cases where it

> takes 5000 ms to enter hibernate?

 

On my side EXT_WAKE is always driven - and shuts down VDDINT!

I wonder if something else (phyint?) in your system wakes up the system immediately.

 

Try to use rtcwake with a wakeup scheduled in 60secs.

Make sure it takes approx. 60 seconds!

QuoteReplyEditDelete

 

 

2010-07-29 12:14:31     Re: BF522 hibernate wake from i2ckeypadcontroller

Mike Frysinger (UNITED STATES)

Message: 91875   

 

blame the hardware.  iirc, any write to the RTC will latch the "write pending" bit.  if you look at the suspend/resume path, it is restoring the interrupt status bits.  i imagine that sets the "write pending" but doesnt fire off a "write complete" interrupt.

 

i picked HZ*5 as a pessimistic value, but even if it was just HZ*1, you'd still see a delay so long as the source of the missed interrupt is left undiscovered.

QuoteReplyEditDelete

 

 

2010-07-29 14:37:28     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Hennerich (GERMANY)

Message: 91884    > i picked HZ*5 as a pessimistic value, but even if it was just HZ*1,

> you'd still see a delay

 

I don't see that - If I set it to HZ - I only see a 1sec delay.

The 5HZ is BTW the root cause why wakeup by RTC doesn't work if resume is scheduled < 10sec.

 

-Michael

QuoteReplyEditDelete

 

 

2010-07-29 14:47:13     Re: BF522 hibernate wake from i2ckeypadcontroller

Mike Frysinger (UNITED STATES)

Message: 91885   

 

a 1sec delay is still a delay

 

the 5sec was picked because it'd be enough "to notice" and to figure out why a write interrupt was being missed.  in the normal course of things, the delay to a pending write is only checked if another write is going to occur, but even then it should be as long as the hardware delays since the write complete interrupt should have fired.  i doubt the completion was missed inbetween the "while" check and the call to the completion function ?

 

you should add #define DEBUG to the rtc-bfin driver to see the code paths.  the source is already enumerated with appropriate trace points pretty much everywhere.

QuoteReplyEditDelete

 

 

2010-07-29 20:24:53     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Dean (UNITED STATES)

Message: 91892   

 

We were able to get hibernate wake from the adp5588 keyboard controller today.    There was a hardware issue with the EXT_WAKE signal getting backdriven after the first hibernate wakeup.   That was prevented the VDDINT from ever going low the second time.  The rtcwake delay was confusing but unrelated.     The edge trigged irq in the keypad was also causing keys to stop working after the first wake and not resume on subsequent hibernates.    We were able to "fake out" the controller in the resume function so that the interupt would re-occur and get serviced normally after the CPU was up and running again.    

 

Thanks for the help, it pointed us in a different direction and helped us make progress.

 

-Michael

QuoteReplyEditDelete

 

 

2010-07-30 13:56:32     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Dean (UNITED STATES)

Message: 91932   

 

OK, we tried a couple of things here....

 

For the bfin_rtc_suspend call, we used the bfin_rtc_sync_pending_polled() call instead of the bfin_rtc_sync_pending() call.  This eliminated the 5 sec delay.  Not sure if that is a safe call long term.

 

 

 

bfin_write_RTC_ISTAT(RTC_ISTAT_WRITE_COMPLETE);

 

 

 

bfin_write_RTC_ICTL(bfin_read_RTC_ICTL() | RTC_ISTAT_WRITE_COMPLETE);

 

before the return.  This fixed the delay we were experiencing on the second (and third, etc.) calls to rtcwake we were doing.

 

It looks as if the WRITE_COMPLETE interrupt was not being re-enabled on resume.

 

Any thoughts?

QuoteReplyEditDelete

 

 

2010-07-30 13:58:21     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Dean (UNITED STATES)

Message: 91933   

 

The last part meant to say:

 

 

In the bfin_rtc_resume() call, we added:

 

bfin_write_RTC_ISTAT(RTC_ISTAT_WRITE_COMPLETE);

bfin_write_RTC_ICTL(bfin_read_RTC_ICTL() | RTC_ISTAT_WRITE_COMPLETE);

 

before the return.  This fixed the delay we were experiencing on the second (and third, etc.) calls to rtcwake we were doing.

 

It looks as if the WRITE_COMPLETE interrupt was not being re-enabled on resume.

QuoteReplyEditDelete

 

 

2010-07-30 18:20:53     Re: BF522 hibernate wake from i2ckeypadcontroller

Mike Frysinger (UNITED STATES)

Message: 91943   

 

hmm, i see what you mean.  my expectation was that all RTC MMRs were being powered by the Vbat and not the Vint.  in talking to some people here and looking more closely at the HRM though, it seems that only some of the bits in the MMRs are powered externally.

 

when you suspend to mem (remove Vint), the write pending bit in ICTL is cleared and that is why you see 5 sec delays.  if i had used a 1 sec delay, i dont think we would have noticed this bug ;).

 

so, to address that, the fix is something like:

static int bfin_rtc_resume(struct platform_device *pdev)

{

       if (device_may_wakeup(&pdev->dev))

                disable_irq_wake(IRQ_RTC);

-       else

-               bfin_write_RTC_ISTAT(-1);

+

+       while (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_SEC))

+               continue;

+       bfin_rtc_int_set(RTC_ISTAT_WRITE_COMPLETE);

 

        return 0;

}

QuoteReplyEditDelete

 

 

2010-07-30 18:37:13     Re: BF522 hibernate wake from i2ckeypadcontroller

Mike Frysinger (UNITED STATES)

Message: 91944   

 

Michael: why do we bang on RTC_ISTAT in dpmc ?  that is not a register that is used to ack interrupts (the RTC doesnt need that with any of its sources), so why bother clearing it ?  i cant see anywhere else in the Blackfin core where RTC_ISTAT is read; only the rtc-bfin driver.

 

i punted it all and i can still go to "standby" and "mem" just fine ...

QuoteReplyEditDelete

 

 

2010-07-31 08:40:35     Re: BF522 hibernate wake from i2ckeypadcontroller

Robin Getz (UNITED STATES)

Message: 91960   

 

Mike:

 

>+       while (!(bfin_read_RTC_ISTAT() & RTC_ISTAT_SEC))

 

this will busy wait for up to one second - won't it?

 

Is that what we want to do?

QuoteReplyEditDelete

 

 

2010-08-02 04:51:26     Re: BF522 hibernate wake from i2ckeypadcontroller

Michael Hennerich (GERMANY)

Message: 92041    > Michael: why do we bang on RTC_ISTAT in dpmc ? that is not a register

> that is used to ack interrupts (the RTC doesnt need that with any of

> its sources), so why bother clearing it ? i cant see anywhere else in

> the Blackfin core where RTC_ISTAT is read; only the rtc-bfin driver.

>

> i punted it all and i can still go to "standby" and "mem" just fine ...

 

IIRC this is a leftover from some original code.

I never questioned if this code is really necessary or not.

(it might have been necessary before the RTC driver took care of it)

So I don't bother removing it now.

 

I checked a patch into SVN trunk.

 

-Michael

QuoteReplyEditDelete

 

 

2010-08-02 12:26:17     Re: BF522 hibernate wake from i2ckeypadcontroller

Mike Frysinger (UNITED STATES)

Message: 92056   

 

i dont think we have a choice.  we need to be able to restore the correct ICTL values, and we need to make sure that the RTC registers are available before anyone gets a chance to read them.  so if we resume, and someone in userspace tries to read the current time quick enough, they'll get incorrect values.

QuoteReplyEditDelete

 

 

2010-08-02 12:51:41     Re: BF522 hibernate wake from i2ckeypadcontroller

Robin Getz (UNITED STATES)

Message: 92058   

 

Mike:

 

Wouldn't it make more sense to put a lock on the RTC then?  (like in bfin_rtc_read_time)?

 

-Robin

Attachments

    Outcomes