/proc/acpi/ removal plan

processor throttling state I/F
As processor T-state is used for thermal control only, processor t-state is mapped to a cooling_device's cooling_state in the generic thermal driver, combined with the processor's p-state.

# ls -l /sys/class/thermal/cooling_device0/

wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

oops, I forget to add the dynamic tables... will do it soon, :)

button sys I/F can be found at /sys/class/input/.
e.g.

# cat /sys/class/input/input*/device/hid 
LNXPWRBN
PNP0C0C

From: Len Brown [mailto:[email protected]]
Sent: Friday, September 19, 2008 12:33 AM
To: [email protected]; [email protected]; [email protected]; Zhang, Rui
Subject: Re: /proc/acpi/ removal plan

Quoted 4 lines

processor throttling state I/F
As processor T-state is used for thermal control only, processor t-state is mapped to a cooling_device's cooling_state in the generic thermal driver, combined with the processor's p-state.

Quoted 1 line

# ls -l /sys/class/thermal/cooling_device0/

When I scribble into cur_state
I do not see anything reflected in
/proc/acpi/processor/*/throttling

Also, max_state is 10, when surely my processor
has only 8 T-states.

If user-space can not provoke processor T-states via this I/F, then those using the old /proc I/F will flag it as a regression when it goes away. (even if few should ever need it)

Quoted 2 lines

wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

I thought that Rafael said the wakeup file
in the device tree was working now -- at least
for PCI devices, no?

I think the biggest problem with sysfs wakeup is that every device in the tree gets a wakeup file, even if it has no wakeup capability...

Quoted 6 lines

button sys I/F can be found at /sys/class/input/.
e.g.

# cat /sys/class/input/input*/device/hid
LNXPWRBN
PNP0C0C

The /proc files for power and sleep buttons simply told us what kind of button they were, just info, not API.

The functional one is PNP0C0D, the lid switch. It is also reflected in /sys/class/input, but I don't see a way to find from /sys the open/closed state like we have in /proc. (I ran into this when I tried to delete the button /proc I/F some time ago).

Quoted 10 lines

Quoted 6 lines

button sys I/F can be found at /sys/class/input/.
e.g.

# cat /sys/class/input/input*/device/hid
LNXPWRBN
PNP0C0C

The /proc files for power and sleep buttons simply told us what kind of button they were, just info, not API.

Quoted 6 lines

The functional one is PNP0C0D, the lid switch. It is also reflected in /sys/class/input, but I don't see a way to find from /sys the open/closed state like we have in /proc. (I ran into this when I tried to delete the button /proc I/F some time ago).

You're right. Lid device still needs such an I/F.

Quoted 11 lines

From: Len Brown [mailto:[email protected]]
Sent: Friday, September 19, 2008 12:33 AM
To: [email protected]; [email protected]; [email protected]; Zhang, Rui
Subject: Re: /proc/acpi/ removal plan

Quoted 4 lines

processor throttling state I/F
As processor T-state is used for thermal control only, processor t-state is mapped to a cooling_device's cooling_state in the generic thermal driver, combined with the processor's p-state.

Quoted 9 lines

Quoted 1 line

# ls -l /sys/class/thermal/cooling_device0/

When I scribble into cur_state
I do not see anything reflected in
/proc/acpi/processor/*/throttling

Also, max_state is 10, when surely my processor
has only 8 T-states.

the cooling state of processor is a combination of p-state and t-state.
because reducing the frequency is preferred when system is overheat.
e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.

Quoted 7 lines

If user-space can not provoke processor T-states via this I/F, then those using the old /proc I/F will flag it as a regression when it goes away. (even if few should ever need it)

Quoted 2 lines

wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

Quoted 4 lines

I thought that Rafael said the wakeup file
in the device tree was working now -- at least
for PCI devices, no?

Rafael's patch did bind the "wakeup" file together with the ACPI device. It calls the acpi_enable_wakeup_device_power of the ACPI device, but it doesn't touch the wakeup GPE at all. So, I don't think it actually works...

Quoted 5 lines

I think the biggest problem with sysfs wakeup is that every device in the tree gets a wakeup file, even if it has no wakeup capability...

that's okay.
The wakeup file return null string if it doesn't have the wakeup ability. To be honest, there is one thing that I'm still concerned about. The wakeup file is a runtime device wakeup flag rather than a system wakeup flag. i.e. "enabled" means that the device can be suspend/resumed at runtime.

It doesn't ensure that it can wakeup the system from a sleep state. If /proc/acpi/wakeup is replaced by the /sys/devices/.../wakeup, users may be confused because the device can not wakeup the system even if the wakeup file is set to "enabled".

Quoted 9 lines

Quoted 5 lines

button sys I/F can be found at /sys/class/input/.
e.g.

# cat /sys/class/input/input*/device/hid
LNXPWRBN
PNP0C0C

The /proc files for power and sleep buttons simply told us what kind of button they were, just info, not API.

Quoted 6 lines

The functional one is PNP0C0D, the lid switch. It is also reflected in /sys/class/input, but I don't see a way to find from /sys the open/closed state like we have in /proc. (I ran into this when I tried to delete the button /proc I/F some time ago).

You're right. Lid device still needs such an I/F.

Quoted 35 lines · Rui

Quoted 11 lines

From: Len Brown [mailto:[email protected]]
Sent: Friday, September 19, 2008 12:33 AM
To: [email protected]; [email protected]; [email protected]; Zhang, Rui
Subject: Re: /proc/acpi/ removal plan

Quoted 4 lines

processor throttling state I/F
As processor T-state is used for thermal control only, processor t-state is mapped to a cooling_device's cooling_state in the generic thermal driver, combined with the processor's p-state.

Quoted 9 lines

Quoted 1 line

# ls -l /sys/class/thermal/cooling_device0/

When I scribble into cur_state
I do not see anything reflected in
/proc/acpi/processor/*/throttling

Also, max_state is 10, when surely my processor
has only 8 T-states.

the cooling state of processor is a combination of p-state and t-state.
because reducing the frequency is preferred when system is overheat.
e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.

Quoted 11 lines

If user-space can not provoke processor T-states via this I/F, then those using the old /proc I/F will flag it as a regression when it goes away. (even if few should ever need it)

Quoted 2 lines

wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

I thought that Rafael said the wakeup file
in the device tree was working now -- at least
for PCI devices, no?

Quoted 3 lines

Rafael's patch did bind the "wakeup" file together with the ACPI device. It calls the acpi_enable_wakeup_device_power of the ACPI device, but it doesn't touch the wakeup GPE at all. So, I don't think it actually works...

Have you noticed that the GPEs are actually set up right before entering the sleep state? acpi_enable_wakeup_device() does that, so in fact yes, it does work.

Quoted 11 lines

Quoted 5 lines

I think the biggest problem with sysfs wakeup is that every device in the tree gets a wakeup file, even if it has no wakeup capability...

that's okay.
The wakeup file return null string if it doesn't have the wakeup ability. To be honest, there is one thing that I'm still concerned about. The wakeup file is a runtime device wakeup flag rather than a system wakeup flag. i.e. "enabled" means that the device can be suspend/resumed at runtime.

No, it is _NOT_. 'enabled' means that the device is allowed to wake up the system from a sleep state if so configured.

Quoted 4 lines

It doesn't ensure that it can wakeup the system from a sleep state. If /proc/acpi/wakeup is replaced by the /sys/devices/.../wakeup, users may be confused because the device can not wakeup the system even if the wakeup file is set to "enabled".

That is actually true, but OTOH there's no any 'binary' interface that can be used for that, because for example network adapters can wake-up the system in many different situations (ie. they can react to many different types of packets).

To avoid the confusion, I started to change the wake-on-LAN ioctls of network adapters so that they update the 'wakeup' flag whey the device is set up to wake up.

Quoted 40 lines · Rafael J. Wysocki

Quoted 38 lines · Rui

Quoted 11 lines

From: Len Brown [mailto:[email protected]]
Sent: Friday, September 19, 2008 12:33 AM
To: [email protected]; [email protected]; [email protected]; Zhang, Rui
Subject: Re: /proc/acpi/ removal plan

Quoted 4 lines

processor throttling state I/F
As processor T-state is used for thermal control only, processor t-state is mapped to a cooling_device's cooling_state in the generic thermal driver, combined with the processor's p-state.

Quoted 9 lines

Quoted 1 line

# ls -l /sys/class/thermal/cooling_device0/

When I scribble into cur_state
I do not see anything reflected in
/proc/acpi/processor/*/throttling

Also, max_state is 10, when surely my processor
has only 8 T-states.

the cooling state of processor is a combination of p-state and t-state.
because reducing the frequency is preferred when system is overheat.
e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.

Quoted 11 lines

If user-space can not provoke processor T-states via this I/F, then those using the old /proc I/F will flag it as a regression when it goes away. (even if few should ever need it)

Quoted 2 lines

wakeup control,
/sys/devices/.../wakeup should be in the todo list. :)

I thought that Rafael said the wakeup file
in the device tree was working now -- at least
for PCI devices, no?

Rafael's patch did bind the "wakeup" file together with the ACPI device. It calls the acpi_enable_wakeup_device_power of the ACPI device, but it doesn't touch the wakeup GPE at all. So, I don't think it actually works...

Quoted 4 lines

Have you noticed that the GPEs are actually set up right before entering the sleep state? acpi_enable_wakeup_device() does that, so in fact yes, it does work.

acpi_enable_wakeup_device will enable all the valid wakeup GPEs, that's why dev->wakeup.state.enabled is set when writing to /proc/acpi/wakeup. And I don't think this flag is set in acpi_pm_device_sleep_wake, or do I miss something?