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

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

 



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

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

  Powered by Linux