Bug 15707

Created attachment 25889 [details]
calpella_dmesg_REG_fail

We do the following steps to collect dmesg
1. Compile the kernel with CONFIG_ACPI_DEGUG=y
2. Add boot opiton: acpi.debug_layer=0x10 acpi.debug_level=0x1f
3. dmeg | grep _REG to check whether _REG is evaluated or not

Created attachment 25890 [details]
diff_ec_try_econ.patch

we tried to re-evaluate _REG object and assign arguments (assigned 3 to Arg0
and 1 to Arg1) after acpi_ec_register_query_methods.

Then, the result of getting AC/DC status was correct.

Alexey, this is the EC problem I discussed with you last time.
can you take a look at this please?

Created attachment 25893 [details]
DSDT_calpella.dsl

The dsdt for the calpella platform

We found the abnormal about dmesg(https://bugzilla.kernel.org/attachment.cgi?id=25889) as following:

[    0.395830] ACPI: Execute Method [\_SB_.PCI0.P0P2.VGA_._STA] (Node f7450d74)
[    0.396054] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396131] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396522] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.396597] ACPI: Execute Method [\_SB_.PCI0.LPCB.EC0_._REG] (Node f7451860)
[    0.397619] ACPI: Execute Method [\] (Node c1739030)
[    0.397653]   nseval-0400 [00] ns_exec_module_code   : Executed module-level
code at f821ba6e
[    0.397658] ACPI: Executed 1 blocks of module-level executable AML code
[    0.397662] Completing Region/Field/Buffer/Package
initialization:.............................................................................................................................................................................ACPI:
Execute Method [\_SB_.PCI0._BBN] (Node f744ffa4)
[    0.402026] .............................
[    0.402472] Initialized 48/49 Regions 49/49 Fields 46/47 Buffers 59/60
Packages (2092 nodes)

The _REG was executed 4 times and initialized 48/49 regions. 1 region was failed to initialize.

After applying the testing patch (https://bugzilla.kernel.org/attachment.cgi?id=25890) that
we tried to re-execute _REG after acpi_ec_register_query_methods, we can workaround the AC/DC status issue. Is the workaround proper to apply?

Or, are there any debug parameter to find out the root cause(why region initialized
failed)?

Thanks.

Zhang,

I think problem is that there is no Operating Region with type EmbeddedControl.
The OpReg declared inside EC is SystemMemory for some reason.
Probably, ACPICA is not used to register OpReg handler to something not present.

Thus EC only sits on its GPE and launch _Qxx methods (quite a number of them).

Yes, Alexey, you're right!

look at the code below:

static acpi_status
acpi_ev_reg_run(acpi_handle obj_handle,
                u32 level, void *context, void **return_value)
{
        ...
        /* Object is a Region */

        if (obj_desc->region.space_id != space_id) {

                /* This region is for a different address space, just ignore it */

                return (AE_OK);
        }

        status = acpi_ev_execute_reg_method(obj_desc, 1);
        return (status);
}

when installing acpi ec address space handler, the _REG method will not be invoked because there is no EmbeddedControl region.
thus _REG is never invoked with parameter 3 and 1 on this laptop.

                    Method (_REG, 2, NotSerialized)
                    {
                        If (LEqual (Arg0, 0x03))
                        {
                            Store (Arg1, Local0)
                            If (Local0)
                            {
                                Store (One, ECON)
                            }
                            Else
                            {
                                Store (Zero, ECON)
                            }
                        }
                    }
ECON will not be set unless the patch in comment #2 is applied.

I will investigate if Windows invokes _REG(3, 1) in this case first...

In EC driver, ec_install_handlers calls acpi_install_address_space_handlers with  space id == 3 (ACPI_ADR_SPACE_EC) which in turns firstly calls acpi_ev_install_space_handler to attach the space id (3) to the EC region in ACPI name space, secondly calls acpi_ev_execute_reg_methods with same space id (3), which will invoke _REG with space ide (3). So it should work without any problem.

There is no EC region in ACPI name space, read carefully!

hi Alexey, if i use "OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100)" instead of "OperationRegion (ERAM, EmbeddedControl, 0xFF808201, 0x0100)" in DSDT, i will get AC/DC status, right?

hi Alexey, if i use "OperationRegion (ERAM,EmbeddedControl , 0xFF808201, 0x0100)"
instead of "OperationRegion (ERAM, SystemMemory, 0xFF808201, 0x0100)" in
DSDT, i will get AC/DC status, right?

Is this a pre-production machine?
Does windows detect AC/DC on it?
If so, which version?

(In reply to comment #12)
> Is this a pre-production machine?
> Does windows detect AC/DC on it?
> If so, which version?

Windows 7 can detect AC/DC status on this machine.

Interesting.
Does Windows XP work as well?

*** Bug 19602 has been marked as a duplicate of this bug. ***

Created attachment 40642 [details]
output of grep . /proc/acpi/battery/*/*

First of all sorry if i say something wrong, it's the first time i post here and i'm not a developer. My english is very broken too.
I'm coming here from https://bugzilla.kernel.org/show_bug.cgi?id=19602
I own an Acer A0521 and i have the very same issue as bug 19602 .
I'm on slitaz distro with 2.6.36 kernel.
I cannot apply diff_ec_try_econ.patch because static int acpi_ec_add in ec.c has been changed from kernel 2.6.36, is this bug supposed to be fixed with 2.6.36?
i can't get battery info but my /proc/acpi/ac_adapter works well, so maybe the other bug would be more appropriate.
i don't have /proc/acpi/thermal_zone at all.
if needed i'm available to build a kernel with CONFIG_ACPI_EC_DEBUGFS=y and give you required info, eventually i can install a more standard distro instead of slitaz

Created attachment 40652 [details]
output of zcat /proc/config.gz | grep ACPI

Created attachment 40982 [details]
errors in building patched 2.6.35.9 and working 2.6.34.7 /proc/acpi/BAT1/*

i have switched to archlinux because i had problems building kernel others than the default one in slitaz.
patch at comment 2 applies with no error to 2.6.34.7 and to 2.6.35.9, but the last one fails to build, while patched 2.6.34.7 with standard arch configs can correctly read Acer aspire one A0521 battery details. in 2.6.36 the patch fails in the last hunk. would it be possible to make current kernel recognize A0521 battery?

I made a never version of this patch, since the new kernel (2.6.36-tuxonice-r4) i used does not have that patch included:

*** ec.c.orig	2011-01-07 18:05:07.000000000 +0100
--- ec.c	2011-01-07 18:05:03.000000000 +0100
***************
*** 731,736 ****
--- 731,737 ----
  static int ec_install_handlers(struct acpi_ec *ec)
  {
  	acpi_status status;
+ 		
  	if (test_bit(EC_FLAGS_HANDLERS_INSTALLED, &ec->flags))
  		return 0;
  	status = acpi_install_gpe_handler(NULL, ec->gpe,
***************
*** 745,750 ****
--- 746,752 ----
  						    &acpi_ec_space_handler,
  						    NULL, ec);
  	if (ACPI_FAILURE(status)) {
+ 		printk (KERN_INFO "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n");
  		if (status == AE_NOT_FOUND) {
  			/*
  			 * Maybe OS fails in evaluating the _REG object.
***************
*** 759,764 ****
--- 761,768 ----
  			acpi_disable_gpe(NULL, ec->gpe);
  			return -ENODEV;
  		}
+ 	}else{
+ 		printk (KERN_INFO "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\n");
  	}
  
  	set_bit(EC_FLAGS_HANDLERS_INSTALLED, &ec->flags);
***************
*** 781,786 ****
--- 785,798 ----
  {
  	struct acpi_ec *ec = NULL;
  	int ret;
+ 	acpi_status status;
+ 	union acpi_object arg_objs[] = {
+ 		{ACPI_TYPE_INTEGER},
+ 		{ACPI_TYPE_INTEGER}
+ 	};
+ 	struct acpi_object_list args = { 2, arg_objs };
+ 	arg_objs[0].integer.value = 3;
+ 	arg_objs[1].integer.value = 1;
  
  	strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
  	strcpy(acpi_device_class(device), ACPI_EC_CLASS);
***************
*** 811,817 ****
  	if (!first_ec)
  		first_ec = ec;
  	device->driver_data = ec;
! 
  	WARN(!request_region(ec->data_addr, 1, "EC data"),
  	     "Could not request EC data io port 0x%lx", ec->data_addr);
  	WARN(!request_region(ec->command_addr, 1, "EC cmd"),
--- 823,835 ----
  	if (!first_ec)
  		first_ec = ec;
  	device->driver_data = ec;
! 	status = acpi_evaluate_object (ec->handle, "_REG", &args, NULL);
! 	
! 	if (ACPI_FAILURE(status)){
! 		printk (KERN_INFO "@@@@@@@@@@@@@ _REG\n");
! 	}
! 	
! 	
  	WARN(!request_region(ec->data_addr, 1, "EC data"),
  	     "Could not request EC data io port 0x%lx", ec->data_addr);
  	WARN(!request_region(ec->command_addr, 1, "EC cmd"),

Is this patch incuded in the kernel (or will be)?

No.
Good news is that Bob has proposed a patch to fix it in ACPICA code.

Do you know if that patch has been accepted ?

*** Bug 34532 has been marked as a duplicate of this bug. ***

what steve did at https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2 worked for me. Let me know if you want old/new dmesg and dsdt.dsl.

Same here as gmoutso. Steve's solution worked wonders.
For the record, I used Steve's hack at https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2, and because I was doing this kind of stuff first time ever, below are the relevant resources:
http://homeport.org/~bcordes/satellite-l500-install.html
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
https://help.ubuntu.com/community/Kernel/Compile

in the pipeline:

commit e2066ca1b211ff08325c98be9fb8ad95affbaba8
Author: Bob Moore <robert.moore@intel.com>
Date:   Wed Apr 13 13:22:04 2011 +0800

    ACPICA: Execute an orphan _REG method under the EC device

Coming here from bug 34532
Not sure if this is still relevant but i tried the following:
vanilla 2.6.39 kernel patched with ACPICA 20110413

the new acpi_ev_orphan_ec_reg_method runs but gives up trying to
find the ECDT.
Apparently this laptop (toshiba L645 ) and Ottos dont have ECDTs.

Steve's fix from https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2 for using a custom DSDT made my battery show up (but wireless broke, though that's a different story).

Tried 2.6.39-1 without the custom DSDT, but that didn't work.

Toshiba Satellite L655-S5158.

The patch in comment #27 shipped in Linux v3.0
leon7176, please report if v3.0 works for you or not,
and re-open if no.

Still not working for me... 
Gateway lt22 (linux 3.0)

still patching every kernel update manualy with this patch
https://bugzilla.redhat.com/attachment.cgi?id=470363

Neither works for me, using the patch like above. Looks like I can't reopen the bug.

*** Bug 42628 has been marked as a duplicate of this bug. ***

I have what I believe is the same issue on both a Latitude E6410 and Latitude E6420, using the latest kernel available. Linux reports that no battery is available, even while running on it. Windows has no issues on either machine. The only way I know my battery is getting low is when the battery LED on my laptop starts flashing red.

My fix is still working on the 3.2 kernel... (for Gateway lt22)
Comment #31

Here is a working p1 patch for 3.3-rc7
diff -uNpr linux-3.3-rc7.orig/drivers/acpi/ec.c linux-3.3-rc7.new/drivers/acpi/ec.c
--- linux-3.3-rc7.orig/drivers/acpi/ec.c        2012-03-14 19:00:18.459994716 -0400
+++ linux-3.3-rc7.new/drivers/acpi/ec.c 2012-03-14 19:05:45.716659504 -0400
@@ -784,6 +784,15 @@ static int acpi_ec_add(struct acpi_devic
        struct acpi_ec *ec = NULL;
        int ret;

+       acpi_status status;
+       union acpi_object arg_objs[] = {
+               {ACPI_TYPE_INTEGER},
+               {ACPI_TYPE_INTEGER}
+       };
+       struct acpi_object_list args = { 2, arg_objs };
+       arg_objs[0].integer.value = 3;
+       arg_objs[1].integer.value = 1;
+
        strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
        strcpy(acpi_device_class(device), ACPI_EC_CLASS);

@@ -811,7 +820,7 @@ static int acpi_ec_add(struct acpi_devic
        if (!first_ec)
                first_ec = ec;
        device->driver_data = ec;
-
+       status = acpi_evaluate_object (ec->handle, "_REG", &args, NULL);
        WARN(!request_region(ec->data_addr, 1, "EC data"),
             "Could not request EC data io port 0x%lx", ec->data_addr);
        WARN(!request_region(ec->command_addr, 1, "EC cmd"),

Here's a report with a Toshiba Satellite L640 of the problem
still being present on 3.2.18:

 http://bugs.debian.org/609846

Using a custom DSDT with

 OperationRegion (EMEM, SystemMemory, 0xFF808001, 0xFF)

replaced by

 OperationRegion (EMEM, EmbeddedControl, 0×00, 0xFF)

fixes it for the reporter.

Er, sorry, this might be the wrong bug.  By "the problem" I mean that
battery status is missing for Taylor.  I don't know if the AC Adapter
state is usable.

this is weird.
commit e2066ca1b211ff08325c98be9fb8ad95affbaba8 should have fixed this problem.

Bob,
this is duplicate with http://www.acpica.org/bugzilla/show_bug.cgi?id=875, right?

(In reply to comment #28)
> Coming here from bug 34532
> Not sure if this is still relevant but i tried the following:
> vanilla 2.6.39 kernel patched with ACPICA 20110413
> 
> the new acpi_ev_orphan_ec_reg_method runs but gives up trying to
> find the ECDT.
> Apparently this laptop (toshiba L645 ) and Ottos dont have ECDTs.

Bob,
do you have any plan on supporting these platforms that does not have EC address space or ECDT.

To have an EmbeddedControl address space, all that is really needed is the EC device, ECDT is optional.

It does look to me as though the acpica fix in 875 should fix the problem. But it has been a while, I will need to look closer at it again.

Does the fix for 875 make the machine behave any different?

(In reply to comment #41)
> To have an EmbeddedControl address space, all that is really needed is the EC
> device, ECDT is optional.
> 
> It does look to me as though the acpica fix in 875 should fix the problem.

the patch in comment 1 of bug 875 fixes the problem.

> But
> it has been a while, I will need to look closer at it again.
> 
> Does the fix for 875 make the machine behave any different?

I guess no, because it fails soon in acpi_ev_orphan_ec_reg_method because there is no ECDT found.

Then my question would be,
why we need ECDT? can't we get the acpi handle of ec by the acpi_namespace_node parameter in acpi_ev_execute_reg_methods?

After looking at the code, I see that the orphan_ec_reg_method code may not be "fully implemented". It depends on the ECDT being present in order to get a handle to the EC device quickly.

Note, the handle passed to execute_reg_methods is not the EC, it is some other device in the namespace. We are going back to the EC device to determine if a _REG method exists under EC that has not been executed (orphaned because there is no operation region under the EC that would cause the _REG to be invoked.)

I think a quick fix (at least to test the theory) would be to add a namespace walk to find the EC device (via the EC _HID) (in the case of no ECDT), and execute any orphaned _REG method found there.

There may be a better fix that we can determine later.

Created attachment 87901 [details]
execute orphan EC _REG even if ECDT not present

please try this patch and see if it helps or not.

ping...

(In reply to comment #44)
> Created an attachment (id=87901) [details]
> execute orphan EC _REG even if ECDT not present
> 
> please try this patch and see if it helps or not.

Yes that works!
Tried it against 3.4.9 source and will will try it on a newer kernel
version tonight

It works to me too. Tried with 3.6.10.

Works well on 3.6.10

What additional info is needed?

marked as RESOLVED, as there is a working patch attached
that may be a candidate for upstream

I'm ooo from Feb 9th to Feb 17th for Chinese New Year holiday.  Email response will be slow.
For any urgent issues, please call my cell phone.

Thanks,
Ning

patch in comment #44 was not accepted upstream.
so this bug report is now being marked ASSIGNED
and Rui will follow-up with another fix candidate.

*** Bug 43156 has been marked as a duplicate of this bug. ***

Hi Bob:
      Do you have plan fix this bug in the ACPICA recently?

It looks like we need a quirk inside EC driver to execute _REG for specific BIOS.

It looks such quirk can be generic enough to having it implemented inside ACPICA.  So I assigned this bug to myself.

As far as I can see, there are following 2 bugs in the Linux:

1. Orphan _REG method execution
   According to the spec, the OS will run a _REG in a given scope when the operation regions declared in that scope are available for use.
   By my reading, this means orphan _REG methods should be executed as long as all the operation regions declared below it's parent scope are all available for use -> this rule is not only for the EC device, but should be applied to all of the namespace scopes.
   This should be fixed in the ACPICA, ACPICA probably should check operation regions' availability in the acpi_install_address_space_handler and call all _REG methods under the given acpi_namespace_node.

2. the Embedded Controller space handler registration
   According to the spec, OSPM will make Embedded Controller operation regions, accessed via Embedded Controller described in ECDT, available before executing any control method.
   By my reading, this means only the Embedded Controller device pointed by the ECDT is responsible for registering EmbeddedControl space handler.
   This should be fixed in the Linux, Linux EC drivers need to check ECDT to see if it is responsible for handling EmbeddedControl space and the parameter passed to the acpi_install_address_space_handler should be ACPI_ROOT_OBJECT.

As a conclusion, I think non of the above fixes should be merged at this point as they all appear to be wrong approaches.
So please wait until a better solution can be worked out.

I'm trying to call _REG with each space id that known to be "installed" for the given namespace node.
But it seems there might be _REG methods written without space_id checking that will be broken on this approach.
Sorry for the noise.

Rui's patch to execute an orphan _REG method that appears under the EC device (during handler installation) has been integrated into ACPICA 20130418.

Great.
Mark as Resolved.
Will close the bug after ACPICA 20130418 shipped in Linux.

patch in https://bugzilla.kernel.org/show_bug.cgi?id=15707#c44 works also on the current kernel in ubuntu 3.8.8. There are some quirks that Steve's dsdt solution in
https://bugzilla.kernel.org/show_bug.cgi?id=34532#c2
didn't have.
1. powertop gives 4 Watts on my medium weight laptop. I think this is too small by a factor of 4-5.
2. power management in kde displays 99% for a new battery, or 30% for an old battery. I think it is showing the percentage to the design capacity. It should show 100% when fully charged, right?

> Will close the bug after ACPICA 20130418 shipped in Linux.

That version of ACPICA shipped in Linux-3.11