linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhao Yakui <yakui.zhao@intel.com>
To: yi.y.yang@intel.com
Cc: trenn@suse.de, Zhang Rui <rui.zhang@intel.com>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	david-b@pacbell.net, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, lenb@kernel.org,
	acpi-bugzilla@lists.sourceforge.net,
	Holger Macht <hmacht@suse.de>
Subject: Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup
Date: Thu, 20 Mar 2008 12:32:51 +0800	[thread overview]
Message-ID: <1205987571.4061.55.camel@localhost.localdomain> (raw)
In-Reply-To: <1205937444.3842.82.camel@yangyi-dev>

On Wed, 2008-03-19 at 22:37 +0800, Yi Yang wrote:
> > Any news on this?
> > I ran into a problem with the current implementation:
> > 
> > If one GPE is tight to several devices you get a message:
> > echo XYZ >/tmp/acpi/wakeup
> > ACPI: 'XXX' and 'XYZ' have the same GPE, can't disable/enable one
> > seperately
> > ACPI: 'YYY' and 'XYZ' have the same GPE, can't disable/enable one
> > seperately
> > and none of the devices are activated to be able to wake the machine up.
> > Which I expect is wrong, all should be enabled/disabled then IMO, but
> > it's probably not worth much fixing in /proc/acpi/...
> "Can't disable/enable one seperately" is just a warning, all the devices
> with the same GPE can be disabled/enabled once.
> 
> > 
> > The correct interface to use seem to be:
> > drivers/base/power/sysfs.c
> wakeup flag in this driver is a generic software flag in "struct
> device", but the wakeup flag you see in /proc/acpi/wakeup is a hardware
> wakeup flag in ACPI device, all the wakeup events triggered by hardware
> devices are handled by ACPI driver.
> 
In current kernel the wakeup flag in /proc/acpi/wakeup means whether the
device can wakeup the sleeping system. It is only used to wake the
system from S1/S3/S4. 
Now the power/wakeup sys I/F is created for every device. Maybe it is
better that  the power/wakeup sys I/F is only created for the device
that can wake up the sleeping system. In order to determine whether the
device can wake up the sleeping system, it is necessary to check whether
the associated ACPI device can support wakeup  and whether the native
device can support wakeup (For example: PCI device should support PME
function.)
> But i indeed regret wakeup flags in /sys/... and /proc/acpi/wakeup
> haven't any association. They should be consolidated in my opinion.

> Zhang Rui said they are doing it, but i didn't get any information about
> progress, i completely agree it should be done ASAP.

Now I am trying to do them. But the difficulty is that we should support
the runtime wakeup. 
> If you need to enbale wakeup, you.d better enable wakeup flag in
> both /proc/acpi/wakeup and /sys/..., i can use USB mouse to wake up my
> machine from S3.
> 
> > But this is rather broken?
> > Here an output of /proc/acpi/wakeup and /sys/...:
> > for x in `find /sys/ |grep wakeup`;do if [ $(cat $x) ];then echo $x; cat $x;fi;done
> > /sys/devices/pnp0/00:04/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/wakeu
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.7/usb4/4-1/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.7/usb4/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.2/usb3/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.1/usb2/power/wakeup
> > enabled
> > /sys/devices/pci0000:00/0000:00:1d.0/usb1/power/wakeup
> > enabled
> > trenn@stravinsky:/extern/trenn/packages/home:trenn> cat /proc/acpi/wakeup 
> > Device  S-state   Status   Sysfs node
> > PCI0      S5     disabled  no-bus:pci0000:00
> > 
> > I still think (from comments in drivers/base/power/sysfs.c, not sure
> > whether it really is that appropriate) it is wakeup sysfs file that
> > should be used for this.
> > I wonder why each device has a wakeup file, it should be enough to
> > create them dynamically if wakeup enable/disable is supported for a
> > specific device?
> > Also a second file is missing from which state (S3,S4,S5) the device can
> > wake the machine up.
> > 
> > If there can be multiple devices for one GPE, this information (the
> > power directory of multiple devices) could be linked together in sysfs?
> > E.g.
> > /sys/devices/pci0000:00/0000:00:1d.7/usb4/power/wakeup
> > is a link to:
> > /sys/devices/pci0000:00/0000:00:1d.2/usb3/power/wakeup
> > If both are using one wake-up GPE.
> > 
> > Also if the ACPI device caught through acpi_get_physical device is a PCI
> > bridge, it should get evaluated what is behind the bridge and this
> > device (e.g. a network card) should get the wakeup stuff set up, not the
> > bridge?
> > 
> > Does someone still look at this?
> > If not, shall I or is it on some queue?
> > Should this be discussed a bit more detailed first?
> > 
> >    Thomas
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2008-03-20  4:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-27  6:47 [PATCH linux-acpi] Fix /proc/acpi/alarm set error Yi Yang
2007-12-27  8:41 ` [PATCH linux-acpi] Remove superfluous code and correct counting error in function acpi_system_write_alarm Yi Yang
2007-12-29  8:22   ` [PATCH linux-acpi] Correct wakeup set error and append a new column PCI ID Yi Yang
2008-01-01 23:20     ` Pavel Machek
2008-01-02  2:03       ` Yi Yang
2008-01-02 16:09         ` Pavel Machek
2008-01-03  2:02           ` Yi Yang
2008-01-03  2:11           ` Yi Yang
2008-01-04  8:16     ` [PATCH linux-acpi] fix acpi fan state set error Yi Yang
2008-01-07  6:56       ` [PATCH] ACPI: fix processor throttling " Yi Yang
2008-01-08  3:21         ` [PATCH] ACPI: fix processor limit " Yi Yang
2008-01-24  0:45           ` [PATCH] ACPI: create proc entry 'power' only if C2 or C3 is supported Yi Yang
2008-01-24 14:43             ` Mark Lord
2008-01-09 22:21         ` [PATCH] ACPI: Add sysfs interface for acpi device wakeup Yi Yang
2008-01-10  7:43           ` Maxim Levitsky
2008-01-09 23:59             ` Yi Yang
2008-01-10 10:30               ` Matthew Garrett
2008-01-13 18:16               ` Pavel Machek
2008-01-11  8:16             ` Zhang Rui
2008-01-10 23:55               ` Yi Yang
2008-03-19 13:06                 ` Thomas Renninger
2008-03-19 14:37                   ` Yi Yang
2008-03-20  4:32                     ` Zhao Yakui [this message]
2008-03-19 18:52                   ` David Brownell
2008-03-20  5:12                     ` Zhao Yakui
2008-03-20  6:12                       ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205987571.4061.55.camel@localhost.localdomain \
    --to=yakui.zhao@intel.com \
    --cc=acpi-bugzilla@lists.sourceforge.net \
    --cc=david-b@pacbell.net \
    --cc=hmacht@suse.de \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=rui.zhang@intel.com \
    --cc=trenn@suse.de \
    --cc=yi.y.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).