Re: Re: Smart Battery System driver

[Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org>]

Hi all --

I've just uploaded a new version of the Smart Battery driver:

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050117.tar.gz

Changes include

*) A slightly more-methodical use of mutexes (probably still broken, though)
*) An 'alarm' interface file in each SB? Smart Battery subdirectory (see 
the README file for usage instructions)
*) An 'alarm' interface file in each BAT? legacy battery subdirectory

The alarm functionality is read-write, so you can change the capacity & 
time-left levels at which the Smart Battery begins to generate alarm events.

HOWEVER, here's the rub: I haven't yet found a way of detecting when 
these alarm events are issued. Reading through chapter 12.12 of the ACPI 
spec, it appears that all Alarm Notify messages from EC-based SMBus 
should trigger a query method (_QXX), with the query value XX being set 
by the _EC named object.

For instance, on my system (TM4502):

                     Device (SMBC)
                     {
                         Name (_HID, "ACPI0001")
                         Name (_EC, 0x1820)
                         Device (SBS0)
                         {
                             Name (_HID, "ACPI0002")
                             Name (_SBS, 0x02)
                         }
                      }

...means that the SMBus has a base address of 0x18 within embedded 
controller space, and all SMBus events are handled by query method _Q20.

Looking at the definition of _Q20 on my system, we have:

                     Method (_Q20, 0, NotSerialized)
                     {
                         If (And (SMST, 0x40))
                         {
                             Store (SMAA, Local0)
                             If (LEqual (Local0, 0x14))
                             {
                                 And (SMST, 0xBF, SMST)
                             }
                         }
                     }

This I think I can understand: if the SMBus Alarm Notify bit is set (bit 
14 of the SMST register), and the alarm was triggered by the device with 
shifted address 0x14, then reset the alarm bit.

Now what corresponds to shifted address 0x14? Well, shift it one bit to 
the right to get the 'true' SMBus slave address, and we find the value 
0x0a -- which corresponds (see sec. 10 of the ACPI spec.) to a Smart 
Battery System Manager (SBSM) or Smart Battery Selector (SBSEL, which 
I've got on my system). So, the _Q20 method listens for alarms coming 
from the SBSM/SBSEL, but takes no specific action when it receives one, 
beyond resetting it.

Spurred on by a post by a very helpful post by Karol Kozimor, I tried 
adding code to the _Q20 method, to fire off a notifcation to the driver 
(well, in fact I just used a Store(XXXXX, debug) to get some output). 
With this code in place, I found that my SBSEL was generating alarms 
when the AC power cord was plugged in and removed. Likewise, events were 
generated when the battery was removed and re-inserted.

Hurrah, I thought -- we can get the 'backend' for alarms to work 
(although we'll need to do some DSDT hacking). But here now is the 
problem: using the new driver, I set the alarm trigger levels to 
crazy-high values, to get the Smart Battery to fire off alarm events. 
But these events seem to be getting lost somewhere, or they're not being 
generated in the first place, because I don't get a peep from my hacked 
_Q20 method.

I don't know why this is the case, but its worth noting that section 
10.1.1 of the spec states "The Smart Battery System Manager, the Smart 
Battery Selector, and the Smart Battery Charger each have an optional 
mechanism for notifying the system that the battery configuration or AC 
status has changed. ACPI requires that this interrupt mechanism be 
through the SMBus Alarm Notify mechanism." Important note: no mention 
whatsoever of alarms generated by the Smart Battery itself!

But where, then, do the Smart Battery alarms end up? Reading sec. 
5.6.2.2.2 of the spec. gave me hope: "Similarly, for an SMBus driver, if 
no driver registers for SMBus alarms, the SMBus driver will queue 
control methods to handle these. Methods must be placed under the SMBus 
device with the name _QXX, where XX is the hex format of the SMBus 
address of the device sending the alarm". So I went added _QXX methods 
for SMBus slave address 0x0b (Smart Battery) and its shifted equivalent 
0x16. Unfortunately, again not a peep from the battery.

What could be going wrong? Some thoughts:
*) maybe there is already a driver registered for SMBus alarms, that 
prevents them from getting through?
*) I'm assuming its already there, but maybe the functionality described 
in 5.6.2.2.2 actually needs to be implemented in the i2c-acpi-ec code?
*) perhaps the battery simply isn't generating the alarms?
*) maybe I just don't know enough about what I'm doing?

Well, that's enough rambling for me -- I just wanted to share how far 
I'd got in working out what is what. I'd really like to get the alarm 
issue resolved, since it is the most important feature to me, but at the 
moment I need to do some Real Work to keep my boss happy. It would be 
great if eveyone interested in Smart Battery support could have a shot 
at playing around like I have -- seriously, you don't need to know a 
whole lot!

cheers,

Rich


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt