Re: [linux-pm] Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 21 Jun 2007, Rafael J. Wysocki wrote:

> > Just do 1). Global variables are ugly, and we already have space in
> > pm_message_t. 
> 
> Well, this is what Len voted for, I think.  David is against it.
> 
> I also think that the cleanest way would be to pass that as an argument
> to .suspend(), but currently pm_message_t. is passed by value and if we
> made it a real struct (ie. with more than one field), that would also become
> ugly, IMHO.
> 
> So, can we make pm_message_t consist only of the target state?

You're both repeating the mistakes from two years ago.

You can't use a simple type to describe a target system state.  While 
it might work for ACPI states, it won't work on general (i.e., 
non-ACPI) systems.  It's probably a mistake even to use a data 
structure to describe a system state, since the requirements are so 
complex.  The only reasonable approach is to describe it in code.

What you can do is this: Pick a small enumerated set of labels for some 
selected system states.  For example:

enum pm_system_state {
	PM_STATE_RUNNING,
	PM_STATE_STANDBY,
	PM_STATE_SUSPEND,
	PM_STATE_HIBERNATE,
};

(It might be preferable to make the list more configurable, perhaps 
even allow changes at runtime.  Never mind all that for now.)

These are merely labels, they don't actually describe anything.  To use 
them, you would have to pass them to a subsystem routine for 
interpretation.  For example, pci_select_state() might pass one of 
these things to an ACPI routine, which would know what ACPI state 
corresponded to the given pm_system_state and would be able to say what 
D-state would be appropriate for a given PCI device.  On a non-ACPI 
platform, pci_select_state() would have to call a different routine -- 
something platform-dependent -- to do the same job.


On the other hand, maybe you don't need anything like this at all.  
What would happen if a PCI driver put its device into a D-state which 
wasn't supported under the target ACPI state?  Would it be so terrible?
I can imagine that the requested wakeup functionality might not be 
available, but would it prevent the device from working properly when 
it was resumed?

Alan Stern

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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux