Shutting down PCI devices on suspend

Shutting down PCI devices on suspend

[Matthew Garrett]

The default PCI suspend/resume calls (used if the driver doesn't
implement them itself) don't alter the device power state. This seems to
cause problems on some Thinkpads - going into S3 doesn't seem to result
in the on-board Radeon being put into D3, and as a result the battery is
drained at a higher rate than it should be. Who should be responsible
for making sure that devices are properly put to sleep:

1) The drivers (not immensely helpful in the case where we don't
necessarily have drivers registered for every device)
2) The kernel
3) The hardware itself?

I seem to remember someone mentioning something about Linux not checking
for hints from the hardware as to what state devices should be put in,
but I know little about this.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Nate Lawson]

Matthew Garrett wrote:
> The default PCI suspend/resume calls (used if the driver doesn't
> implement them itself) don't alter the device power state. This seems to
> cause problems on some Thinkpads - going into S3 doesn't seem to result
> in the on-board Radeon being put into D3, and as a result the battery is
> drained at a higher rate than it should be. Who should be responsible
> for making sure that devices are properly put to sleep:
> 
> 1) The drivers (not immensely helpful in the case where we don't
> necessarily have drivers registered for every device)
> 2) The kernel
> 3) The hardware itself?
> 
> I seem to remember someone mentioning something about Linux not checking
> for hints from the hardware as to what state devices should be put in,
> but I know little about this.

In FreeBSD, we do this at the bus layer.  So the ACPI and PCI bus code 
is responsible for powering down/up children.  We currently do it:

1. When no driver is attached and on reprobe
2. When suspending/resuming, based on evaluating _SxD

See this commit for details:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1604853+0+archive/2004/cvs-all/20041205.cvs-all

Notes: we had problems switching serial ports into D3.  It seems that an 
interrupt storm happens for this type of device.  This is likely a 
deficiency in our serial driver.  We only switch type 0 devices 
(non-bridge) since our bridge resume code needs improvement.

Hope this helps.

-- 
Nate


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Matthew Garrett]

On Sat, 2004-12-11 at 11:50 -0800, Nate Lawson wrote:
> In FreeBSD, we do this at the bus layer.  So the ACPI and PCI bus code 
> is responsible for powering down/up children.  We currently do it:
> 
> 1. When no driver is attached and on reprobe
> 2. When suspending/resuming, based on evaluating _SxD
> 
> See this commit for details:
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1604853+0+archive/2004/cvs-all/20041205.cvs-all

Does _SxD represent the "desired" mode for the hardware, or merely the
highest state it can be left in? A mail from Len earlier this year
suggested that if S3D returned 0x2, that meant that either D3 or D2 were
acceptable.

Is there any reason why adding something like

if (state==3) {
	pci_set_power_state(dev,ACPI_STATE_D3COLD)
}

to pci_device_suspend in the non-driver path and reenabling it in
pci_default_resume would result in things breaking?

(Possibly with sanity checks as to whether it's a bridge or not)

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Nate Lawson]

Matthew Garrett wrote:
> On Sat, 2004-12-11 at 11:50 -0800, Nate Lawson wrote:
> 
>>In FreeBSD, we do this at the bus layer.  So the ACPI and PCI bus code 
>>is responsible for powering down/up children.  We currently do it:
>>
>>1. When no driver is attached and on reprobe
>>2. When suspending/resuming, based on evaluating _SxD
>>
>>See this commit for details:
>>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1604853+0+archive/2004/cvs-all/20041205.cvs-all
> 
> 
> Does _SxD represent the "desired" mode for the hardware, or merely the
> highest state it can be left in? A mail from Len earlier this year
> suggested that if S3D returned 0x2, that meant that either D3 or D2 were
> acceptable.

_SxD is the highest state supported by the device for a given sleep 
state, yes.  We put devices in D3 unless _SxD specifies something 
higher.  The reason to do this is some devices can't wake the system if 
they are in D3.  ACPI 3.0 has ways to indicate a desired power state 
(not just maximum).  I don't have any evidence but fear some devices 
won't work after resuming if set to D3 and they indicate this with an 
_SxD so we always use the value in _SxD if present.

> Is there any reason why adding something like
> 
> if (state==3) {
> 	pci_set_power_state(dev,ACPI_STATE_D3COLD)
> }
> 
> to pci_device_suspend in the non-driver path and reenabling it in
> pci_default_resume would result in things breaking?
> 
> (Possibly with sanity checks as to whether it's a bridge or not)

Not that I can think of.  You probably want state == S3 || S4 since it's 
fine to power down devices for S4.  You'll probably find drivers that 
don't properly resume their device.  You have to make sure you power 
devices down after suspending them and power them up before resuming them.

-- 
Nate


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Arjen Verweij]

It would be swell if this worked for S5 as well. It's also the simplest 
case, since the hardware is reinitialised at boottime anyway.

Nate Lawson wrote:

> Matthew Garrett wrote:
>
>> On Sat, 2004-12-11 at 11:50 -0800, Nate Lawson wrote:
>>
>>> In FreeBSD, we do this at the bus layer.  So the ACPI and PCI bus 
>>> code is responsible for powering down/up children.  We currently do it:
>>>
>>> 1. When no driver is attached and on reprobe
>>> 2. When suspending/resuming, based on evaluating _SxD
>>>
>>> See this commit for details:
>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1604853+0+archive/2004/cvs-all/20041205.cvs-all 
>>>
>>
>>
>>
>> Does _SxD represent the "desired" mode for the hardware, or merely the
>> highest state it can be left in? A mail from Len earlier this year
>> suggested that if S3D returned 0x2, that meant that either D3 or D2 were
>> acceptable.
>
>
> _SxD is the highest state supported by the device for a given sleep 
> state, yes.  We put devices in D3 unless _SxD specifies something 
> higher.  The reason to do this is some devices can't wake the system 
> if they are in D3.  ACPI 3.0 has ways to indicate a desired power 
> state (not just maximum).  I don't have any evidence but fear some 
> devices won't work after resuming if set to D3 and they indicate this 
> with an _SxD so we always use the value in _SxD if present.
>
>> Is there any reason why adding something like
>>
>> if (state==3) {
>>     pci_set_power_state(dev,ACPI_STATE_D3COLD)
>> }
>>
>> to pci_device_suspend in the non-driver path and reenabling it in
>> pci_default_resume would result in things breaking?
>>
>> (Possibly with sanity checks as to whether it's a bridge or not)
>
>
> Not that I can think of.  You probably want state == S3 || S4 since 
> it's fine to power down devices for S4.  You'll probably find drivers 
> that don't properly resume their device.  You have to make sure you 
> power devices down after suspending them and power them up before 
> resuming them.
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Arjen Verweij]

Matthew,

I asked a similar question some time ago, to figure out what is needed 
to add Wake-on-Lan support. The NIC needs to be put into D3 state, but 
this doesn't happen automagically. Currently I use pci-config from the 
scyld website to accomplish this right before powerdown.

Hopefully someone can comment on how it should work (tm), my guess is 
that device drivers need to be signalled, and hence it will only work if 
the driver supports it. I know from the ATi forum that the linux driver 
does not support this (yet).

Maybe you can use pci-config as a work around.
http://www.scyld.com/diag/index.html
ftp://ftp.scyld.com/pub/diag/pci-config.c
http://atlas.et.tudelft.nl/verwei90/nforce2/scyld/pci-config.c (mirror)
Compile with: gcc-2.95 -O pci-config.c -o pci-config

Regards,

Arjen

Matthew Garrett wrote:

>The default PCI suspend/resume calls (used if the driver doesn't
>implement them itself) don't alter the device power state. This seems to
>cause problems on some Thinkpads - going into S3 doesn't seem to result
>in the on-board Radeon being put into D3, and as a result the battery is
>drained at a higher rate than it should be. Who should be responsible
>for making sure that devices are properly put to sleep:
>
>1) The drivers (not immensely helpful in the case where we don't
>necessarily have drivers registered for every device)
>2) The kernel
>3) The hardware itself?
>
>I seem to remember someone mentioning something about Linux not checking
>for hints from the hardware as to what state devices should be put in,
>but I know little about this.
>  
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> The default PCI suspend/resume calls (used if the driver doesn't
> implement them itself) don't alter the device power state. This seems to
> cause problems on some Thinkpads - going into S3 doesn't seem to result
> in the on-board Radeon being put into D3, and as a result the battery is
> drained at a higher rate than it should be. Who should be responsible
> for making sure that devices are properly put to sleep:
> 
> 1) The drivers (not immensely helpful in the case where we don't
> necessarily have drivers registered for every device)

Please do it in the drivers. Anything else is likely to break
currently working setups.

> 2) The kernel
> 3) The hardware itself?
> 
> I seem to remember someone mentioning something about Linux not checking
> for hints from the hardware as to what state devices should be put in,
> but I know little about this.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Matthew Garrett]

On Sun, 2004-12-12 at 17:44 +0100, Pavel Machek wrote:

> Please do it in the drivers. Anything else is likely to break
> currently working setups.

This requires a driver for every PCI device on the system. Is this the
best solution?

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> > Please do it in the drivers. Anything else is likely to break
> > currently working setups.
> 
> This requires a driver for every PCI device on the system. Is this the
> best solution?

Each PCI device is either:

* supported -- it has a driver, we are okay

* unsupported -- it should not be even turned on, right?

* legacy, like VGA or IDE -- okay, we need drivers for those. You need
to reinit them on resume, anyway, so....

...yes, I think this is the best solution.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Adam Belay]

On Sun, Dec 12, 2004 at 06:15:21PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > Please do it in the drivers. Anything else is likely to break
> > > currently working setups.

I agree.  However there may be other strategies to explore.

> > 
> > This requires a driver for every PCI device on the system. Is this the
> > best solution?
> 
> Each PCI device is either:
> 
> * supported -- it has a driver, we are okay
> 
> * unsupported -- it should not be even turned on, right?
> 
> * legacy, like VGA or IDE -- okay, we need drivers for those. You need
> to reinit them on resume, anyway, so....
> 
> ...yes, I think this is the best solution.
> 								Pavel
> -- 

Not necessarily.  Most unsupported devices start in the on state.  Also I
think it's difficult to see a consistent power management behavior/policy if
each driver is controlling it's devices' power state.  I'd prefer to have
drivers saving and restoring device state and then having the bus driver
take care of the actual power state transitions.

Thanks,
Adam


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> > Each PCI device is either:
> > 
> > * supported -- it has a driver, we are okay
> > 
> > * unsupported -- it should not be even turned on, right?
> > 
> > * legacy, like VGA or IDE -- okay, we need drivers for those. You need
> > to reinit them on resume, anyway, so....
> > 
> > ...yes, I think this is the best solution.
> 
> Not necessarily.  Most unsupported devices start in the on state.  Also I
> think it's difficult to see a consistent power management behavior/policy if
> each driver is controlling it's devices' power state.  I'd prefer to have
> drivers saving and restoring device state and then having the bus driver
> take care of the actual power state transitions.

Why?

Saving/restoring state is way more work than actual power state
transitions. Provide nice helpers so that power state transitions are
easy, but leave the work on the drivers, so that drivers may do
something special if required.

Ouch and btw linux-pm list exists where this stuff is debated...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Adam Belay]

On Sun, Dec 12, 2004 at 09:18:10PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > Each PCI device is either:
> > > 
> > > * supported -- it has a driver, we are okay
> > > 
> > > * unsupported -- it should not be even turned on, right?
> > > 
> > > * legacy, like VGA or IDE -- okay, we need drivers for those. You need
> > > to reinit them on resume, anyway, so....
> > > 
> > > ...yes, I think this is the best solution.
> > 
> > Not necessarily.  Most unsupported devices start in the on state.  Also I
> > think it's difficult to see a consistent power management behavior/policy if
> > each driver is controlling it's devices' power state.  I'd prefer to have
> > drivers saving and restoring device state and then having the bus driver
> > take care of the actual power state transitions.
> 
> Why?

Because the power management design should be layered:

device power off request -->

(start)
|
| class - disable user space interfaces, stop timers etc
|
| driver - save hardware state, prepare hardware for poweroff
|
| bus - power off physical device
|
| firmware (ex ACPI) - additional power logic (ex external device components
|					       may need to be powered off.
|					       This will typically involve Dx
|					       states)
/
(finish)

Layering is one of the reasons the driver core was created.

We currently have this:

device power off request -->

(start)
|
| driver (*suspend) - tell class to stop logical device (often large amounts
|		      of duplicate code between drivers)
|		    
|		    - Save device state
|		    
|		    - Power off physical device
|		    
|		    - totally ignore ACPI firmware Dx states (how could we
|		      handle them, we don't know enough about the layers below
|		      us.  ACPI may not be compiled into the kernel, the device
|		      may not have ACPI extensions etc.)
|
\
(finish)

I think it would be better if every layer in the driver stack played a role in
device power state transitions.

> 
> Saving/restoring state is way more work than actual power state
> transitions. Provide nice helpers so that power state transitions are
> easy, but leave the work on the drivers, so that drivers may do
> something special if required.

Could you provide an example of a special case?  I'm not sure if we should
design our model around the least common denominator of standard compliance.

> 
> Ouch and btw linux-pm list exists where this stuff is debated...

Yes I'm aware of it.  This issue also applies to ACPI very directly.

Thanks,
Adam


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> Because the power management design should be layered:
> 
> device power off request -->
> 
> (start)
> |
> | class - disable user space interfaces, stop timers etc
> |
> | driver - save hardware state, prepare hardware for poweroff
> |
> | bus - power off physical device
> |
> | firmware (ex ACPI) - additional power logic (ex external device components
> |					       may need to be powered off.
> |					       This will typically involve Dx
> |					       states)
> /
> (finish)

Driver needs to be in control. For every rule, there's exception
(buggy hw?). It is fine if classes or buses provide helpers, but
ultimately it needs to be driver's suspend using those helpers.

> | driver (*suspend) - tell class to stop logical device (often large amounts
> |		      of duplicate code between drivers)

Well, then feel free to move that duplicate code into helper
functions. I do think that I'd notice that large amounts of duplicate
code, but feel free to prove me wrong.

> |		    - totally ignore ACPI firmware Dx states (how could we
> |		      handle them, we don't know enough about the layers below
> |		      us.  ACPI may not be compiled into the kernel, the device
> |		      may not have ACPI extensions etc.)

Helpers can do that, right?

> > Saving/restoring state is way more work than actual power state
> > transitions. Provide nice helpers so that power state transitions are
> > easy, but leave the work on the drivers, so that drivers may do
> > something special if required.
> 
> Could you provide an example of a special case?  I'm not sure if we should
> design our model around the least common denominator of standard
> compliance.

Well, if you want your network card to do wake-on-lan, you need to
keep it powered on... And the driver is the piece of code that knows
if you want to do wake-on-lan, right?

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Adam Belay]

Hi,

On Mon, Dec 13, 2004 at 12:01:57AM +0100, Pavel Machek wrote:
> Hi!
> 
> > Because the power management design should be layered:
> > 
> > device power off request -->
> > 
> > (start)
> > |
> > | class - disable user space interfaces, stop timers etc
> > |
> > | driver - save hardware state, prepare hardware for poweroff
> > |
> > | bus - power off physical device
> > |
> > | firmware (ex ACPI) - additional power logic (ex external device components
> > |					       may need to be powered off.
> > |					       This will typically involve Dx
> > |					       states)
> > /
> > (finish)
> 
> Driver needs to be in control. For every rule, there's exception
> (buggy hw?). It is fine if classes or buses provide helpers, but
> ultimately it needs to be driver's suspend using those helpers.
> 
> > | driver (*suspend) - tell class to stop logical device (often large amounts
> > |		      of duplicate code between drivers)
> 
> Well, then feel free to move that duplicate code into helper
> functions. I do think that I'd notice that large amounts of duplicate
> code, but feel free to prove me wrong.
> 
> > |		    - totally ignore ACPI firmware Dx states (how could we
> > |		      handle them, we don't know enough about the layers below
> > |		      us.  ACPI may not be compiled into the kernel, the device
> > |		      may not have ACPI extensions etc.)
> 
> Helpers can do that, right?

Maybe, something really needs to be done about it in the short run.


Why must the driver be in complete control?  We can't ensure every driver will
behave consistently.  Why have a driver model at all if we can't break tasks
into layers of responsibility?

Yes, layering has small losses in flexability, but the advantage of ensuring
uniform behavior and capabilities is very important.  With layering, code
repitition is minimal and everything in the kernel is all around more
simplistic and easy to maintain.  I think we can have a higher average quality
of functionality and stability with this approach.  Also less work will be
required when developing new drivers or adding new functionality.  For
example, a developer could update class level code without breaking or needing
to change driver and bus level code.

Basically each component in the stack should not know or care about what the
components above or below it are going to do.  Each should be autonomous and
only concerned with completing its own well defined goal along the chain of
the process.  This can apply to most problems, including power management.

> 
> > > Saving/restoring state is way more work than actual power state
> > > transitions. Provide nice helpers so that power state transitions are
> > > easy, but leave the work on the drivers, so that drivers may do
> > > something special if required.
> > 
> > Could you provide an example of a special case?  I'm not sure if we should
> > design our model around the least common denominator of standard
> > compliance.
> 
> Well, if you want your network card to do wake-on-lan, you need to
> keep it powered on... And the driver is the piece of code that knows
> if you want to do wake-on-lan, right?

Firmware like ACPI will tell us what wake-on-lan capabilities we have.  The
bus layer also handles much of the physical aspects.  The user will say that
he or she wants the logical device "eth1", as an example, to wake up the
computer if any traffic is incoming.  So really all of the layers play some
role in wake-on-lan, right?  Is a device useful for wake-on-lan without a
corresponding logical ethernet device?

Furthermore, it can be more complicated than just keeping it powered on.  A
device might need a seperate power domain to be used for wake-on-lan than
normal operation.  ACPI could help with this.
 
Thanks,
Adam


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> > > | driver (*suspend) - tell class to stop logical device (often large amounts
> > > |		      of duplicate code between drivers)
> > 
> > Well, then feel free to move that duplicate code into helper
> > functions. I do think that I'd notice that large amounts of duplicate
> > code, but feel free to prove me wrong.

You did not show me that duplicated code...

> > > |		    - totally ignore ACPI firmware Dx states (how could we
> > > |		      handle them, we don't know enough about the layers below
> > > |		      us.  ACPI may not be compiled into the kernel, the device
> > > |		      may not have ACPI extensions etc.)
> > 
> > Helpers can do that, right?
> 
> Maybe, something really needs to be done about it in the short run.
> 
> 
> Why must the driver be in complete control?  We can't ensure every driver will
> behave consistently.  Why have a driver model at all if we can't break tasks
> into layers of responsibility?

Driver model is neccessary for suspending devices in right order. 

> Yes, layering has small losses in flexability, but the advantage of ensuring
> uniform behavior and capabilities is very important.  With layering, code
> repitition is minimal and everything in the kernel is all around more
> simplistic and easy to maintain.  I think we can have a higher average quality
> of functionality and stability with this approach.  Also less work
> will be

Maybe you'll have higher average quality, but I'm afraid that it will
also mean that few important drivers will no longer work that well
(see the loss of flexibility above).

Plus your solution is more complex and harder to understand.

> required when developing new drivers or adding new functionality.  For
> example, a developer could update class level code without breaking or needing
> to change driver and bus level code.

If you update class level without at least testing the drivers, you
are likely to cause problems. I'd rather have people test their
changes, and the way to do that is to leave the control at the driver
level.

> > Well, if you want your network card to do wake-on-lan, you need to
> > keep it powered on... And the driver is the piece of code that knows
> > if you want to do wake-on-lan, right?
> 
> Firmware like ACPI will tell us what wake-on-lan capabilities we have.  The
> bus layer also handles much of the physical aspects.  The user will say that
> he or she wants the logical device "eth1", as an example, to wake up the
> computer if any traffic is incoming.  So really all of the layers play some
> role in wake-on-lan, right?  Is a device useful for wake-on-lan without a
> corresponding logical ethernet device?

I do not think mapping between eth1, PCI device and ACPI device is
readily available in kernel somewhere. 
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Matthew Garrett]

On Sun, 2004-12-12 at 18:15 +0100, Pavel Machek wrote:

> * legacy, like VGA or IDE -- okay, we need drivers for those. You need
> to reinit them on resume, anyway, so....
							
The current situation is that we can reinit /most/ VGA hardware from
userspace, but it's less than trivial to make sure that the appropriate
devices are shut down. Surely the situation is more like the following:

1) Some devices don't have drivers. In most cases, it doesn't matter
what power state they're in. Therefore, setting them to D3 (or whatever
SxD says) shouldn't be a problem.

2) For devices that do have drivers, the drivers should set them to the
appropriate power state.

I'd argue that devices that need to be in a specific power state but
whose drivers don't state this have broken drivers. If there's no driver
in charge of the device, we should be able to do whatever we want.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> > * legacy, like VGA or IDE -- okay, we need drivers for those. You need
> > to reinit them on resume, anyway, so....
> 							
> The current situation is that we can reinit /most/ VGA hardware from
> userspace, but it's less than trivial to make sure that the appropriate
> devices are shut down. Surely the situation is more like the following:
> 
> 1) Some devices don't have drivers. In most cases, it doesn't matter
> what power state they're in. Therefore, setting them to D3 (or whatever
> SxD says) shouldn't be a problem.

Agreed, if device has no driver, doing some default action is
possible.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

RE: Shutting down PCI devices on suspend

[Li, Shaohua]

>Yes, layering has small losses in flexability, but the advantage of
>ensuring
>uniform behavior and capabilities is very important.  With layering,
code
>repitition is minimal and everything in the kernel is all around more
>simplistic and easy to maintain.  I think we can have a higher average
>quality
>of functionality and stability with this approach.  Also less work will
be
>required when developing new drivers or adding new functionality.  For
>example, a developer could update class level code without breaking or
>needing
>to change driver and bus level code.
>
>Basically each component in the stack should not know or care about
what
>the
>components above or below it are going to do.  Each should be
autonomous
>and
>only concerned with completing its own well defined goal along the
chain of
>the process.  This can apply to most problems, including power
management.
I like the layering device model very much. We really need a unified
model to link the physical devices with ACPI devices. I have some
attempts before (see
http://www.gossamer-threads.com/lists/linux/kernel/490570?#490570), but
it isn't clear. Pat suggested me using some helpers for this issue, but
it would be better if the device model can unified handle it.

>Firmware like ACPI will tell us what wake-on-lan capabilities we have.
The
>bus layer also handles much of the physical aspects.  The user will say
>that
>he or she wants the logical device "eth1", as an example, to wake up
the
>computer if any traffic is incoming.  So really all of the layers play
some
>role in wake-on-lan, right?  Is a device useful for wake-on-lan without
a
>corresponding logical ethernet device?
>
>Furthermore, it can be more complicated than just keeping it powered
on.  A
>device might need a seperate power domain to be used for wake-on-lan
than
>normal operation.  ACPI could help with this.
ACPI could help more. Many ACPI devices have specific methods, such as
Floppy, SATA, USB. We just ignored them now. It's more important for
ACPI 3.0. In ACPI 3.0, every device could have a _OSC method, and the
drivers must indicate their capability. 

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: Shutting down PCI devices on suspend

[Pavel Machek]

Hi!

> >Basically each component in the stack should not know or care about
> what
> >the
> >components above or below it are going to do.  Each should be
> autonomous
> >and
> >only concerned with completing its own well defined goal along the
> chain of
> >the process.  This can apply to most problems, including power
> management.

> I like the layering device model very much. We really need a unified
> model to link the physical devices with ACPI devices. I have some
> attempts before (see
> http://www.gossamer-threads.com/lists/linux/kernel/490570?#490570), but
> it isn't clear. Pat suggested me using some helpers for this issue, but
> it would be better if the device model can unified handle it.

Driver model is complex enough beast as of now. Please do use helpers
for now.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/