public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* Suspend/Resume questions
@ 2009-01-12 17:11 Peter Barada
  2009-01-12 18:26 ` Koen Kooi
  2009-01-13 22:02 ` Kevin Hilman
  0 siblings, 2 replies; 4+ messages in thread
From: Peter Barada @ 2009-01-12 17:11 UTC (permalink / raw)
  To: linux-omap


I'm using the current PM branch (2.6.28-rc8, revision 2beb9b4b) to
investigate power consumption on an OMAP35x board (Logic's LV SOM).

When I:

# mount -t vfat /dev/mmc0blkp1 /mnt/sdcard
# echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
omapfb omapfb: timeout waiting for FRAME DONE
mmc0: card 133b removed
MMC: killing requests for dead queue
cpufreq: suspend failed to assert current frequency is what timing core
thinks it is.
Powerdomain (iva2_pwrdm) didn't enter target state 1
Powerdomain (core_pwrdm) didn't enter target state 1
Powerdomain (per_pwrdm) didn't enter target state 1
Could not enter target state in pm_suspend
cpufreq: resume failed to assert current frequency is what timing core
thinks it is.

eth0: link down
soc-audio soc-audio: scheduling resume work
Restarting tasks ...
soc-audio soc-audio: starting resume work
soc-audio soc-audio: resume work completed
done.
omap3530# mmc0: new high speed SD card at address 133b
mmcblk1: mmc0:133b SD02G 1.91 GiB 
 mmcblk1: p1
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

omap3530# ls -l /dev/mmcblk0*
ls: /dev/mmcblk0*: No such file or directory
omap3530# 

1) Is "echo mem > /sys/power/state" the proper method to put the board
into suspend?

2) Why does the MMC "move" from /dev/mmcblk0 before the suspend
to /dev/mmcblk1 after the suspend? (If the card is not mounted, it
doesn't "move").

3) Any ideas why the iva2, core, per power domains not change states to
PWRDM_POWER_RET?  Any way to find out?

4) Any suggestions on how to code the power button (attached to TWL4030
PWRON pin) to wake it back up again?

Thanks in advance!

-- 
Peter Barada <peterb@logicpd.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suspend/Resume questions
  2009-01-12 17:11 Suspend/Resume questions Peter Barada
@ 2009-01-12 18:26 ` Koen Kooi
  2009-01-12 19:34   ` Peter Barada
  2009-01-13 22:02 ` Kevin Hilman
  1 sibling, 1 reply; 4+ messages in thread
From: Koen Kooi @ 2009-01-12 18:26 UTC (permalink / raw)
  To: Peter Barada; +Cc: linux-omap

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]


Op 12 jan 2009, om 18:11 heeft Peter Barada het volgende geschreven:

>
> I'm using the current PM branch (2.6.28-rc8, revision 2beb9b4b) to
> investigate power consumption on an OMAP35x board (Logic's LV SOM).
>
> When I:
>
> # mount -t vfat /dev/mmc0blkp1 /mnt/sdcard
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> omapfb omapfb: timeout waiting for FRAME DONE
> mmc0: card 133b removed
> MMC: killing requests for dead queue
> cpufreq: suspend failed to assert current frequency is what timing  
> core
> thinks it is.
> Powerdomain (iva2_pwrdm) didn't enter target state 1
> Powerdomain (core_pwrdm) didn't enter target state 1
> Powerdomain (per_pwrdm) didn't enter target state 1
> Could not enter target state in pm_suspend
> cpufreq: resume failed to assert current frequency is what timing core
> thinks it is.
>
> eth0: link down
> soc-audio soc-audio: scheduling resume work
> Restarting tasks ...
> soc-audio soc-audio: starting resume work
> soc-audio soc-audio: resume work completed
> done.
> omap3530# mmc0: new high speed SD card at address 133b
> mmcblk1: mmc0:133b SD02G 1.91 GiB
> mmcblk1: p1
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> omap3530# ls -l /dev/mmcblk0*
> ls: /dev/mmcblk0*: No such file or directory
> omap3530#
>
> 1) Is "echo mem > /sys/power/state" the proper method to put the board
> into suspend?
>
> 2) Why does the MMC "move" from /dev/mmcblk0 before the suspend
> to /dev/mmcblk1 after the suspend? (If the card is not mounted, it
> doesn't "move").

Do you have CONFIG_MMC_UNSAFE_RESUME=y in your .config? It's basically  
always needed if you suspend a mounted filesystem on MMC/SD.

regards,

Koen

>

[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suspend/Resume questions
  2009-01-12 18:26 ` Koen Kooi
@ 2009-01-12 19:34   ` Peter Barada
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Barada @ 2009-01-12 19:34 UTC (permalink / raw)
  To: Koen Kooi; +Cc: linux-omap

On Mon, 2009-01-12 at 19:26 +0100, Koen Kooi wrote:
> Op 12 jan 2009, om 18:11 heeft Peter Barada het volgende geschreven:
> 
> >
> > I'm using the current PM branch (2.6.28-rc8, revision 2beb9b4b) to
> > investigate power consumption on an OMAP35x board (Logic's LV SOM).
> >
> > When I:
> >
> > # mount -t vfat /dev/mmc0blkp1 /mnt/sdcard
> > # echo mem > /sys/power/state
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > omapfb omapfb: timeout waiting for FRAME DONE
> > mmc0: card 133b removed
> > MMC: killing requests for dead queue
> > cpufreq: suspend failed to assert current frequency is what timing  
> > core
> > thinks it is.
> > Powerdomain (iva2_pwrdm) didn't enter target state 1
> > Powerdomain (core_pwrdm) didn't enter target state 1
> > Powerdomain (per_pwrdm) didn't enter target state 1
> > Could not enter target state in pm_suspend
> > cpufreq: resume failed to assert current frequency is what timing core
> > thinks it is.
> >
> > eth0: link down
> > soc-audio soc-audio: scheduling resume work
> > Restarting tasks ...
> > soc-audio soc-audio: starting resume work
> > soc-audio soc-audio: resume work completed
> > done.
> > omap3530# mmc0: new high speed SD card at address 133b
> > mmcblk1: mmc0:133b SD02G 1.91 GiB
> > mmcblk1: p1
> > eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> >
> > omap3530# ls -l /dev/mmcblk0*
> > ls: /dev/mmcblk0*: No such file or directory
> > omap3530#
> >
> > 1) Is "echo mem > /sys/power/state" the proper method to put the board
> > into suspend?
> >
> > 2) Why does the MMC "move" from /dev/mmcblk0 before the suspend
> > to /dev/mmcblk1 after the suspend? (If the card is not mounted, it
> > doesn't "move").
> 
> Do you have CONFIG_MMC_UNSAFE_RESUME=y in your .config? It's basically  
> always needed if you suspend a mounted filesystem on MMC/SD.

(Dang HTML encoding bounced my last message, resending in plaintext).

Well, dip me in paint and color me pink - thanks, that works great!

Any ideas on my other question (i.e. how to code to get PWRON pin of the
TWL4030 to bring it out of suspend)?

> regards,
> 
> Koen
> 
> >
-- 
Peter Barada <peterb@logicpd.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Suspend/Resume questions
  2009-01-12 17:11 Suspend/Resume questions Peter Barada
  2009-01-12 18:26 ` Koen Kooi
@ 2009-01-13 22:02 ` Kevin Hilman
  1 sibling, 0 replies; 4+ messages in thread
From: Kevin Hilman @ 2009-01-13 22:02 UTC (permalink / raw)
  To: Peter Barada; +Cc: linux-omap

Peter,

Some suggestions below...

Peter Barada <peterb@logicpd.com> writes:

> I'm using the current PM branch (2.6.28-rc8, revision 2beb9b4b) to
> investigate power consumption on an OMAP35x board (Logic's LV SOM).

First, thanks for testing the PM branch.  Much appreciated!

> When I:
>
> # mount -t vfat /dev/mmc0blkp1 /mnt/sdcard
> # echo mem > /sys/power/state
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> omapfb omapfb: timeout waiting for FRAME DONE
> mmc0: card 133b removed
> MMC: killing requests for dead queue
> cpufreq: suspend failed to assert current frequency is what timing core
> thinks it is.
> Powerdomain (iva2_pwrdm) didn't enter target state 1
> Powerdomain (core_pwrdm) didn't enter target state 1
> Powerdomain (per_pwrdm) didn't enter target state 1
> Could not enter target state in pm_suspend
> cpufreq: resume failed to assert current frequency is what timing core
> thinks it is.
>
> eth0: link down
> soc-audio soc-audio: scheduling resume work
> Restarting tasks ...
> soc-audio soc-audio: starting resume work
> soc-audio soc-audio: resume work completed
> done.
> omap3530# mmc0: new high speed SD card at address 133b
> mmcblk1: mmc0:133b SD02G 1.91 GiB 
>  mmcblk1: p1
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> omap3530# ls -l /dev/mmcblk0*
> ls: /dev/mmcblk0*: No such file or directory
> omap3530# 
>
> 1) Is "echo mem > /sys/power/state" the proper method to put the board
> into suspend?

Yes.

> 2) Why does the MMC "move" from /dev/mmcblk0 before the suspend
> to /dev/mmcblk1 after the suspend? (If the card is not mounted, it
> doesn't "move").
>
> 3) Any ideas why the iva2, core, per power domains not change states to
> PWRDM_POWER_RET?  Any way to find out?

Unfortunately, there's currently no easy way other than looking
through the PM registers themselves.  However, in your case, I think I
know what is going on.

IVA2 is not hitting RET most likely because the bootloader powers it
on but the kernel doesn't do anything with it.  The latest PM branch
(just announced) has a patch to ensure that IVA2 is put into RET
during bootup.  Could you try it?

For CORE and PER these are likely because the UART clocks console are
keeping these domains active.  If you

# echo 1 > /sys/power/clocks_off_while_idle

then the UART clocks will be disabled in idle or suspend allowing
those domains to hit retention.

If this still isn't working, can you enable CONFIG_PM_DEBUG and
CONFIG_DEBUG_FS and send me the output of 'cat /debug/pm_debug/count'
just after bootup.

Kevin

> 4) Any suggestions on how to code the power button (attached to TWL4030
> PWRON pin) to wake it back up again?
>
> Thanks in advance!
>
> -- 
> Peter Barada <peterb@logicpd.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-01-13 22:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-12 17:11 Suspend/Resume questions Peter Barada
2009-01-12 18:26 ` Koen Kooi
2009-01-12 19:34   ` Peter Barada
2009-01-13 22:02 ` Kevin Hilman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox