Re: [linux-pm] Re: [PATCH] PCI: Add pci shutdown ability

[Nigel Cunningham]

Hi.

On Tue, 2005-04-26 at 16:23, Adam Belay wrote:
> Ok, here's a new idea.
> 
> For many devices "->suspend" and "->resume" with pm_message_t is exactly what
> we need.  However, as we support more advanced power management features, such
> as runtime power management, or power containers, we need something a little
> more specific.  The exact power state must be specified among other issues.
> 
> We might do something like this:
> 
> Keep "->suspend" and "->resume" around unchanged. (so the states would
> probably remain as PMSG_FREEZE and PMSG_SUSPEND).  If the driver doesn't
> support the more advanced PM methods just use these.  They work well enough
> for system sleep states etc.

Ok, so for each driver we have either ->suspend & ->resume or
->change_state, ->halt and ->continue, right?

Is it safe to assume that these later methods would get called from the
same places in device_suspend and device_resume that ->suspend &
->resume are called from at the moment? That would seem to me to be the
cleanest way of addressing ordering ... but then I find myself asking,
why not just do one or the other?

I have to admit that I've never liked ->suspend & ->resume. They imply
too much knowledge in the caller about what start the device was in. I'd
like, instead, to see all of the decision making as to what state to
actually be in exist in the driver and the helpers it uses. Then the
semantics becomes requests and notifications of system/child/parent
state changes rather than _commands_ to suspend/resume. This should be a
lot cleaner in the context of runtime power management as well.

> When changing system state, we call "change_state" for every device with power
> resources.  Devices that do not directly consume power or have power states
> will not implement "change_state" so we will call "halt" and "continue"
> instead.

Now you're confusing me...

if (driver->suspend | driver->resume)
	driver->suspend|resume
elseif (driver->change_state)
	driver->change_state
elseif (driver->halt | driver->continue)
	driver->halt|continue
else
	printk("Urgh. No driver power management methods for %s.\n");


> When shutting down the system, halt has the option of turning off the device,
> as it will see the SHUTDOWN reason.  So it's a driver-knows-best approach
> instead of assuming everything must be turned off, or everything must just be
> stopped.

I do like this idea. Especially if we can say "I'm rebooting rather than
powering off."

> So in theory, with cpufreq, we could stop userspace, ->halt every device
> (drivers won't do anything if they know it's not necessary), change the
> frequency, and then resume operation.

That looks like a good idea too. But it also sounds like an abuse of
suspend|resume. Perhaps it implies the need/desire for more genericness
to pm_message_t (sounds familiar!).

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/