RFC: ACPI namespace

[Sjoerd Simons]

On Sat, Jan 08, 2005 at 11:51:37AM +0000, Richard Hughes wrote:
> I've been working on policy for the ACPI extension I'm planning:

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..
> 
> 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..
> 
> 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).

> 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..
  
> 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.
> 
> 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 ? Is there a difference between this
property and the next one (thus can a processor do more power management then
throttling it's speed?)
  
> 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.

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

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 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)

  Sjoerd
-- 
The aim of science is to seek the simplest explanations of complex
facts.  Seek simplicity and distrust it.
		-- Whitehead.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal