ACPI parser error

[nopper]

I got this while using acpi_thermal driver (cat /dev/power/acpi_thermal/0):

KERN: acpi_thermal: read()
KERN: acpi_thermal: GetThermalType()
KERN: ACPI Error (evregion-0426): No handler for Region [EC__] (0x90afa320) [EmbeddedControl] [20080701]
KERN: ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080701]
KERN: ACPI Error (psparse-0627): Method parse/execution failed [\_TZ_.THRM._TMP] (Node 0x90af9820), AE_NOT_EXIST
KERN: acpi_thermal: GotBasicTemperatures()

I think that's a problem relative to the bus manager in general (evaluate_method?)

[nopper]

I got these errors also using my driver that manages the battery. I need this function to test and then to release the code.

[nopper]

This is a first attempt to port the linux acpi_battery module to haiku.

[stippi]

Pretty cool. But you have some left-overs in your code, like turning on ACPI unconditionally (you need to change your "kernel" settings file instead) and also there are coding style violations/inconsistencies. If you could go over your patch again and look for coding style issues, that would be great! Thanks a lot for your work! BTW, Is there a userland application already which can work with this driver, or is this something that would need to be done yet?

[ithamar]

I've just started to look at this, but I get reasonable values with the current acpi_thermal driver on my EeePC 900, doing a cat /dev/power/acpi_thermal/0.... I'll try this patch and see if the battery driver gives me reasonable values too.

@nopper, could you attach the output of /dev/acpi/namespace here, just to see if we might be looking at an ACPI Table issue here?

[ithamar]

ok, after installing the battery driver it is unable to find the battery device, whilst there are multiple listed in the /dev/acpi/namespace output. One device is found without a name. I'm going to dive into the enumeration code, as that seems to fail, as the tables contain the battery device (see /dev/acpi/namespace output), but no acpi device node is generated for it.

I guess the bug that is causing this _might_ also cause the problem you're seeing. Will report back when I find this bugger ;)

[axeld]

BTW the PowerStatus application should be extended to work with this driver once it's ready :-)

I also wouldn't mind to have a userland API for it that's part of a power management framework that figures out the details itself. But that's something for R2 (we need something to improve upon, right? ;-)).

[ithamar]

ok, some more status here.... It seems (using dm_tree from KDL) that the device nodes for _all_ ACPI devices are actually being created, and with the appropriate paths/hids. The main problem seems to be that the *_support() functions in the drivers only get to see a subset of these, and therefore don't get to see the battery.

Will start looking into why this is this weekend. Expect a fix soon ;)

@Axel: Will take a look at the PowerStatus application, didn't even know we had it :P And yeah, lets get the basic tech working for R1, and leave R2 to use it intelligently ;)

[axeld]

There are a number of rules how the devices are iterated, and when supports_device() is being called. Either ACPI does not use the right flags for the nodes, or the device manager is at fault.

PowerStatus is currently not on the image, as APM is problematic, and ACPI is not only turned off by default, but also does not deliver the information yet :-)