I am working on a Kontron COMExpress-PC computer on module board. This board uses the MARS smart battery system from Kontron. The status of the batteries is not updated when plugging or unplugging a battery. I have to manually poll the /proc interface for update to happen. Batteries are correctly detected at boot time but not after unless I read /proc/acpi/battery/BAT[12]/*. From the MARS documentation users guide, I see that the COM SM-Bus is connected to the smart battery system manager which is an LTC1760 chip. I've tried with different acpi_os_name and acpi_os with no luck. I've also tried putting some printk's in the acpi_battery_notify and I can confirm that it is never called. I've also noticed that the i2c-i820 module conflicts with a region claimed by ACPI. This region seems to be related to the battery system. Disabling the module removes the message but the batteries still aren't working as expected (I will put the dmesg of the kernel configured with i2c-i820 and i2c-scim). See attached files for more information.
Created attachment 31292 [details] disassmebled DSDT
Created attachment 31302 [details] ADP1 info plugged
Created attachment 31312 [details] ADP1 info unplugged
Created attachment 31322 [details] acpidump
Created attachment 31332 [details] battery info (no battery present)
Created attachment 31342 [details] battery info (one battery present)
Created attachment 31352 [details] battery info (two battery present)
Created attachment 31362 [details] BIOS decode
Created attachment 31372 [details] dmesg with i2c-i820
Created attachment 31382 [details] dmesg with i2c-scim
Created attachment 31392 [details] dmidecode
Created attachment 31402 [details] lspci -v output
Created attachment 31412 [details] lspci -vxxx output
please boot with the latest upstream kernel, and do the following test: 1. echo 1 > /sys/module/acpi/aml_debug_output && dmesg -c 2. cat /proc/interrupts > interrupts-1 && grep . /sys/firmware/acpi/interrupts/* > acpi-interrupt-1 3. unplug or plug the battery 4. cat /proc/interrupts > interrupts-2 && grep . /sys/firmware/acpi/interrupts/* > acpi-interrupt-2 && dmesg > dmesg and attach these five files here.
Created attachment 31612 [details] acpi-interrupt-1
Created attachment 31622 [details] acpi-interrupt-2
Created attachment 31632 [details] dmesg
Created attachment 31642 [details] interrupts-1
Created attachment 31652 [details] interrupts-2
Created attachment 31662 [details] dmesg60 A series of ACPI debug messages keep popping up in the log. See the attachment for an example.
Bad news. There is no interrupt when plugging/unplugging the battery... By reading the AML code, GPE 07 should be fired when AC/Battery is plugged/unplugged, but it doesn't. I guess the AC adapter status is not changed neither when AC is plugged/unplugged, right? This seems like an firmware problem to me and we can do nothing in Linux kernel to fix/workaround this. BTW: IMO, windows should have the same problem. It would be great if you can verify this.
(In reply to comment #21) > Bad news. > There is no interrupt when plugging/unplugging the battery... > By reading the AML code, GPE 07 should be fired when AC/Battery is > plugged/unplugged, but it doesn't. I guess the AC adapter status is not > changed > neither when AC is plugged/unplugged, right? > Right plugging/unplugging the AC doesn't change it's status. > This seems like an firmware problem to me and we can do nothing in Linux > kernel > to fix/workaround this. > BTW: IMO, windows should have the same problem. It would be great if you can > verify this. The board manufacturer says it should work under windows but I haven't tested it.