RFC: ACPI namespace

[Richard Hughes]

(updated namespace at bottom of document)

On Sat, 08 Jan 2005 14:09:36 +0100, Sjoerd Simons wrote:
> I've promised to look at the PMU part, but didn't have the time i've
> hoped for during the holidays.. At least for the powersaving parts acpi
> and pmu can be unified..

Sounds good :-)

>> acpi namespace:
>> Device objects with the capability acpi represent all the devices
>> currently accessed through the ACPI bus and found in /proc/acpi.
>> 
>> Key: acpi.version (string)
>> Mandatory: No
>> Description: The in-kernel driver version providing ACPI services.
>> Usually of the form 20041210.
> 
> Can be pmu.version.. This is only needed for application that have
> detailed knowledge about the versions, so namespacing it isn't a
> problem..

Agreed


>> acpi.ac_adaptor namespace:
>> Device objects with the capability acpi.ac_adaptor represent all the
>> devices capable of powering the system from AC power. Note that device
>> objects can only have the acpi.ac_adaptor capability if they have
>> already got the capability acpi. The following property is available:
>> 
>> Key: acpi.ac_adaptor.enabled (bool)
>> Mandatory: Yes
>> Description: The state of the adaptor, i.e. whether it is providing
>> power to the unit.
> 
> If you just drop the acpi prefix here, we can do exactly the same for
> PMU and probably for apm too. Using power instead of acpi would be ok i
> guess (thus power.ac_adaptor).
> 
> 
Sure, could we not just use system to reduce the number of TL namespaces?

>> acpi.button namespace:
>> Device objects with the capability acpi.button represent all the
>> devices capable of providing a state to the system. Note that device
>> objects can only have the acpi.button capability if they have already
>> got the capability acpi. The following property is available:
>> 
>> Key: acpi.button.type (string)
>> Mandatory: Yes
>> Values:
>> lid_switch: The switch on a laptop that senses whether the lid is open
>> or closed.
>> power: The main power button on the computer sleep: The sleep button on
>> a computer capable of putting the computer into a suspend state.
> 
> The only ``button'' of this type on a powerpc (at least on a powerbook)
> that i know of is the lid.  Again if you change the acpi prefix into
> something generic, it can be used for both powerbooks and acpi
> machines..

Agreed, using the system namespace?

>> acpi.processor namespace:
>> Device objects with the capability acpi.processor represent all CPU's
>> in the system. Note that device objects can only have the
>> acpi.processor capability if they have already got the capability acpi.
>> The following properties are available:
> 
> Again no need for the acpi prefix here. Using system.processor would be
> better imho.

Agreed

>> Key: acpi.processor.number (int)
>> Mandatory: Yes
>> Description: The internal processor number in the system
>> 
>> Key: acpi.processor.power_management (int) Mandatory: No
>> Description: Whether the processor supports advanced power management
>> facilities.
> 
> Seems to be a candidate for a bool type ?

My error, you're right, a copy/paste error on my part.

> Is there a difference between this
> property and the next one (thus can a processor do more power management
> then throttling it's speed?)

I believe so. Throttling is to do with changing my frequency (ala
speedstep), but I've not worked out what
/proc/acpi/processor/CPU0/info:powermanagement is used for yet, but my
laptop has it set, and my desktop not. I'll leave it out unless someone
needs it.

>> Key: acpi.processor.can_throttle (int) Mandatory: No
>> Description: Whether the processor supports throttling to decrease it's
>> own clock speed.
> This should be boolean from the naming. And i guess a
> processor.{minimum,maximum}_speed would be nice (type int, mhz). Afaik
> all processors that can throttle can provide this information, so making
> it mandator iff processor.can_throttle == true would be okay i guess.

Again, my error on the bool.

I wanted to leave the throttling specifics until later, because it varies
wildly between models of laptops. AFAIK some laptops can only set
pre-defined frequencies (like 800MHz, 400MHz, 200MHz) and others can scale
pretty much as they like. Tell me if I'm wrong.
I wanted to get the core bits of the power management into HAL, and then
we can refine the policies into something more specific. I played with the
idea of using a percentage scale, and then for the scaling backend to
automatically choose the nearest frequency from the available list. But,
ideas are welcome :-)

processor.maximum_speed is a must, even without the throttling.

> As a general comment just don't prefix everything with acpi :) On a
> powerpc you can get basically same info for most stuff.
> 
> 
Okay

> What i'm missing are sensors. For example my powerbook has 2 light
> sensors and 2 temperature sensors. Can ACPI provide this kind of stuff

What's a light sensor? What's it for? Sorry if I'm being dense...

For temperature, you're right, ACPI can display it:
/proc/acpi/thermal_zone/THRM/temperature

(I only get one temperature reading, "CPU" on my laptop so I put it in the
system.processor namespace. I also get a case temperature reading on my
desktop, but where would it best go? system.temperature?

I've added a sample to the new system.processor namespace (look down),
please comment on what you think.

> or is that always lmsensors domain ? Also for laptops having the
> brightness level of the lcd would be nice (Nothing to do with acpi, but
> still)

WIP :-) the LCD stuff has been my #1 priority for a long time... 

Has any work been done in the past on HAL to support probing of
monitors/LCDs?

I've added the display_device namespace. What other properties do display
devices need?

UPDATED NAMESPACE FOLLOWS:

########################################### 
pmu namespace:
Device objects with the capability pmu represent devices currently
accessed through the PMU bus /dev/pmu.
###########################################

Key: pmu.version (string)
Mandatory: No
Description: The in-kernel driver version providing PMU services.

########################################### 
acpi namespace:
Device objects with the capability acpi represent devices currently
accessed through the ACPI bus and found in /proc/acpi.
###########################################

Key: acpi.version (string)
Mandatory: No
Description: The in-kernel driver version providing ACPI services. Usually
of the form 20041210.

########################################### 
system namespace:
Device objects with the capability system represent all the system devices
currently accessed through the ACPI or PMU bus.
###########################################

------------------------------------------- 
system.ac_adaptor namespace:
------------------------------------------- 
Device objects with the
capability system.ac_adaptor represent all the devices capable of powering
the system from AC power. 
The following property is available:

Key: system.ac_adaptor.enabled (bool) 
Mandatory: Yes
Description: The state of the adaptor, i.e. whether it is providing power
to the unit.

------------------------------------------- 
system.button namespace:
------------------------------------------- 
Device objects with the capability system.button represent all the devices
capable of providing a state to the system. 
The following property is available:

Key: system.button.type (string)
Mandatory: Yes
Values:
 lid_switch: The switch on a laptop that senses whether the lid is open or
 closed. 
 power: The main power button on the computer
 sleep: The sleep button on a computer capable of putting the computer into
 a suspend state.

------------------------------------------- 
system.processor namespace:
------------------------------------------- 
Device objects with the capability system.processor represent all CPU's in
the system. 
The following properties are available:

Key: system.processor.number (int)
Mandatory: Yes
Description: The internal processor number in the system

Key: system.processor.can_throttle (bool) 
Mandatory: No
Description: Whether the processor supports throttling to decrease it's
own clock speed.

Key: system.processor.maximum_speed (long) 
Mandatory: No
Description: The speed of the processor in units of MHz

Key: system.processor.temperature (int)
Mandatory: No
Description: The temperature of the processor in degrees Celsius

-------------------------------------------
system.display_device namespace:
-------------------------------------------
Device objects with the capability display_device represent all display
devices in the system. The following properties are available:

Key: system.display_device.type (string)
Mandatory: Yes
Values:
 lcd: A LCD panel
 crt: A CRT tube
 tv_out: TV Out
Description: The type of display device

Key: system.display_device.lcd.brightness (int)
Mandatory: No
Description: The brightness of the LCD panel in percent
Note: Only valid if system.display_device.type is lcd

Thanks, Richard

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal