[PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Zhang Rui]

This patch set is against acpi-test sysfs branch, and will duplicate several ACPI procfs functions in sysfs.
As struct subsystem power_subsys is referred and the interface under /sys/power/ is changed by this patch series,
I wish to receive some comments from linux-pm too.

Patch 01:
	add a Kconfig option which is used to make ACPI procfs interface configurable.
	This will be used by all the following sysfs conversion patches.

Patch 02:
	add ACPI debug attribute in sysfs.
	By applying this patch, /proc/acpi/debug_layer && debug_level is deprecated by
	/sys/module/acpi/parameter/debug_layer && debug_level.

Patch 03-05:
	add ACPI sleep attributes in sysfs.
	/proc/acpi/sleep is already deprecated by /sys/power/state.
	/proc/acpi/alarm is deprecated by /sys/power/alarm.
	For those devices that support "wake" attribute, two files, "sleep_state" and "wakeup", are created for these devices.
	"sleep_state" indicates the lowest sleeping state that can be entered while still providing wake functionality.
	"wakeup" can be used to enable/disable the device's ability to wake a sleeping system.
	So /proc/acpi/wakeup is deprecated by /sys/devices/acpi_system/.../xxx/sleep_state && wakeup.

Patch 06:
	add ACPI info in sysfs which indicates ACPICA version.
	/sys/firmware/acpi/info is create and /proc/acpi/info is marked as deprecated.

Things not do:
	/proc/acpi/dsdt and /proc/acpi/fadt are not duplicated in sysfs, as the acpidump tools are quite handy.
	And another reason is that, if we do this, we want all the ACPI tables be shown in sysfs, like
	the multiple ssdts and dynamic loaded ssdts. And we are not able to do this now. 

Things will do:
	This patch set only duplicates the ACPI attributes shown in /proc/acpi/.
	The next patch set will duplicate attributes in sysfs for ACPI devices.

For users who are used to the procfs interface, setting CONFIG_ACPI_PROCFS will make them feel nothing different.
But I'd like you guys to try the ACPI sysfs interfaces though it's not complete now. :)

Re: [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Saturday 06 January 2007 3:35 am, Zhang Rui wrote:
> This patch set is against acpi-test sysfs branch, and will duplicate
> several ACPI procfs functions in sysfs. 
> As struct subsystem power_subsys is referred and the interface under
> /sys/power/ is changed by this patch series, 
> I wish to receive some comments from linux-pm too.

First, please be sure your mailer wraps TX lines well before the end
of an 80 character line.  (I had to do that manually in this reply.)

Second, I'm glad to see attention paid to those /proc/acpi files,
which AFAICT have been mostly left alone for many years now; that
neglect has been puzzling, given the driver model and sysfs plus
the general deprecation of procfs for operational tasks.

Third, stuff in /sys/power should be generic, and not depend on ACPI
infrastructure or models ... it should for example work for embedded
platforms where Linux runs on the bare metal.  Moreover, in general
an ACPI-specific interface should be the very last (and non-portable,
worst) choice, not the first/default/preferred one.


Which means in particular that:

> Patch 03-05:
> 	add ACPI sleep attributes in sysfs.
> 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> 	/proc/acpi/alarm is deprecated by /sys/power/alarm.

A /sys/power/alarm thing conflicts with ongoing RTC framework work.

You may have missed the patches I've sent making RTCs be "just another
wakeup-capable device" -- an interface that already works with multiple
RTCs, is not in the least bit coupled to ACPI, and is on track to work
with on more platforms -- or the proposal to provide sysfs support for
activiting alarms within the RTC framework.

The latest patches relevant to the RTC used by ACPI are:

 http://marc.theaimsgroup.com/?l=linux-kernel&m=116802017116195&w=2
 http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044406838&w=2
 http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044531547&w=2
 http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044532646&w=2

(Only that last one touches ACPI directly.)

Note that like it says in the first message, this version doesn't
have the "remove /proc/acpi/alarm" stuff, mostly to simplify merging
of the core driver code; that will be done later, and in any case the
old drivers/char/rtc.c code didn't interact with it either.  It worked
in earlier versions of the patch.  (Modulo the fact that ACPI wakeup
from STR seems to usually be a total lose.)  One such version:

 http://marc.theaimsgroup.com/?l=linux-kernel&m=116406177605472&w=2

You'll observe those ACPI bits are kind of messy.  The clean
approach I have in mind is to have callbacks in platform_data,
with which ACPI -- or EFI etc -- can do whatever nastiness it
needs to let the RTC alarm trigger wakeup from system sleep state.
A "bare metal" platform would just enable_irq_wake(); ACPI would
set a magic PM1 bit or whatever; etc.

(In terms of userspace tools, I posted an "rtcwake.c" tool working
on several platforms, including x86 PCs with the above patch plus
some ARM systems, notably AT91rm9200, with rtc wakeup irqs.)


> 	For those devices that support "wake" attribute,

Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
attribute.  And that ACPI is finally going to start working with those
attributes ...


> 	two files, 
> 	"sleep_state" and "wakeup", are created for these devices. 

I'm going to be assuming your "wakeup" attribute has the same semantics
as that existing one.  If it doesn't, you should either fix your model,
or justify changing the Linux-wide model.


As for sleep_state:

> 	"sleep_state" indicates the lowest sleeping state that can be
> 	entered while still providing wake functionality. 

I understand that /proc/acpi/wakeup exposes this information.  I don't
understand how userspace is expected to use it.  Or, for that matter,
how this model ought to work on non-ACPI systems.  But most especially,
if it's useful, I don't understand why it would be ACPI-only.

(Yes, there are huge gaps in Linux-PM wakeup support.  Weak ACPI suppport
for it, especially from STR -- without swsusp -- is a big factor.  I
was pleased to see RTC wakeup from ACPI S4 actually work ... first time
I've ever seen ACPI wakeup ever work correctly.)


> 	"wakeup" can be used to enable/disable the device's
> 	ability to wake a sleeping system. 

We've found a need to nuance that a bit.  So for example a USB root
hub sure ought to support the USB "remote wakeup" mechanism in that
way, and by and large the BIOS will declare that it does.  (Not that
I've ever observed that to work from ACPI STR, mind you!!)

However, it appears out that on some boards remote wakeup doesn't
work right ... either there's a chipset bug, or some board wiring
problem, or something of that ilk.  This impacts _runtime_ power
management as well as system-wide sleep states.  So "wakeup" also
gets used to disable runtime PM techniques like suspending USB
devices to reduce system power drain (since that relies on remote
wakeup).  The hardware mechanism isn't used only to wake sleeping
systems; so the sysfs attribute isn't limited to that role either.


> 	So /proc/acpi/wakeup is deprecated by
> 	/sys/devices/acpi_system/.../xxx/sleep_state && wakeup. 

Why is ACPI still not coupling such information to the REAL device
nodes?  On my laptop, right now without any wakeup-capable USB
devices attached, the appended script produces:

% pm-wake
lan        on  pci0000:00/0000:00:0a.0/0000:01:01.0
           on  pci0000:00/0000:00:06.1
hub        on  pci0000:00/0000:00:02.2/usb3
usb_host   on  pci0000:00/0000:00:02.2
hub        on  pci0000:00/0000:00:02.1/usb2
usb_host   on  pci0000:00/0000:00:02.1
hub        on  pci0000:00/0000:00:02.0/usb1
usb_host   on  pci0000:00/0000:00:02.0
           on  pci0000:00/0000:00:01.1
rtc        on  pnp0/00:06
%  

That's with various patches applied, notably one to transfer the
PCI PM "can issue PME#" flags to the device's wakeup flag.  (Much
the same patch circulated when the wakeup flag was added.  Works
fine on x86, but there was an PCI init sequencing issue on PPC
that kept it from getting merged.  And of course, ACPI wants some
additional out-of-band signaling, so only the RTC device is truly
a wakeup source on this system; sigh.)

That 00:06.1 device is a Winmodem, which /proc/acpi/wakeup doesn't
list as a wakeup event source ... maybe for good reason.  The 00:01.1
device is SMBUS, not listed for what I'm guessing is a less good
reason (i.e. it really IS a wakeup device, but managed internally
to ACPI).  I'm guessing RTC is omitted from /proc/acpi/wakeup since
that's really just a dump of one table, and it's not actually a
list of the system's wakeup-capable ACPI devices.

Note that /proc/acpi/wakeup says everything supports wake from S3;
but that's never worked on this system.  (Yes, even after enabling
everything in /proc/acpi/wakeup.)  RTC wakeup from S4 works, but
that's a mode that /proc/acpi/wakeup says doesn't exist, so I might
have been imagining that.  :)
 
- Dave

#!/bin/bash

# show the wakeup-capable devices and what's enabled/disabled

# class_label *:* ==> $type
class_label ()
{
	case $1 in
	# recognize common types of wakeup-capable devices
	i2c-dev:*)	type="smbus     "; return 0;;
	input:*)	type="input     "; return 0;;
	mmc_host:*)	type="mmc_host  "; return 0;;
	net:eth*)	type="lan       "; return 0;;
	net:*)		type="net       "; return 0;;
	pcmcia_socket:*)type="pcmcia    "; return 0;;
	rtc:*)		type="rtc       "; return 0;;
	sound:*)	type="modem     "; return 0;;
	tty:*)		type="tty       "; return 0;;
	usb_host:*)	type="usb_host  "; return 0;;
	esac
	return 1
}

# interface_label $PATH ==> $type
interface_label ()
{
	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		class_label $F && return
	done
}

# devtype $PATH ==> $type
devtype ()
{
	local F T

	# fixed length, currently ten spaces
	type=""

	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		if [ ! -d "$1/$F" ]
		then
			break;
		fi

		# is this a usb interface?
		if [ -f $1/$F/bInterfaceClass ]
		then
			interface_label $1/$F && return
		fi

		case $F in
		# use interface's label if possible, else generic
		usb_device:*)
			read T < $1/maxchild
			if [ 0 -lt $T ]
			then
				type="hub       "
				return
			fi
			type="(usb)     "
			continue;;
		*:*)	class_label $F && return ;;
		esac

	done

	if [ "$type" = "" ]
	then
		for T in $(cd $1 >/dev/null 2>&1 ; echo fw-host*/ieee1394_host:*)
		do
			if [ ! -L "$1/$T" ]
			then
				break;
			fi
			type="firewire  "
			return
		done
	fi

	if [ "$type" = "" ]
		then
		type="          "
	fi
}

cd /sys/devices
for F in $(find * -name 'wakeup')
do
	# F=.../power/wakeup
	read value < $F
	if [ "$value" = "" ]
	then
		continue
	fi

	# F=...
	F=$(dirname $(dirname $F))
	devtype $F

	# for each entry that actually supports wakeup, one line with:
	#  - device type (if recognized)
	#  - wake on/OFF
	#  - /sys/devices/... path
	case "$value" in
	"disabled")	echo "$type OFF $F" ;;
	"enabled")	echo "$type on  $F" ;;
	esac
done

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Matthew Garrett]

On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:

> Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> attribute.  And that ACPI is finally going to start working with those
> attributes ...

It's not necessarily possible to map from an ACPI object with a wakeup 
capability to a Linux device, so there's going to have to be some degree 
of interface nastiness. However, some devices can be sensibly mapped, 
and ideally those should be integrated into 
/sys/devices/.../power/wakeup.

However, I'm not entirely sure /how/ that integration should happen. If 
both the Linux driver and ACPI know how to enable wakeup for a device, 
what should writing to power/wakeup do?

> > 	So /proc/acpi/wakeup is deprecated by
> > 	/sys/devices/acpi_system/.../xxx/sleep_state && wakeup. 
> 
> Why is ACPI still not coupling such information to the REAL device
> nodes?  On my laptop, right now without any wakeup-capable USB
> devices attached, the appended script produces:

So for example, the PCI0 device on my Thinkpad is an ACPI wakeup device. 
Investigating the DSDT suggests that this is just a wrapper around a 
bunch of platform devices, including the ISA bridge. In this case, what 
real device should we be associating it with?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

Hi!

> This patch set is against acpi-test sysfs branch, and will duplicate several ACPI procfs functions in sysfs.
> As struct subsystem power_subsys is referred and the interface under /sys/power/ is changed by this patch series,
> I wish to receive some comments from linux-pm too.

Thanks for doing the work.

> Patch 03-05:
> 	add ACPI sleep attributes in sysfs.
> 	/proc/acpi/sleep is already deprecated by /sys/power/state.

Does that mean we drop standby (S1) capability on PCs?

						Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Saturday 06 January 2007 9:54 pm, Matthew Garrett wrote:
> On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
> 
> > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > attribute.  And that ACPI is finally going to start working with those
> > attributes ...
> 
> It's not necessarily possible to map from an ACPI object with a wakeup 
> capability to a Linux device, 

That seems singularly useless then.  If there's no such mapping, there's
really no point to the /proc/acpi/wakeup table... why not just always
enable every possible device as a wakeup source, since that information
is evidently not designed to be usable for anything?

Or are you saying that some of the entries there aren't for "devices"
per se, but for busses, bridges, and so on?  If so, that's not an issue.
At least, not until Linux has drivers for those things.


> so there's going to have to be some degree  
> of interface nastiness.

Interface, or implementation?  One expects that the interface would
be the same regardless of whether or not ACPI gets involved.


> However, some devices can be sensibly mapped,  
> and ideally those should be integrated into 
> /sys/devices/.../power/wakeup.

Yes...


> However, I'm not entirely sure /how/ that integration should happen. If 
> both the Linux driver and ACPI know how to enable wakeup for a device,
> what should writing to power/wakeup do?

Writing to power/wakeup sets the policy for that device:  should it
issue wakeup events, or not?  The answer is "yes" by default, but when
the hardware is broken, or the user doesn't want that, the policy can
be changed without a kernel recompile.

The driver stack needs to know that policy in order to act properly.

For example, USB devices should only be told to use remote wakeup if
their ancestral USB host controller is wakeup-enabled.  And when that
controller isn't wakeup-enabled, it can often enter states which save
more power.  (E.g. turn off oscillators and switch off VBUS power.)

You will notice, by the way, that the USB peripherals will never be
showing up in those ACPI tables... which is a trivial demostration
of the fact that the ACPI wakeup infrastructure is insufficient to
manage system wakeup on Linux.  That USB keyboard, or mouse, that
wakes the system does not appear in those ACPI tables.

Also, a network driver needs to know that it should configure WOL, and
in this mode not that one, etc.

I'd expect drivers and ACPI to cooperate more or less by having the
driver do the standard stuff (like enabling PCI PME#, and enabling
wakeup irqs)), and ACPI not being driver-visible while it does
whatever it must to make those driver directions actually work.


> > > 	So /proc/acpi/wakeup is deprecated by
> > > 	/sys/devices/acpi_system/.../xxx/sleep_state && wakeup. 
> > 
> > Why is ACPI still not coupling such information to the REAL device
> > nodes?  On my laptop, right now without any wakeup-capable USB
> > devices attached, the appended script produces:
> 
> So for example, the PCI0 device on my Thinkpad is an ACPI wakeup device. 
> Investigating the DSDT suggests that this is just a wrapper around a 
> bunch of platform devices, including the ISA bridge. In this case, what 
> real device should we be associating it with?

I'd guess the root bridge... I have a desktop that seems to have the
same structure.  The PS2K and PS2M devices have separate entries in
/proc/acpi/wakeup but the DSDT for PCI0 also talks about them.  A
quick look suggests to me that /proc/acpi/wakeup is discarding the
device tree internal to ACPI ... _SB_.PCI0.SBRG.PS2K._PRW gets
morphed to "PS2K" and discards the PCI0 parentage.

On the other hand, I think that particular ACPI table must have a
habit of being flakey.  I have one machine that claims to have four
different USB host adapters, where the silicon only has three; and
what I'm assuming is a firewire device (S139), where the silicon
most certainly does not have one of those.  And another machine
lists an MMCI (MMC/SD?) that certainly does not exist ...

So it may well be that doing the work to connect those ACPI tables
to the system hardware will let Linux discard all the bogus data,
so it can work better.  :)

- Dave

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Zhang Rui]

On Sun, 2007-01-07 at 05:54 +0000, Matthew Garrett wrote:
> On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
> 
> > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > attribute.  And that ACPI is finally going to start working with those
> > attributes ...
> 
> It's not necessarily possible to map from an ACPI object with a wakeup 
> capability to a Linux device, so there's going to have to be some degree 
> of interface nastiness. However, some devices can be sensibly mapped, 
> and ideally those should be integrated into 
> /sys/devices/.../power/wakeup.
I do want to integrate this ACPI sleep wakeup attribute
into /sys/devices/.../power/wakeup.
But this needs some changes in driver core to make ACPI work properly.
And this will be done in further patches.

I think I forgot some introductions about the background of this patch
set in [PATCH 0/6].

This patch set is against acpi-test sysfs branch which already converts
ACPI to follow driver model. Now the ACPI procfs functions are
duplicated in sysfs step by step. And I want the ACPI interface in sysfs
works exactly the same way as in procfs.

So, currently I don't want too many parts are involved until this branch
is proved to work stable. Or else, you know, it would be painful to dig
out what the problem is if something breaks. 

BTW: it's true that the "alarm" can not handle multiple RTCs though it
works in the same way as /proc/acpi/alarm. But
if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
David's patches are merged. :)

Thanks,
Rui

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

On Sun 2007-01-07 19:31:19, David Brownell wrote:
> On Saturday 06 January 2007 9:54 pm, Matthew Garrett wrote:
> > On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
> > 
> > > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > > attribute.  And that ACPI is finally going to start working with those
> > > attributes ...
> > 
> > It's not necessarily possible to map from an ACPI object with a wakeup 
> > capability to a Linux device, 
> 
> That seems singularly useless then.  If there's no such mapping, there's
> really no point to the /proc/acpi/wakeup table... why not just always
> enable every possible device as a wakeup source, since that information
> is evidently not designed to be usable for anything?

If that's the case, please keep the interface in /proc. One useless
interface is bad... two of them ... :-).

Anyway yes it can be usefull for debugging unexpected machine
resumes. /proc/acpi/wakeup names are still _somehow_ human readable,
so it is useful for debugging.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

Hi!

> This patch set is against acpi-test sysfs branch which already converts
> ACPI to follow driver model. Now the ACPI procfs functions are
> duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> works exactly the same way as in procfs.

No, you can't port same broken interface into sysfs. Some /proc
interfaces are horrible, and we do not want to create _exactly same_
horrible interfaces in /sys.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Monday 08 January 2007 3:40 am, Zhang Rui wrote:
>
> if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
> and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
> David's patches are merged. :)

One help there would be someone from the ACPI team signing off on
patch #3 of the series I sent, which teaches ACPI how to export the
extra registers to the rtc-cmos driver.

There will be another ACPI patch at some point, actually kicking
in hooks needed to handle system wakeup, but getting the PC into
the RTC class framework is an important first step.

Once there's a proper replacement for /proc/acpi/alarm it becomes
a candidate for removal.  Maybe sooner rather than later, unless
some users for that old file turn up...

- Dave

Re: [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Zhang Rui]

> Patch 01:
> 	add a Kconfig option which is used to make ACPI procfs interface configurable.
> 	This will be used by all the following sysfs conversion patches.
> 
> Patch 02:
> 	add ACPI debug attribute in sysfs.
> 	By applying this patch, /proc/acpi/debug_layer && debug_level is deprecated by
> 	/sys/module/acpi/parameter/debug_layer && debug_level.
> 
> Patch 03-05:
> 	add ACPI sleep attributes in sysfs.
> 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> 	/proc/acpi/alarm is deprecated by /sys/power/alarm.
> 	For those devices that support "wake" attribute, two files, "sleep_state" and "wakeup", are created for these devices.
> 	"sleep_state" indicates the lowest sleeping state that can be entered while still providing wake functionality.
> 	"wakeup" can be used to enable/disable the device's ability to wake a sleeping system.
> 	So /proc/acpi/wakeup is deprecated by /sys/devices/acpi_system/.../xxx/sleep_state && wakeup.
> 
Len,
Now, I'm thinking of dropping patch 03-05.
"alarm" is ACPI specific and /sys/power/alarm is not a good idea.
In addition, it can't handle multiple RTCs as David described.
So, if the new rtc-cmos driver written by David works well,
this's not needed any more. :)

"wakeup" attribute for ACPI wakeup devices is in the wish list.
	1. Try to map ACPI devices to the physical devices.
	   It's not very easy, as we can not find a generic method to
	   map ACPI wakeup devices to physical devices. So I have to
	   divide them into several groups, e.g. PCI, legacy serial,
	   legacy PS2, etc. And verify which group the ACPI device 
	   belongs to.
	2. add "wakeup" properly to /sys/device/(not ACPI)/...
	   I'll investigate the possibility of integrating this one into
	   /sys/device/.../power/wakeup.
	3. consolidate all wakeup devices in one place for convenience.
	   E.g. /sys/power/wakeup/, symbolic links with useful names.
	   (note that links here are from "real" devices node in sysfs,
	   so it's a generic interface for systems both w/ and w/o ACPI)
	4. remove /proc/acpi/wakeup,
	   since it's replaced by /sys/power/wakeup/...
> Patch 06:
> 	add ACPI info in sysfs which indicates ACPICA version.
> 	/sys/firmware/acpi/info is create and /proc/acpi/info is marked as deprecated.
I'll refresh the patch 01,02,06 and resend them.
Thanks for your comments, David, Matthew, Pavel, Randy and Suietov. :)

[PATCH 0/3] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Zhang Rui]

This patch set is against acpi-test sysfs branch,
and will duplicate several ACPI procfs functions in sysfs.

Patch 01:
add a Kconfig option to make ACPI procfs configurable.
This will be used by all the following sysfs conversion patches.

Patch 02:
add ACPI debug attribute in sysfs.
/proc/acpi/debug_layer && debug_level is deprecated by
/sys/module/acpi/parameter/debug_layer && debug_level.

Patch 03:
add ACPICA version in sysfs.
/proc/acpi/info is deprecated by /sys/firmware/acpi/version.

Wish list:

Sysfs interfaces for all the ACPI tables, like the multiple ssdts and
dynamic loaded ssdts, which are likely to be listed under
/sys/firmware/acpi/tables/...

"wakeup" attribute for ACPI wakeup devices.
        1. Try to map ACPI devices to the physical devices.
           It's not very easy, as we can not find a generic method to
           map ACPI wakeup devices to physical devices. So I have to
           divide them into several groups, e.g. PCI, legacy serial,
           legacy PS2, etc. And verify which group the ACPI device 
           belongs to.
        2. add "wakeup" properly to /sys/device/(not ACPI)/...
           I'll investigate the possibility of integrating this one into
           /sys/device/.../power/wakeup.
        3. consolidate all wakeup devices in one place for convenience.
           E.g. /sys/power/wakeup/, symbolic links with useful names.
           (note that links here are from "real" devices node in sysfs,
           so it's a generic interface for systems both w/ and w/o ACPI)
        4. remove /proc/acpi/wakeup,
           since it's replaced by /sys/power/wakeup/...

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

> > Patch 03-05:
> > 	add ACPI sleep attributes in sysfs.
> > 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> 
> Does that mean we drop standby (S1) capability on PCs?

I think we need to make /sys/power/state handle S1.

There are two cases

1. Platform supports S1, but does not support S3.

This is more common.  You see this a lot on server-class machines.

We could make "mem" simply mean S1 here b/c it is effectively
the closest thing to S3.

2. Platform supports both S1 and S3.

This is pretty rare -- at least on the systems I've got.
I'd  like the generic interface be able to describe and handle this case.

I'm open to suggestions on what to call S1 if it isn't called "mem".

-Len

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

On Monday 08 January 2007 08:13, Pavel Machek wrote:
> Hi!
> 
> > This patch set is against acpi-test sysfs branch which already converts
> > ACPI to follow driver model. Now the ACPI procfs functions are
> > duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> > works exactly the same way as in procfs.
> 
> No, you can't port same broken interface into sysfs. Some /proc
> interfaces are horrible, and we do not want to create _exactly same_
> horrible interfaces in /sys.

Please be specific.

thanks,
-Len

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Nigel Cunningham]

Hi.

On Wed, 2007-01-24 at 21:03 -0500, Len Brown wrote:
> > > Patch 03-05:
> > > 	add ACPI sleep attributes in sysfs.
> > > 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> > 
> > Does that mean we drop standby (S1) capability on PCs?
> 
> I think we need to make /sys/power/state handle S1.
> 
> There are two cases
> 
> 1. Platform supports S1, but does not support S3.
> 
> This is more common.  You see this a lot on server-class machines.
> 
> We could make "mem" simply mean S1 here b/c it is effectively
> the closest thing to S3.
> 
> 2. Platform supports both S1 and S3.
> 
> This is pretty rare -- at least on the systems I've got.
> I'd  like the generic interface be able to describe and handle this case.
> 
> I'm open to suggestions on what to call S1 if it isn't called "mem".

'standby'? That's what occurs to me from previous M$ usage.

Regards,

Nigel

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

Thanks for your detailed reply, David..

> Third, stuff in /sys/power should be generic, and not depend on ACPI
> infrastructure or models ... it should for example work for embedded
> platforms where Linux runs on the bare metal.  Moreover, in general
> an ACPI-specific interface should be the very last (and non-portable,
> worst) choice, not the first/default/preferred one.

Agreed.

> Which means in particular that:
> 
> > Patch 03-05:
> > 	add ACPI sleep attributes in sysfs.
> > 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> > 	/proc/acpi/alarm is deprecated by /sys/power/alarm.
> 
> A /sys/power/alarm thing conflicts with ongoing RTC framework work.
> 
> You may have missed the patches I've sent making RTCs be "just another
> wakeup-capable device" -- an interface that already works with multiple
> RTCs, is not in the least bit coupled to ACPI, and is on track to work
> with on more platforms -- or the proposal to provide sysfs support for
> activiting alarms within the RTC framework.
> 
> The latest patches relevant to the RTC used by ACPI are:
> 
>  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802017116195&w=2
>  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044406838&w=2
>  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044531547&w=2
>  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044532646&w=2
> 
> (Only that last one touches ACPI directly.)

This looks promising, thanks.
 
> Note that like it says in the first message, this version doesn't
> have the "remove /proc/acpi/alarm" stuff, mostly to simplify merging
> of the core driver code; that will be done later, and in any case the
> old drivers/char/rtc.c code didn't interact with it either.  It worked
> in earlier versions of the patch.  (Modulo the fact that ACPI wakeup
> from STR seems to usually be a total lose.)  One such version:
> 
>  http://marc.theaimsgroup.com/?l=linux-kernel&m=116406177605472&w=2
> 
> You'll observe those ACPI bits are kind of messy.  The clean
> approach I have in mind is to have callbacks in platform_data,
> with which ACPI -- or EFI etc -- can do whatever nastiness it
> needs to let the RTC alarm trigger wakeup from system sleep state.
> A "bare metal" platform would just enable_irq_wake(); ACPI would
> set a magic PM1 bit or whatever; etc.
> 
> (In terms of userspace tools, I posted an "rtcwake.c" tool working
> on several platforms, including x86 PCs with the above patch plus
> some ARM systems, notably AT91rm9200, with rtc wakeup irqs.)
> 
> 
> > 	For those devices that support "wake" attribute,
> 
> Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> attribute.  And that ACPI is finally going to start working with those
> attributes ...
> 
> 
> > 	two files, 
> > 	"sleep_state" and "wakeup", are created for these devices. 
> 
> I'm going to be assuming your "wakeup" attribute has the same semantics
> as that existing one.  If it doesn't, you should either fix your model,
> or justify changing the Linux-wide model.

The Linux-wide model needs some work.

First, wakeup appears under devices that don't know or care about wakeup.
Second, it doesn't tell the user when it is useful -- which is what Rui
tried to address with sleep_state below.
Third, it doesn't tell you if it is already enabled or not.
 
> As for sleep_state:
> 
> > 	"sleep_state" indicates the lowest sleeping state that can be
> > 	entered while still providing wake functionality. 
> 
> I understand that /proc/acpi/wakeup exposes this information.  I don't
> understand how userspace is expected to use it.  Or, for that matter,
> how this model ought to work on non-ACPI systems.  But most especially,
> if it's useful, I don't understand why it would be ACPI-only.

Agreed that the user shouldn't know that it is ACPI only, but it may be that
only ACPI systems have this concept.

We've seen this in practice.  For example some wakeup devices
work only down to S4.  When STD used S5 instead of S4, these
wakeup devices were unavailable.
 
> (Yes, there are huge gaps in Linux-PM wakeup support.  Weak ACPI suppport
> for it, especially from STR -- without swsusp -- is a big factor.  I
> was pleased to see RTC wakeup from ACPI S4 actually work ... first time
> I've ever seen ACPI wakeup ever work correctly.)

Try your power button, sleep button, or lid switch.

> > 	"wakeup" can be used to enable/disable the device's
> > 	ability to wake a sleeping system. 
> 
> We've found a need to nuance that a bit.  So for example a USB root
> hub sure ought to support the USB "remote wakeup" mechanism in that
> way, and by and large the BIOS will declare that it does.  (Not that
> I've ever observed that to work from ACPI STR, mind you!!)
> 
> However, it appears out that on some boards remote wakeup doesn't
> work right ... either there's a chipset bug, or some board wiring
> problem, or something of that ilk.  This impacts _runtime_ power
> management as well as system-wide sleep states.  So "wakeup" also
> gets used to disable runtime PM techniques like suspending USB
> devices to reduce system power drain (since that relies on remote
> wakeup).  The hardware mechanism isn't used only to wake sleeping
> systems; so the sysfs attribute isn't limited to that role either.

I think it is a mistake to overload what wakeup does.
It should enable system wakeup capability, and nothing else.

cheers,
-Len

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

On Sunday 07 January 2007 00:54, Matthew Garrett wrote:
> On Sat, Jan 06, 2007 at 02:21:41PM -0800, David Brownell wrote:
> 
> > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > attribute.  And that ACPI is finally going to start working with those
> > attributes ...

I agree that must be the goal.

> It's not necessarily possible to map from an ACPI object with a wakeup 
> capability to a Linux device, so there's going to have to be some degree 
> of interface nastiness. However, some devices can be sensibly mapped, 
> and ideally those should be integrated into 
> /sys/devices/.../power/wakeup.

True.  Some ACPI "devices" don't exist except for in ACPI mode.
Rui exposed them in some earlier patches in the sysfs patch series
which are now in -mm via git-acpi.patch.

> However, I'm not entirely sure /how/ that integration should happen. If 
> both the Linux driver and ACPI know how to enable wakeup for a device, 
> what should writing to power/wakeup do?
> 
> > > 	So /proc/acpi/wakeup is deprecated by
> > > 	/sys/devices/acpi_system/.../xxx/sleep_state && wakeup. 
> > 
> > Why is ACPI still not coupling such information to the REAL device
> > nodes?  On my laptop, right now without any wakeup-capable USB
> > devices attached, the appended script produces:
> 
> So for example, the PCI0 device on my Thinkpad is an ACPI wakeup device. 
> Investigating the DSDT suggests that this is just a wrapper around a 
> bunch of platform devices, including the ISA bridge. In this case, what 
> real device should we be associating it with?

yeah, we'll have to figure out what that really means.

thanks,
-Len

Re: [PATCH 0/3] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

On Sunday 21 January 2007 00:48, Zhang Rui wrote:
> This patch set is against acpi-test sysfs branch,
> and will duplicate several ACPI procfs functions in sysfs.
> 
> Patch 01:
> add a Kconfig option to make ACPI procfs configurable.
> This will be used by all the following sysfs conversion patches.

add to feature-removal-schedule-txt
Make it July '07

> Patch 02:
> add ACPI debug attribute in sysfs.
> /proc/acpi/debug_layer && debug_level is deprecated by
> /sys/module/acpi/parameter/debug_layer && debug_level.

I don't think we need feature-removal-schedule-txt since
this is just a debug hook -- can do this right away.

> Patch 03:
> add ACPICA version in sysfs.
> /proc/acpi/info is deprecated by /sys/firmware/acpi/version.

make modparam
 
> Wish list:
> 
> Sysfs interfaces for all the ACPI tables, like the multiple ssdts and
> dynamic loaded ssdts, which are likely to be listed under
> /sys/firmware/acpi/tables/...

agreed.
 
> "wakeup" attribute for ACPI wakeup devices.

first we should nuke the generic wakeup file under devices where
it has no function.

second, the generic wakeup file doesn't give the user any indication
of when it will work.  ie. will it work in S5, or just in S4?
Also, it doesn't give any feedback to show if it is enabled or not.

>         1. Try to map ACPI devices to the physical devices.
>            It's not very easy, as we can not find a generic method to
>            map ACPI wakeup devices to physical devices. So I have to
>            divide them into several groups, e.g. PCI, legacy serial,
>            legacy PS2, etc. And verify which group the ACPI device 
>            belongs to.

Agreed.
PCI is easy, the others may be harder.

>         2. add "wakeup" properly to /sys/device/(not ACPI)/...
>            I'll investigate the possibility of integrating this one into
>            /sys/device/.../power/wakeup.

Agreed.
at the end of the day, we need a single generic wakeup file.
whether the functionality is supplied by ACPI or not should
not be visible to the user.

>         3. consolidate all wakeup devices in one place for convenience.
>            E.g. /sys/power/wakeup/, symbolic links with useful names.
>            (note that links here are from "real" devices node in sysfs,
>            so it's a generic interface for systems both w/ and w/o ACPI)

I think this would be really really useful for user-space --
but then I don't write the utilities, so somebody from that space
might want to weigh in.

>         4. remove /proc/acpi/wakeup,
>            since it's replaced by /sys/power/wakeup/...
> 

thanks,
-Len

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

On Sunday 07 January 2007 22:31, David Brownell wrote:

> > However, I'm not entirely sure /how/ that integration should happen. If 
> > both the Linux driver and ACPI know how to enable wakeup for a device,
> > what should writing to power/wakeup do?

If a native hardware device driver knows how to talk to the device,
then it should win, and ACPI should lose.

ACPI, after all, is intended to fill in the missing gaps in native hardware drivers.

> Writing to power/wakeup sets the policy for that device:  should it
> issue wakeup events, or not?  The answer is "yes" by default, but when
> the hardware is broken, or the user doesn't want that, the policy can
> be changed without a kernel recompile.

For ACPI wakeup devices, the default is "no", except IIR for the power button.

> The driver stack needs to know that policy in order to act properly.
> 
> For example, USB devices should only be told to use remote wakeup if
> their ancestral USB host controller is wakeup-enabled.  And when that
> controller isn't wakeup-enabled, it can often enter states which save
> more power.  (E.g. turn off oscillators and switch off VBUS power.)
> 
> You will notice, by the way, that the USB peripherals will never be
> showing up in those ACPI tables... which is a trivial demostration
> of the fact that the ACPI wakeup infrastructure is insufficient to
> manage system wakeup on Linux.  That USB keyboard, or mouse, that
> wakes the system does not appear in those ACPI tables.

Oh?

> Also, a network driver needs to know that it should configure WOL, and
> in this mode not that one, etc.
> 
> I'd expect drivers and ACPI to cooperate more or less by having the
> driver do the standard stuff (like enabling PCI PME#, and enabling
> wakeup irqs)), and ACPI not being driver-visible while it does
> whatever it must to make those driver directions actually work.
> 
> 
> > > > 	So /proc/acpi/wakeup is deprecated by
> > > > 	/sys/devices/acpi_system/.../xxx/sleep_state && wakeup. 
> > > 
> > > Why is ACPI still not coupling such information to the REAL device
> > > nodes?  On my laptop, right now without any wakeup-capable USB
> > > devices attached, the appended script produces:
> > 
> > So for example, the PCI0 device on my Thinkpad is an ACPI wakeup device. 
> > Investigating the DSDT suggests that this is just a wrapper around a 
> > bunch of platform devices, including the ISA bridge. In this case, what 
> > real device should we be associating it with?
> 
> I'd guess the root bridge... I have a desktop that seems to have the
> same structure.  The PS2K and PS2M devices have separate entries in
> /proc/acpi/wakeup but the DSDT for PCI0 also talks about them.  A
> quick look suggests to me that /proc/acpi/wakeup is discarding the
> device tree internal to ACPI ... _SB_.PCI0.SBRG.PS2K._PRW gets
> morphed to "PS2K" and discards the PCI0 parentage.
> 
> On the other hand, I think that particular ACPI table must have a
> habit of being flakey.  I have one machine that claims to have four
> different USB host adapters, where the silicon only has three; and
> what I'm assuming is a firewire device (S139), where the silicon
> most certainly does not have one of those.  And another machine
> lists an MMCI (MMC/SD?) that certainly does not exist ...

The DSDT is whatever the BIOS writer typed in.
We've seen many times that for a new machine they start
with the DSDT for an old machine and modify it until
Windows boots, then claim victory and go home:-)

> So it may well be that doing the work to connect those ACPI tables
> to the system hardware will let Linux discard all the bogus data,
> so it can work better.  :)

Agreed.

-Len

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Len Brown]

On Wednesday 10 January 2007 15:53, David Brownell wrote:
> On Monday 08 January 2007 3:40 am, Zhang Rui wrote:
> >
> > if /sys/class/rtc/rtcN/alarm can provide the same function, it's great
> > and I'll drop patch#03. I'll also mark /proc/acpi/alarm as deprecated if
> > David's patches are merged. :)
> 
> One help there would be someone from the ACPI team signing off on
> patch #3 of the series I sent, which teaches ACPI how to export the
> extra registers to the rtc-cmos driver.

done.

> There will be another ACPI patch at some point, actually kicking
> in hooks needed to handle system wakeup, but getting the PC into
> the RTC class framework is an important first step.
> 
> Once there's a proper replacement for /proc/acpi/alarm it becomes
> a candidate for removal.  Maybe sooner rather than later, unless
> some users for that old file turn up...

Sometimes that file's syntax is useful -- wake up at 7:00,
but those testing suspend-resume want to wake up 1 minute in the future
now mater what time it is...

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Matthew Garrett]

On Wed, Jan 24, 2007 at 11:14:22PM -0500, Len Brown wrote:
> On Sunday 07 January 2007 22:31, David Brownell wrote:
> 
> > > However, I'm not entirely sure /how/ that integration should happen. If 
> > > both the Linux driver and ACPI know how to enable wakeup for a device,
> > > what should writing to power/wakeup do?
> 
> If a native hardware device driver knows how to talk to the device,
> then it should win, and ACPI should lose.

My concern is that there may be cases where the ACPI wakeup code 
interacts with the platform in a way that the Linux code doesn't, which 
may be somehow necessary. I've no evidence that this is ever something 
that would actually be an issue, but on the other hand, this is ACPI...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Rafael J. Wysocki]

Hi,

On Thursday, 25 January 2007 03:52, Nigel Cunningham wrote:
> Hi.
> 
> On Wed, 2007-01-24 at 21:03 -0500, Len Brown wrote:
> > > > Patch 03-05:
> > > > 	add ACPI sleep attributes in sysfs.
> > > > 	/proc/acpi/sleep is already deprecated by /sys/power/state.
> > > 
> > > Does that mean we drop standby (S1) capability on PCs?
> > 
> > I think we need to make /sys/power/state handle S1.
> > 
> > There are two cases
> > 
> > 1. Platform supports S1, but does not support S3.
> > 
> > This is more common.  You see this a lot on server-class machines.
> > 
> > We could make "mem" simply mean S1 here b/c it is effectively
> > the closest thing to S3.
> > 
> > 2. Platform supports both S1 and S3.
> > 
> > This is pretty rare -- at least on the systems I've got.
> > I'd  like the generic interface be able to describe and handle this case.
> > 
> > I'm open to suggestions on what to call S1 if it isn't called "mem".
> 
> 'standby'? That's what occurs to me from previous M$ usage.

Yes, something like that, I think..

Greetings,
Rafael

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Wednesday 24 January 2007 8:14 pm, Len Brown wrote:
> On Sunday 07 January 2007 22:31, David Brownell wrote:
> 
> > > However, I'm not entirely sure /how/ that integration should happen. If 
> > > both the Linux driver and ACPI know how to enable wakeup for a device,
> > > what should writing to power/wakeup do?
> 
> If a native hardware device driver knows how to talk to the device,
> then it should win, and ACPI should lose.
> 
> ACPI, after all, is intended to fill in the missing gaps in native
> hardware drivers. 

It goes a bit beyond that however.  It goes and defines GPEs that
could be managed by embedded firmware, which may interact with things
like PCI PME# while the ACPI host system is shut down deeply enough
that it can't be woken up that way.  (At least, by my non-expert
reading of bits'n'pieces of the ACPI spec.)

Which implies that if for example a device driver enables PME#, then
ACPI glue may need to notice that and activate an associated GPE ...
or, alternatively, that ACPI may need to check the same flag that the
driver checks.

It's reasonable IMO to expect a PCI driver to know about PCI PM, and
to have it check a simple policy flag.  It's _not_ reasonable that it
ought to understand anything about ACPI, since PCI itself does not
depend on ACPI.


> > Writing to power/wakeup sets the policy for that device:  should it
> > issue wakeup events, or not?  The answer is "yes" by default, but when
> > the hardware is broken, or the user doesn't want that, the policy can
> > be changed without a kernel recompile.
> 
> For ACPI wakeup devices, the default is "no", except IIR for the power button.

Annoying but fixable in userspace.   Got any insights into why that
default is "system acts like <x> doesn't work"?  Given how rarely
defaults get changed (and why: "doesn't work that way"), that's more
or less a "wakeup does not work with ACPI" policy.

 
> > The driver stack needs to know that policy in order to act properly.
> > 
> > For example, USB devices should only be told to use remote wakeup if
> > their ancestral USB host controller is wakeup-enabled.  And when that
> > controller isn't wakeup-enabled, it can often enter states which save
> > more power.  (E.g. turn off oscillators and switch off VBUS power.)
> > 
> > You will notice, by the way, that the USB peripherals will never be
> > showing up in those ACPI tables... which is a trivial demostration
> > of the fact that the ACPI wakeup infrastructure is insufficient to
> > manage system wakeup on Linux.  That USB keyboard, or mouse, that
> > wakes the system does not appear in those ACPI tables.
> 
> Oh?

Yes, of course.  How could the BIOS vendor possibly know what wakeup-capable
USB devices the end user is going to hook up ... so that it can stick them
into a *static* table?  And there are certainly no hooks through which the
ACPI system learns about the USB devices that get hotplugged.  The same
issue comes up with CardBus/PCI devices, though it's been so long since I
used one of those that I don't know if they tend to even support PCI PME#
wakeup event sources.

In a not-dissimilar vein, it doesn't seem to notice if I removed the modem
card from its AMR, CNR, or ACR slot ... /proc/acpi/wakeup still lists "MDM"
in such cases, when wake-on-ring clearly couldn't work any more.


> > On the other hand, I think that particular ACPI table must have a
> > habit of being flakey.  I have one machine that claims to have four
> > different USB host adapters, where the silicon only has three; and
> > what I'm assuming is a firewire device (S139), where the silicon
> > most certainly does not have one of those.  And another machine
> > lists an MMCI (MMC/SD?) that certainly does not exist ...
> 
> The DSDT is whatever the BIOS writer typed in.
> We've seen many times that for a new machine they start
> with the DSDT for an old machine and modify it until
> Windows boots, then claim victory and go home:-)

I had suspected that was the engineering "process" in use.

That's sometimes called "cut'n'paste".  I don't think that it
has a very good assurance rating from the folk evaluating
such processes.  ;)


> > So it may well be that doing the work to connect those ACPI tables
> > to the system hardware will let Linux discard all the bogus data,
> > so it can work better.  :)
> 
> Agreed.

Looking forward to patches someday.  :)

- Dave

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Wednesday 24 January 2007 7:28 pm, Len Brown wrote:
> > 
> > The latest patches relevant to the RTC used by ACPI are:
> > 
> >  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802017116195&w=2
> >  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044406838&w=2
> >  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044531547&w=2
> >  http://marc.theaimsgroup.com/?l=linux-kernel&m=116802044532646&w=2
> > 
> > (Only that last one touches ACPI directly.)
> 
> This looks promising, thanks.

And I see you've acked that last one now, thanks.  A patch to provide
system-specific callbacks during suspend/resume can now be on the way,
when I make time for it.  The ACPI version of that callback would mirror
the magic now done with /proc/acpi/wakeup, supporting both implementation
options for RTC wakeup.


> > > 	For those devices that support "wake" attribute,
> > 
> > Please tell me you mean "devices with a /sys/devices/.../power/wakeup"
> > attribute.  And that ACPI is finally going to start working with those
> > attributes ...
> > 
> > 
> > > 	two files, 
> > > 	"sleep_state" and "wakeup", are created for these devices. 
> > 
> > I'm going to be assuming your "wakeup" attribute has the same semantics
> > as that existing one.  If it doesn't, you should either fix your model,
> > or justify changing the Linux-wide model.
> 
> The Linux-wide model needs some work.
> 
> First, wakeup appears under devices that don't know or care about wakeup.

As an empty value.  It's sort of problematic to claim that a device
doesn't know or care ... consider a USB device, where the capability
is configuration-specific and is accordingly irrelevant when it's in a
configuration that doesn't support wakeup (or unconfigured).  Plus there
is the issue that it's in a sysfs "group", which doesn't have selectivity
about what attributes exist (or don't) ... or that driverless devices
are generally incapable of supporting wakeup.


> Second, it doesn't tell the user when it is useful -- which is what Rui
> tried to address with sleep_state below.

Nobody yet responded to my counter argument/questions on that claim...


> Third, it doesn't tell you if it is already enabled or not.

Erm, it most certainly does.  The values are null, "disabled", "enabled".

  
> > As for sleep_state:
> > 
> > > 	"sleep_state" indicates the lowest sleeping state that can be
> > > 	entered while still providing wake functionality. 
> > 
> > I understand that /proc/acpi/wakeup exposes this information.  I don't
> > understand how userspace is expected to use it.  Or, for that matter,
> > how this model ought to work on non-ACPI systems.  But most especially,
> > if it's useful, I don't understand why it would be ACPI-only.
> 
> Agreed that the user shouldn't know that it is ACPI only, but it may be that
> only ACPI systems have this concept.

No, it's pretty common that systems support sleep states that don't
provide things certain devices need to serve as wakeup devices.

One example would be a UART clock ... 115200x16 (=1843200) Hz unavailable
if the system's slow clock mode is 32 KHz.  Another would be the USB
clock, often 48 MHz.  (I think a lot of systems can actually detect
the resume signaling, but just can't get their oscillator and/or PLLs
working properly within the 10 msec allowed by USB.)

 
> We've seen this in practice.  For example some wakeup devices
> work only down to S4.  When STD used S5 instead of S4, these
> wakeup devices were unavailable.

Repeating the question:  how is userspace expected to use this?

It doesn't use the information in its /proc/acpi/wakeup form,
so why would that change in a sysfs form?  (Assuming ACPI wakeup
from S3 or S1 works correctly, which is vanishingly rare in my
own experience ...)

Plus, drivers no longer have a standard way to tell anything
about the target system state ... like whether it's an ACPI
S1, S3, S4, or S5; or whether it's even an ACPI state at all...

  
> > (Yes, there are huge gaps in Linux-PM wakeup support.  Weak ACPI suppport
> > for it, especially from STR -- without swsusp -- is a big factor.  I
> > was pleased to see RTC wakeup from ACPI S4 actually work ... first time
> > I've ever seen ACPI wakeup ever work correctly.)
> 
> Try your power button, sleep button, or lid switch.

I was thinking about stuff listed in /proc/acpi/wakeup, since
that's the specific issue being discussed here ... and yes, it's
after having enabled those devices using that file that I report
ACPI wakeup not working correctly.

 
> > > 	"wakeup" can be used to enable/disable the device's
> > > 	ability to wake a sleeping system. 
> > 
> > We've found a need to nuance that a bit.  So for example a USB root
> > hub sure ought to support the USB "remote wakeup" mechanism in that
> > way, and by and large the BIOS will declare that it does.  (Not that
> > I've ever observed that to work from ACPI STR, mind you!!)
> > 
> > However, it appears out that on some boards remote wakeup doesn't
> > work right ... either there's a chipset bug, or some board wiring
> > problem, or something of that ilk.  This impacts _runtime_ power
> > management as well as system-wide sleep states.  So "wakeup" also
> > gets used to disable runtime PM techniques like suspending USB
> > devices to reduce system power drain (since that relies on remote
> > wakeup).  The hardware mechanism isn't used only to wake sleeping
> > systems; so the sysfs attribute isn't limited to that role either.
> 
> I think it is a mistake to overload what wakeup does.

I don't follow.  Are you saying that wakeup from device runtime sleep
states is something different than wakeup from system sleep states,
even when it uses the **SAME** hardware mechanisms to achieve its goal?

Hardware docs I've seen (including things like RTL specs) don't make
those kinds of distinction about the context of the wakeup event.  So
I don't see why Linux should.


> It should enable system wakeup capability, and nothing else.

Considering that the driver and hardware action is often the same both for
device runtime sleep states, and for system sleep states, I don't see why...

- Dave

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

> > > I think we need to make /sys/power/state handle S1.
> > > 
> > > There are two cases
> > > 
> > > 1. Platform supports S1, but does not support S3.
> > > 
> > > This is more common.  You see this a lot on server-class machines.
> > > 
> > > We could make "mem" simply mean S1 here b/c it is effectively
> > > the closest thing to S3.

Today, this system would list "standby" in /sys/power/state,
but not "mem".  I have a system like that here ...


> > > 2. Platform supports both S1 and S3.
> > > 
> > > This is pretty rare -- at least on the systems I've got.
> > > I'd  like the generic interface be able to describe and handle this case.

Today, this system would list both "standby" and "mem"
in /sys/power/state.  I have a system like that here ...


      3. (ACPI) platform supports S3 but not S1

Today, this system would list "mem" in /sys/power/state,
but not "standby".  I have a system like that here ...



> > > I'm open to suggestions on what to call S1 if it isn't called "mem".
> > 
> > 'standby'? That's what occurs to me from previous M$ usage.
> 
> Yes, something like that, I think..

Good news ... it already works that way!!!  :)

- Dave

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

On Wed 2007-01-24 21:28:13, Len Brown wrote:
> On Monday 08 January 2007 08:13, Pavel Machek wrote:
> > Hi!
> > 
> > > This patch set is against acpi-test sysfs branch which already converts
> > > ACPI to follow driver model. Now the ACPI procfs functions are
> > > duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> > > works exactly the same way as in procfs.
> > 
> > No, you can't port same broken interface into sysfs. Some /proc
> > interfaces are horrible, and we do not want to create _exactly same_
> > horrible interfaces in /sys.
> 
> Please be specific.

/proc/acpi/alarm is horrible mess, as was detailed in another email
from David.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

Hi!

> > There will be another ACPI patch at some point, actually kicking
> > in hooks needed to handle system wakeup, but getting the PC into
> > the RTC class framework is an important first step.
> > 
> > Once there's a proper replacement for /proc/acpi/alarm it becomes
> > a candidate for removal.  Maybe sooner rather than later, unless
> > some users for that old file turn up...
> 
> Sometimes that file's syntax is useful -- wake up at 7:00,
> but those testing suspend-resume want to wake up 1 minute in the future
> now mater what time it is...

Write a shell script then. "Calculating times in future is
conventient, lets hack it into kernel". OOps?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[David Brownell]

On Thursday 25 January 2007 4:08 am, Pavel Machek wrote:
> On Wed 2007-01-24 21:28:13, Len Brown wrote:
> > On Monday 08 January 2007 08:13, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > This patch set is against acpi-test sysfs branch which already converts
> > > > ACPI to follow driver model. Now the ACPI procfs functions are
> > > > duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> > > > works exactly the same way as in procfs.
> > > 
> > > No, you can't port same broken interface into sysfs. Some /proc
> > > interfaces are horrible, and we do not want to create _exactly same_
> > > horrible interfaces in /sys.
> > 
> > Please be specific.
> 
> /proc/acpi/alarm is horrible mess, as was detailed in another email

ditto /proc/acpi/wakeup, and all those empty /proc/acpi directories 

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

Hi!

> > (Yes, there are huge gaps in Linux-PM wakeup support.  Weak ACPI suppport
> > for it, especially from STR -- without swsusp -- is a big factor.  I
> > was pleased to see RTC wakeup from ACPI S4 actually work ... first time
> > I've ever seen ACPI wakeup ever work correctly.)
> 
> Try your power button, sleep button, or lid switch.

Actually, in 2.6.18-or-so, I could wake my x60 from s2ram by simply
opening the lid. New kernels do not support that. Do I need to
configure it somewhere?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Pavel Machek]

Hi!

> > > > > This patch set is against acpi-test sysfs branch which already converts
> > > > > ACPI to follow driver model. Now the ACPI procfs functions are
> > > > > duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> > > > > works exactly the same way as in procfs.
> > > > 
> > > > No, you can't port same broken interface into sysfs. Some /proc
> > > > interfaces are horrible, and we do not want to create _exactly same_
> > > > horrible interfaces in /sys.
> > > 
> > > Please be specific.
> > 
> > /proc/acpi/alarm is horrible mess, as was detailed in another email
> 
> ditto /proc/acpi/wakeup, and all those empty /proc/acpi directories 

Agreed, /proc/acpi/wakeup is unusable/strange/mess, too. I don't get
that many empty /proc/acpi directories, but I surely hope I'll not see
them in /sys.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [PATCH 0/6] [-mm]: ACPI: duplicate ACPI procfs functions in sysfs

[Zhang Rui]

On Thu, 2007-01-25 at 20:51 +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > This patch set is against acpi-test sysfs branch which already converts
> > > > > > ACPI to follow driver model. Now the ACPI procfs functions are
> > > > > > duplicated in sysfs step by step. And I want the ACPI interface in sysfs
> > > > > > works exactly the same way as in procfs.
> > > > > 
> > > > > No, you can't port same broken interface into sysfs. Some /proc
> > > > > interfaces are horrible, and we do not want to create _exactly same_
> > > > > horrible interfaces in /sys.
> > > > 
> > > > Please be specific.
> > > 
> > > /proc/acpi/alarm is horrible mess, as was detailed in another email
> > 
> > ditto /proc/acpi/wakeup, and all those empty /proc/acpi directories 
> 
> Agreed, /proc/acpi/wakeup is unusable/strange/mess, too. I don't get
> that many empty /proc/acpi directories, but I surely hope I'll not see
> them in /sys.
Many /proc/acpi/(drivers)/ may be empty,
e.g. /proc/acpi/ac, /proc/acpi/battery...
This is because that driver entry in procfs is created after driver is
successfully registered. But the actual proc interface is added when a
device is binded to the driver. So when a driver is loaded but no
matchable device is found, we'll leave an empty directory
under /proc/acpi/.
Anyway, we won't have such problems in sysfs.

Thanks,
Rui