Question about suspending a system

Question about suspending a system

[Francis Moreau]

Hello,

I'm trying to see how I could implement Suspend To Ram on my system
that embed a SH4 processor.

I'm almost completely new to this area so please forgive me if the
question is dumb. I read the documentation in Documentation/power and
must admit that I don't get all of it :)

So my question is that when we suspend the system, it seems that all
IRQs are masked and I'm a bit suprise since the event that should wake
up the system is an interrupt. This mask is done by
arch_suspend_disable_irqs() and none of the arch is overriding this
stub. If I'm right, how the system should be waked up ?

Anther point is that the device that consumes a lot on the system is
the hard drive. I can decrease its power consumption by stopping its
motor by using "hdparm" but it still consumes too much. So for now I'm
thinking of stopping to power it up completely. But I don't know it's
going to be easy to resume the hard drive. Does anybody have another
idea or have already experience such trick ?

Thanks
-- 
Francis

Re: Question about suspending a system

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 1234 bytes --]

On Mon, 2007-10-15 at 14:43 +0200, Francis Moreau wrote:

> So my question is that when we suspend the system, it seems that all
> IRQs are masked and I'm a bit suprise since the event that should wake
> up the system is an interrupt. This mask is done by
> arch_suspend_disable_irqs() and none of the arch is overriding this
> stub. If I'm right, how the system should be waked up ?

No, well, in most cases the CPU is actually turned off by some other
chip (like the PMU on powermac systems) and turned on again by it when
the system should wake up.

> Anther point is that the device that consumes a lot on the system is
> the hard drive. I can decrease its power consumption by stopping its
> motor by using "hdparm" but it still consumes too much. So for now I'm
> thinking of stopping to power it up completely. But I don't know it's
> going to be easy to resume the hard drive. Does anybody have another
> idea or have already experience such trick ?

If you search the linuxppc-dev list somebody implemented suspend to ram
(or rather he called it standby) for linkstation powerpc systems. That
might be interesting for you because the CPU is actually not powered off
in that implementatino.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Question about suspending a system

[David Brownell]

> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Mon, 15 Oct 2007 18:03:59 +0200
>
> On Mon, 2007-10-15 at 14:43 +0200, Francis Moreau wrote:
>
> > So my question is that when we suspend the system, it seems that all
> > IRQs are masked and I'm a bit suprise since the event that should wake
> > up the system is an interrupt. This mask is done by
> > arch_suspend_disable_irqs() and none of the arch is overriding this
> > stub. If I'm right, how the system should be waked up ?
>
> No, well, in most cases the CPU is actually turned off by some other
> chip (like the PMU on powermac systems) and turned on again by it when
> the system should wake up.

Not true on most embedded systems using ARM SOCs I've seen ... most
of those have the SOC enter a low power state which doesn't power off
the SOC, and moreover leaves the CPU (and most peripherals) in a low
power data-retaining state.

Coming back from suspend states (like "standby" or "suspend-to-RAM")
then doesn't involve any kind of powerup/reset at all.  That's a goal,
since it shrinks the suspend/resume cycle time substantially.

In conjunction with that model, the last step of entering a system
suspend state should involve disabling all IRQs that aren't flagged as
wakeup sources by enable_irq_wake().  That's shortly before the magic
which powers down memory and CPU, but after devices have all been told
to suspend themselves.


Of course, the CPU itself is often only a small part of the system's
power usage.  More power is saved by powering devices down, or even
off.  In that example of a disk drive, one way to handle that would
be to introduce a power domain within which the drive's controller
and the drive both live.  If that's properly located in the driver
model tree, as a device node, then its suspend and resume methods
could poer the drive off and on (respectively).

- Dave

Re: Question about suspending a system

[Francis Moreau]

