On Wednesday 20 June 2007, Alan Stern wrote:
On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
Pardon me for asking what may be a dumb question. Why does ACPI (or
anything else) need to know the target system state in order to decide
how a device should be suspended or whether wakeup should be
On Wednesday 20 June 2007, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 08:18, Shaohua Li wrote:
On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
On Wednesday 20 June 2007, Len Brown wrote:
I support the proposal that pm_message_t include the target state
in addition to the phase of entering that state.
The reasoning is simple, device drivers that receive a pm_message_t
will do different things depending on the target state.
They
On Tuesday 19 June 2007, Shaohua Li wrote:
+int acpi_pm_choose_sleep_state(acpi_handle handle, pm_message_t state)
+{
The second argument doesn't seem to be used. Is that intentional and if so,
then why?
That's what the platform hook API uses. It is indeed a
useless parameter.
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
The issue at hand is that some device drivers may need to know what the
target sleep state of the system will be when their .suspend() routines are
being executed. Currently, there's no means of passing that information to
the
drivers and
On Thu, 21 Jun 2007, David Brownell wrote:
If drivers actually need a handle on that state, that'd be a fair
approach; make it an opaque type though, platform-specific.
But actually I don't see much point to having such a struct. What
matters is the attributes of the target state (what
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
If drivers actually need a handle on that state, that'd be a fair
approach; make it an opaque type though, platform-specific.
But actually I don't see much point to having such a struct. What
On Thu, 21 Jun 2007, David Brownell wrote:
If a driver wants to find out whether some resource will be available
in the target system state, the only way is to ask the resource's
provider. Hence the driver needs to have some cookie (representing the
target state) that it can pass to the
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
If a driver wants to find out whether some resource will be available
in the target system state, the only way is to ask the resource's
provider. Hence the driver needs to have some cookie
On Thu, 21 Jun 2007, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
If a driver wants to find out whether some resource will be available
in the target system state, the only way is to ask the resource's
provider.
Hi!
IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.
For sufficiently small values of two that is.
Other solutions that have been described on the PM list include
3) Providing accessors to the
On Thursday, 21 June 2007 17:23, Alan Stern wrote:
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
On Thursday, 21 June 2007 18:35, David Brownell wrote:
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
So, can we make pm_message_t consist only of the target state?
Let's just finally get rid of pm_message_t.
Fine. How to we solve the problem at hand, then?
--
Premature
On Thursday, 21 June 2007 17:37, David Brownell wrote:
IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.
For sufficiently small values of two that is.
Other solutions that have been described on the PM list
On Thursday, 21 June 2007 16:48, David Brownell wrote:
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
The issue at hand is that some device drivers may need to know what the
target sleep state of the system will be when their .suspend() routines are
being executed. Currently, there's
On Thursday, 21 June 2007 20:51, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
If a driver wants to find out whether some resource will be available
in the target system
On Thursday 21 June 2007, Pavel Machek wrote:
Hi!
IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.
For sufficiently small values of two that is.
Other solutions that have been described on the PM
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
_How_ does the provider know what the next target state is?
That's an interface between the provider and the platform's PM code.
Remember those two
On Thursday, 21 June 2007 21:51, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
On Thu, 21 Jun 2007, David Brownell wrote:
On Thursday 21 June 2007, Alan Stern wrote:
_How_ does the provider know what the next target state is?
That's an interface between
On Thursday, 21 June 2007 22:03, David Brownell wrote:
On Thursday 21 June 2007, Pavel Machek wrote:
Hi!
IMO it can be done in two different ways:
1) via a .suspend() argument
2) via a global variable that the drivers can read.
For sufficiently small values of two that
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
platform-lowest_power_state_the_device_can_be_in(dev, wakeup)
and
platform-highest_power_state_the_device_can_be_in(dev)
where 'wakeup' tells the platform whether we want this device to be able to
wake up the system.
That won't work
On Thursday, 21 June 2007 22:22, David Brownell wrote:
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
On Thursday, 21 June 2007 16:48, David Brownell wrote:
They really don't care what the state is. The $SUBJECT patch isn't
driver code ... it's for platform hooks that expose
On Thursday, 21 June 2007 22:32, David Brownell wrote:
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
platform-lowest_power_state_the_device_can_be_in(dev, wakeup)
and
platform-highest_power_state_the_device_can_be_in(dev)
where 'wakeup' tells the platform whether we want
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
All of this is fine, but we need some way to tell ACPI what the next sleep
state will be, because currently _we_ _have_ _not_ one.
So, do we introduce an additional pm_op to do that or are we going to do
something else?
Simplest would be
On Thursday, 21 June 2007 22:46, David Brownell wrote:
On Thursday 21 June 2007, Rafael J. Wysocki wrote:
All of this is fine, but we need some way to tell ACPI what the next sleep
state will be, because currently _we_ _have_ _not_ one.
So, do we introduce an additional pm_op to do
On Thu, 21 Jun 2007, Rafael J. Wysocki wrote:
Does anyone have any objections to adding a new pm_op that will tell
the ACPI core (or generally, a platform core code) what target system sleep
state we are going to enter?
Go for it!
Alan Stern
-
To unsubscribe from this list: send the line
On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
http://marc.info/?l=linux-acpim=117873972806360w=2
I slightly changed it.
Add a helper routine, which gets the sleep state of a ACPI device.
Is it
On Wednesday, 20 June 2007 08:18, Shaohua Li wrote:
On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
http://marc.info/?l=linux-acpim=117873972806360w=2
I slightly changed it.
Add a helper
On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
Not. Could pm_message_t have a member indicating the suspend state?
Well, I thought about that, but I did't know what people on linux-pm would
think about that.
Alternatively, we could introduce a pm_target() global PM operation that will
On Wednesday, 20 June 2007 16:08, Alan Stern wrote:
On Wed, 20 Jun 2007, Rafael J. Wysocki wrote:
Not. Could pm_message_t have a member indicating the suspend state?
Well, I thought about that, but I did't know what people on linux-pm would
think about that.
Alternatively, we
On Wednesday 20 June 2007 07:32, Rafael J. Wysocki wrote:
On Wednesday, 20 June 2007 08:18, Shaohua Li wrote:
On Tue, 2007-06-19 at 13:52 +0200, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
http://marc.info/?l=linux-acpim=117873972806360w=2
I slightly changed it.
Add a helper routine, which gets the sleep state of a ACPI device.
Is it going to work with the recent code ordering changes? I mean,
On Tuesday, 19 June 2007 13:52, Rafael J. Wysocki wrote:
On Tuesday, 19 June 2007 04:33, Shaohua Li wrote:
Based on David's patch
http://marc.info/?l=linux-acpim=117873972806360w=2
I slightly changed it.
Add a helper routine, which gets the sleep state of a ACPI device.
Is it going
Based on David's patch
http://marc.info/?l=linux-acpim=117873972806360w=2
I slightly changed it.
Add a helper routine, which gets the sleep state of a ACPI device.
Index: 2.6.22-rc2/drivers/acpi/sleep/main.c
===
---
34 matches
Mail list logo
