Bug 9137
Summary: | No ACPI battery reported on Raon Digital Everun | ||
---|---|---|---|
Product: | ACPI | Reporter: | Bill Gribble (grib) |
Component: | Power-Battery | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED WILL_NOT_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, astarikovskiy |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.24-rc3 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg buffer for plug/unplug AC, remove/reinsert battery
syslog for boot, plug/unplug/plug AC, remove/reinsert battery |
Description
Bill Gribble
2007-10-08 14:09:01 UTC
>I have tried the patch in this thread for what appeared to be a similar >problem with an ASUS laptop No, it's a different problem. It seems that no ACPI battery devices is available on this machine. > /proc/acpi/ac_adapter/AC/state always contains the string "state: on-line", stupid BIOS IMO. Method (_STA, 0, NotSerialized) { Store (One, Local0) If (LEqual (Local0, One)) { Return (0x0F) } Else { Return (Zero) } } This is the _STA method for your AC device, and it apparently always returns 0x0F which means it's on-line. Can you please do the following test? set CONFIG_ACPI_DEBUG and recompile your kernel echo 0x0f > /sys/module/acpi/parameters/debug_layer echo 0x8800001f > /sys/module/acpi/parameters/debug_level unplug, plug the ac, attach the dmesg output remove/insert the battery, attach the dmesg output and attach the syslog as well. Created attachment 13530 [details]
dmesg buffer for plug/unplug AC, remove/reinsert battery
Created attachment 13531 [details]
syslog for boot, plug/unplug/plug AC, remove/reinsert battery
I followed the instructions above... nothing at all in dmesg output for remove/replace AC and battery. Looks like the only time ACPI makes an appearance in the logs is to disable my audio chipset (another problem I'm trying to debug). No need to mention that the battery level is reported under Windows... but it may be of interest that this computer has a special "controller" device that appears as a USB HID device, and controls many of the computer's functions. In Windows, the battery status and low-battery alarm are viewed in a special utility that also controls the functions of the controller device. I have decoded much of the control protocol that the controller device and haven't seen any evidence that it has anything to do with the battery. But I don't know that for sure. >echo 0x0f > /sys/module/acpi/parameters/debug_layer Oops, it should be "echo 0x04 >/sys/module/acpi/parameters/debug_layer". Can you try it again? Sorry for this mistake. and please send the dmesg and the content of /var/log/acpid. >No need to mention that the battery level is reported under Windows... Is the AC status reported correctly? >this computer has a special "controller" device that appears as >a USB HID device, and controls many of the computer's functions. That's the problem. There must be some platform specific thing that we don't know yet. This is probably true, especially for a UMPC, :). The AC status, the battery status are not controlled via ACPI. In order to make it work in Linux, a platform specific driver is needed to control these devices. If all these are true, I'm afraid I can't help you any more and I don't think we will fix it in ACPI generic code. OK, thanks for your help. I will do some more sniffing on the Windows side for battery/AC power info. FWIW I did the above steps with 0x04 instead of 0x0f and no difference, plugging and unplugging AC and battery causes no ACPI activity. So I think you are right that battery is not an ACPI function. >I did the above steps with 0x04 instead of 0x0f and no difference This means that not ACPI is not aware of the AC/Battery status changes. So I think what I said in comment #5 is true. Close this bug and mark it as INVALID. Bill, Please reopen it if you still have some questions. Thanks. OK, I have done further investigation on this and got some information from the manufacturer about the Windows battery utility: >> So: from what hardware device or IO port does ExpWin get the battery charge >> and AC adapter state? > > We build virtual driver which accesses to SMBus. When you run ExpWin, it > loads > the driver and accesses to the battery register. This led me on a merry chase through lm-sensors land, where I found that the "sensors-detect" program reports: Driver 'smartbatt' (should be inserted) Detects correctly: * Bus 'CS5536 ACB0' Busdriver `UNKNOWN', I2C address 0x0b Chip `Smart Battery' (confidence: 5) OK, that looks pretty good so far. But I try to track down the smart battery driver and find that it is no longer in I2C, but is back in ACPI! I have enabled the 'Smart Battery' driver in ACPI but still no battery reported. Any ideas? Thanks, Bill Gribble new info from Bill on bug# 9588: ---start--- Sensors-detect detects a Smart Battery, and i2cdetect shows why: # i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 0b -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I believe that the device at 0x0b is a smart battery because (1) the manufacturer told me the device had a smart battery on SMBus, (2) I can dump its contents and watch values within the register change in ways that make it really look like a battery. In particular, the stuff at 0x0c-0c0f looks like battery voltage or charge level (not sure of the scale)... it goes up when AC plugged in, down when discharging the battery. 0x2f looks like it represents the AC adapter state somehow; it takes different values when the AC is plugged in or not. # i2cdump -y 0 0x0b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 00 e6 0a 01 00 ff ff 01 fd 5b 04 04 02 62 44 18 .???...??[???bD? 10: 40 ff ff 58 00 38 a7 1b fc 5c 31 fb 08 XX XX XX @..X.8???\1??XXX 20: 0b 07 04 0d XX XX XX XX XX XX XX XX XX XX XX b0 ????XXXXXXXXXXX? 30: XX XX XX XX XX XX XX XX XX XX XX XX 00 1d 22 1d XXXXXXXXXXXX.?"? 40: XX XX XX XX XX de XX XX XX XX XX XX XX XX XX XX XXXXX?XXXXXXXXXX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX However, I can load the sbs and sbshc drivers and nothing happens (no battery information in /sys/ or /proc/ ACPI trees, only an AC adapter which claims to be always on, which is what my DSDT tells ACPI to say... see http://bugzilla.kernel.org/show_bug.cgi?id=9137) Any help appreciated! ---end--- *** Bug 9588 has been marked as a duplicate of this bug. *** This is the description of AC adapter in your DSDT. You may notice that it depends on Local0 being always equal to One (1). Battery is not mentioned in your DSDT at all. In order to be SBS compliant, at least EC and SBS manager(selector) should be described in DSDT. From there we could look-up batteries and charger states. Device (AC) { Name (_HID, "ACPI0003") Name (_PCL, Package (0x01) { _SB }) Method (_PSR, 0, NotSerialized) { Store (One, Local0) Return (Local0) } Method (_STA, 0, NotSerialized) { Store (One, Local0) If (LEqual (Local0, One)) { Return (0x0F) } Else { Return (Zero) } } } If you want to use SBS on your hardware/BIOS you probably could try to convert /drivers/acpi/sbs.c to use i2c controller interface, so it could work without ACPI, it should not be that hard, as sbshc is essentially i2c(smbus) controller too. |