On 10/15/07, David Brownell <david-b@pacbell.net> wrote:
> > From: Johannes Berg <johannes@sipsolutions.net>
> > Date: Mon, 15 Oct 2007 18:03:59 +0200
> >
> > On Mon, 2007-10-15 at 14:43 +0200, Francis Moreau wrote:
> >
> > > So my question is that when we suspend the system, it seems that all
> > > IRQs are masked and I'm a bit suprise since the event that should wake
> > > up the system is an interrupt. This mask is done by
> > > arch_suspend_disable_irqs() and none of the arch is overriding this
> > > stub. If I'm right, how the system should be waked up ?
> >
> > No, well, in most cases the CPU is actually turned off by some other
> > chip (like the PMU on powermac systems) and turned on again by it when
> > the system should wake up.
>
> Not true on most embedded systems using ARM SOCs I've seen ... most
> of those have the SOC enter a low power state which doesn't power off
> the SOC, and moreover leaves the CPU (and most peripherals) in a low
> power data-retaining state.
>

And it's my case too.

> Coming back from suspend states (like "standby" or "suspend-to-RAM")
> then doesn't involve any kind of powerup/reset at all.  That's a goal,
> since it shrinks the suspend/resume cycle time substantially.
>

True, and once the cpu is in standy mode, it's definitely not the
thing which consumes power.

> In conjunction with that model, the last step of entering a system
> suspend state should involve disabling all IRQs that aren't flagged as
> wakeup sources by enable_irq_wake().

Ok, I missed that because I'm using a 2.6.17 kernel.

>  That's shortly before the magic
> which powers down memory and CPU, but after devices have all been told
> to suspend themselves.
>

Is it done in pm_ops->enter method ?

>
> Of course, the CPU itself is often only a small part of the system's
> power usage.  More power is saved by powering devices down, or even
> off.

I'm thinking of making powering the disk off because when suspended it
still uses more that 5W !

>  In that example of a disk drive, one way to handle that would
> be to introduce a power domain within which the drive's controller
> and the drive both live.  If that's properly located in the driver
> model tree, as a device node, then its suspend and resume methods
> could poer the drive off and on (respectively).
>


Do you have any examples that you could give ?

BTW I'm using a SATA hard drive.

Thanks
-- 
Francis

Re: Question about suspending a system

[David Brownell]

> > In conjunction with that model, the last step of entering a system
> > suspend state should involve disabling all IRQs that aren't flagged as
> > wakeup sources by enable_irq_wake().
>
> Ok, I missed that because I'm using a 2.6.17 kernel.

Yeah, that part went mainline with the genirq framework, which
ISTR merged sometime after that.  But then, few non-{ARM,x86}
platforms do much with power management yet either.


> >  That's shortly before the magic
> > which powers down memory and CPU, but after devices have all been told
> > to suspend themselves.
>
> Is it done in pm_ops->enter method ?

Yes, that's the last step of entering the system power state.
After IRQs are off, etc.


> > Of course, the CPU itself is often only a small part of the system's
> > power usage.  More power is saved by powering devices down, or even
> > off.
>
> I'm thinking of making powering the disk off because when suspended it
> still uses more that 5W !

That would make me want to power it off too!


> >  In that example of a disk drive, one way to handle that would
> > be to introduce a power domain within which the drive's controller
> > and the drive both live.  If that's properly located in the driver
> > model tree, as a device node, then its suspend and resume methods
> > could poer the drive off and on (respectively).
>
> Do you have any examples that you could give ?

No example, sorry -- Linux has weak support of power/voltage domains,
unlike clock domains.  Hence my suggestion of packaging it as a device
tree node, so at least the suspend() and resume() methods get called
in the right place in the system sleep/wake sequence.

Most of the systems I've worked with don't have rotating media, unless
someone sticks a MicroDrive into a CF slot.

- Dave

Re: Question about suspending a system

[Francis Moreau]

On 10/16/07, David Brownell <david-b@pacbell.net> wrote:
> Most of the systems I've worked with don't have rotating media, unless
> someone sticks a MicroDrive into a CF slot.
>

Even a hard drive connected through USB ?

-- 
Francis

Re: Question about suspending a system

[David Brownell]

> > Most of the systems I've worked with don't have rotating media, unless
> > someone sticks a MicroDrive into a CF slot.
>
> Even a hard drive connected through USB ?

Well, I meant "embedded" systems ... given that, yes.

For that matter, rotating media on USB drives generally
need more than the 500 mA max power available through USB.
They need independant power supplies.  So their power
management doesn't really kick in with system suspend.

- Dave