RE: Re: Smart Battery System driver

RE: Re: Smart Battery System driver

[Grover, Andrew]

> >From a distribution point of view, it would be nice to:
> 
> a) Not have to rewrite every acpi battery applet to use the sbs
> interface directly, and
> b) Not have to have a database of hardware that has a smart battery
> 
> Is there any way to provide the legacy interface even if standard
> battery support is built in, or alternatively some way of probing the
> system to determine which battery module should be loaded?

Hasn't anyone written a libpower yet? Battery applets shouldn't be
groveling around proc, they should be making library calls. OK all
existing apps would need to be changed (probably a big code reduction
actually) but this would let the library look for both CM and sbs
interfaces (which should not pretend to be a CMBatt of course) and
handle them.

Bonus points for also supporting APM through this interface...

-- Andy


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Karol Kozimor]

Thus wrote Grover, Andrew:
> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.
> 
> Bonus points for also supporting APM through this interface...

Hat-trick for the sysfs interface, when ACPI finally gets converted.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: Re: Smart Battery System driver

[Matthew Garrett]

On Thu, 2005-01-20 at 14:04 -0800, Grover, Andrew wrote:

> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.

hal is probably the right layer to do this, rather than develop yet
another niche abstraction library. I believe the fd.o people are working
on it.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

RE: Re: Smart Battery System driver

[Paul Ionescu]

On Fri, 21 Jan 2005 00:03:17 +0000, Matthew Garrett wrote:

> hal is probably the right layer to do this, rather than develop yet
> another niche abstraction library. I believe the fd.o people are working
> on it.

HAL is the right layer, and they are already working on ACPI, APM and
maybe other interfaces.
But a documentation would be nice for them too.
They should focus on implementing things in HAL instead of digging in the
kernel to see what to expect in various scenarios.

Thx,
Paul





-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Simon Fowler]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> > >From a distribution point of view, it would be nice to:
> > 
> > a) Not have to rewrite every acpi battery applet to use the sbs
> > interface directly, and
> > b) Not have to have a database of hardware that has a smart battery
> > 
> > Is there any way to provide the legacy interface even if standard
> > battery support is built in, or alternatively some way of probing the
> > system to determine which battery module should be loaded?
> 
> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.
> 
From my perspective (I'm the current maintainer of the wmacpi
battery monitor dockapp), all this would be much much easier if
there was some documentation of what exactly all the files in
/proc/acpi /mean/. I've had to root around in the kernel source to
work out what some of it does. 

I've got the beginnings of an acpi reporting library in wmacpi,
which I could fill out very easily if there was just some
documentation to base the code on . . .

> Bonus points for also supporting APM through this interface...
> 
If I had a laptop that supported APM I'd happily do that ;-)

Simon

-- 
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS) 
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: Smart Battery System driver

[Rich Townsend]

Simon Fowler wrote:
> On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> 
>>>>From a distribution point of view, it would be nice to:
>>>
>>>a) Not have to rewrite every acpi battery applet to use the sbs
>>>interface directly, and
>>>b) Not have to have a database of hardware that has a smart battery
>>>
>>>Is there any way to provide the legacy interface even if standard
>>>battery support is built in, or alternatively some way of probing the
>>>system to determine which battery module should be loaded?
>>
>>Hasn't anyone written a libpower yet? Battery applets shouldn't be
>>groveling around proc, they should be making library calls. OK all
>>existing apps would need to be changed (probably a big code reduction
>>actually) but this would let the library look for both CM and sbs
>>interfaces (which should not pretend to be a CMBatt of course) and
>>handle them.
>>
> 
> From my perspective (I'm the current maintainer of the wmacpi
> battery monitor dockapp), all this would be much much easier if
> there was some documentation of what exactly all the files in
> /proc/acpi /mean/. I've had to root around in the kernel source to
> work out what some of it does. 

Even then, what the *kernel* does can be misleading or incorrect. For 
instance, in /proc/acpi/battery/BAT0/info, the "battery technology" 
field should be reporting "primary" or "secondary", based on the 
information it gets from the appropriate DSDT control methods (_BIF, I 
think). However, the implementor of battery.c has misread the ACPI spec 
to mean that "primary" always denotes "non-rechargeable", and 
"secondary" always denotes "rechargeable".

This led to my previous laptop, which had a control-method primary 
battery, reporting the battery as non-rechargeable -- when of course it 
wasn't.

This really does highlight why a proper library is needed for battery 
access -- both to hide the details of whether the battery is CM-based or 
SB-based, but also to remove the additional layer of obfustication added 
by proc.

cheers

Rich


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:

> Hasn't anyone written a libpower yet? Battery applets shouldn't be
> groveling around proc, they should be making library calls. OK all
> existing apps would need to be changed (probably a big code reduction
> actually) but this would let the library look for both CM and sbs
> interfaces (which should not pretend to be a CMBatt of course) and
> handle them.

Thomas Renninger has written a libpower on which his powersaved is based.
It can be used without powersaved as well. It is hosted on
http://forge.novell.com (search for powersaved) and on sourceforge
(sorry, don't know the project name and right now i am offline, it probably
is also named powersaved).

> Bonus points for also supporting APM through this interface...

Yes, it can use both without the application knowing what the underlying
hardware is supporting.

Actually it is right now only extensively used and tested on SUSE, but
we have some bugreports from people compiling it on Mandrake and Debian
too, so it should not be too hard to get it going on other Distributions.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Rich Townsend]

Stefan Seyfried wrote:
> On Thu, Jan 20, 2005 at 02:04:16PM -0800, Grover, Andrew wrote:
> 
> 
>>Hasn't anyone written a libpower yet? Battery applets shouldn't be
>>groveling around proc, they should be making library calls. OK all
>>existing apps would need to be changed (probably a big code reduction
>>actually) but this would let the library look for both CM and sbs
>>interfaces (which should not pretend to be a CMBatt of course) and
>>handle them.
> 
> 
> Thomas Renninger has written a libpower on which his powersaved is based.
> It can be used without powersaved as well. It is hosted on
> http://forge.novell.com (search for powersaved) and on sourceforge
> (sorry, don't know the project name and right now i am offline, it probably
> is also named powersaved).
> 
> 
>>Bonus points for also supporting APM through this interface...
> 
> 
> Yes, it can use both without the application knowing what the underlying
> hardware is supporting.
> 
> Actually it is right now only extensively used and tested on SUSE, but
> we have some bugreports from people compiling it on Mandrake and Debian
> too, so it should not be too hard to get it going on other Distributions.

But aren't we really looking for a kernel-based libpower -- so that 
*nothing* in userspace needs be exposed to the specifics of the hardware?


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Matthew Garrett]

On Fri, 2005-01-21 at 12:06 -0500, Rich Townsend wrote:

> But aren't we really looking for a kernel-based libpower -- so that 
> *nothing* in userspace needs be exposed to the specifics of the hardware?

No. The kernel should provide information and functionality, not define
policy. A good comparison point might be the lm-sensors code - each
driver provides all the information it can, and the userland libsensors
abstracts that away from everything else.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Rich Townsend]

Matthew Garrett wrote:
> On Fri, 2005-01-21 at 12:06 -0500, Rich Townsend wrote:
> 
> 
>>But aren't we really looking for a kernel-based libpower -- so that 
>>*nothing* in userspace needs be exposed to the specifics of the hardware?
> 
> 
> No. The kernel should provide information and functionality, not define
> policy. A good comparison point might be the lm-sensors code - each
> driver provides all the information it can, and the userland libsensors
> abstracts that away from everything else.
> 

Yes, but isn't the lm-sensors kernel code accessed through a uniform 
API?   That's what we need for the kernel battery stuff; at the moment, 
CM batteries are interfaced using ACPI control methods, while Smart 
Batteries are interfaced using SMBus accesses. Wouldn't it be a good 
idea to present all of the available battery info through some unified 
interface? Or are you arguing that this should all be done (as much as 
possible) in userland?



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Matthew Garrett]

On Fri, 2005-01-21 at 13:04 -0500, Rich Townsend wrote:

> Yes, but isn't the lm-sensors kernel code accessed through a uniform 
> API?   That's what we need for the kernel battery stuff; at the moment, 
> CM batteries are interfaced using ACPI control methods, while Smart 
> Batteries are interfaced using SMBus accesses. Wouldn't it be a good 
> idea to present all of the available battery info through some unified 
> interface? Or are you arguing that this should all be done (as much as 
> possible) in userland?

In general, if it can be done in userland, it should be done in
userland. A power management abstraction layer is needed anyway (A
userspace app should be able to request a suspend without knowing
whether the system is ACPI, APM, a Mac or whatever), so implementing the
batteries in whichever way requires least kernel code is almost
certainly the right answer.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Fri, Jan 21, 2005 at 12:06:54PM -0500, Rich Townsend wrote:
 
> But aren't we really looking for a kernel-based libpower -- so that 
> *nothing* in userspace needs be exposed to the specifics of the hardware?

only if you like a bloated kernel. I don't :-)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Smart Battery System driver

[Matthew Garrett]

On Fri, 2005-01-14 at 14:23 -0500, Rich Townsend wrote:

> ...provides access to the SBS via a new /proc/acpi/sbs interface, and
> also provides a "legacy" /proc/acpi/battery interface that current
> battery-monitoring tools can access. This driver depends on Bruno's 
> i2c-acpi-ec driver, which I have included with my source code since a 
> couple of bug fixes were necessary.

One thing I've been meaning to ask - several Thinkpads have an
interesting design issue, whereby reading certain smbus addresses can
render the machine unbootable without a motherboard replacement. As a
result, i2c-piix refuses to load on Thinkpads. Does something similar
need to be done for i2c-acpi-ec, or does it only provide i2c access to
devices connected to the embedded controller?

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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

Re: Smart Battery System driver

[Johannes Kuhlmann]

Hi,

I just tried to use this with a pure kernel (2.6.10-gentoo-r2), that
means I didn't apply Bruno's patch before, and had some problems with
'acpi_ec_read' and 'acpi_ec_write' being unknown symbols. The problem
was, that those symbols were not exported. I had to put
EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after
the functions in drivers/acpi/ec.c.

Regards,
Johannes


-------------------------------------------------------
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

Re: Smart Battery System driver

[Johan Vromans]

Johannes Kuhlmann <jkuhlmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> I had to put
> EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after
> the functions in drivers/acpi/ec.c.

This is one of the issues Bruno's patch addressed...

-- Johan


-------------------------------------------------------
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

Re: Re: Smart Battery System driver

[Rich Townsend]

Johan Vromans wrote:
> Johannes Kuhlmann <jkuhlmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
> 
>>I had to put
>>EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after
>>the functions in drivers/acpi/ec.c.
> 
> 
> This is one of the issues Bruno's patch addressed...
> 

Yeah, I'd completely forgotten about the patch, until I went back and 
checked the instructions in Bruno's smartbatt package. D'oh!

I've modified the README file accordingly, and placed a copy of the 
patch in my acpi-sbs package. This is on top of a number of changes & 
additions to the code, which include:

*) Fixed scaling bug when capacity is reported in mWh
*) Added a new module parameter, capacity_info, to alter whether 
capacities are reported in mAh (charge) or mWh (power)
*) Fixed a number of bugs in the formatting of info/state output
*) Added support for Smart Battery System Manager (SBSM), Smart Battery 
Selector (SBSEL) and Smart Battery Charge (SBC) subsystems. With the 
code for these in place, the module correctly (I think) enumerates how 
many batteries the system can support, which ones are present, etc.
*) Added a new legacy interface for the AC adapter, in 
/proc/acpi/ac_adapter/*/state (where * is typically SBS0).
*) Put in semaphores, so the code *might* now be SMP safe. Of course, 
this may be a purely academic excercise; I've never met the lucky **** 
who has an SMP laptop :)

The latest copy of the code can be obtained from:

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

To move forward from here, I'd appreciate some advice from others on
this list. In particular

*) I'd like some feedback on the directory structure I've chosen. At the 
moment, the root directory of the Smart Battery System is 'sbs', but 
would something more verbose like 'smart_battery_system' be appropriate? 
Also, should various subdirectories, representing subsystems, have more 
descriptive names -- e.g., 'battery_A' instead of 'SB0' (the SBS spec. 
refers to the batteries as 'A', 'B' etc), 'selector' instead of 'SBSL', 
and so on?

*) I'd appreciate feedback from people with systems *other* than Acer 
TravelMater 4x00 laptops, to help check parts of the code that are not 
accessed on these machines (e.g., the Smart Battery System Manager code; 
my TM4502 laptop has an older Smart Battery Selector)

*) The code to update the Smart Battery System state from the SMBus is 
terribly slow, presumably because SMBus itself is a slow protocol. 
Unfortunately, this has the effect of freezing the system (including 
loss of keystrokes and/or mouse movements) whenever an update occurs. 
Typically, these freezes will arise every few seconds, as monitoring 
tools (e.g., gkrellm, wmacpi) poll the /proc/acpi interfaces. The 
jerkiness that results is unacceptable to many, including myself. How 
might I go about fixing this? I've tried putting a schedule() call after 
every individual SMBus access, but that appears to have little effect on 
the system responsiveness.

*) I'm not sure how to go about implmeneting Alarm functionality, not 
only to deal with low-power scenarios, but also to detect asynchronous 
events such as AC on-line/off-line and battery change, without the need 
for polling. Certainly, interrupts *are* being generated somewhere, as 
evidenced by the incrementing value of the acpi field in 
/proc/interrupts. Furthermore, with ACPI debugging enabled, I can see 
the embedded controller handling the events; for instance, an AC 
off-line event produces the following debug output:

Execute Method: [\_SB_.PCI0.LPC0.EC0_._Q20] (Node dded7de8)
  acpi_ec-0180 [5125] acpi_ec_read          : Read [c0] from address [19]
  acpi_ec-0180 [5125] acpi_ec_read          : Read [14] from address [3d]
  acpi_ec-0180 [5125] acpi_ec_read          : Read [c0] from address [19]
  acpi_ec-0232 [5126] acpi_ec_write         : Wrote [80] to address [19]

The corresponding DSL code for function _Q20 of my DSDT is:

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

...which unfortunately doesn't mean a whole lot to me. How can I install 
some form of a handler, so that when the EC detects a Smart Battery 
event (and -- as per the ACPI spec -- sets the EC Alarm Address and Data 
registers), and then fires off a General Purpose Event, a chunk of *my* 
code gets run?

Any pointers for the above questions will be very welcome -- and thanks 
to everyone who has responded with bug reports so far.

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

Re: Re: Smart Battery System driver

[Rich Townsend]

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

Re: Re: Smart Battery System driver

[Rich Townsend]

Rich Townsend wrote:
> Hi all --
> 
> I've just uploaded a new version of the Smart Battery driver:
> 
> 
> 

...and there's an even more-recent version at

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

This contains nothing particularly new, but there is a small tweak to 
the alarm writing code (to enable values up to 65535 to be written), 
plus an important modification to the battery selection code. This 
modification fixes situations where, on systems with a Smart Battery 
Selector, any read from a battery caused the charging of that battery 
temporarily to stop.

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

Re: Re: Smart Battery System driver

[Rich Townsend]

OK, it seems like I've drifted toward doing a nightly build of the SBS 
driver -- and tonight is no different! The latest version of the code,

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

contains some important changes, including:

*) fixed a segmentation fault on module load, experienced by some users 
(thanks to Pedro Venda & Olaf Jansen-Olliges for their "interactive 
debugging")
*) modified the i2c-acpi-ec module, to insert msleeps() after each 
read/write to the embedded controller - this leads to HUGE improvements 
in the responsiveness of the system when the /proc/acpi/* stuff is accessed
*) fixed some typos in the /proc/acpi/* output -- most importantly, the 
battery/BAT0/state file doesn't now report that a battery is discharging 
when it is in fact charging
*) fixed the allowed length of alarm values written into 
/proc/acpi/SBS/SB?/alarm, so that for instance "10000,10000" is now valid

Keep the bug reports coming!

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

Re: Re: Smart Battery System driver

[Rich Townsend]

Tonight's build:

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

...only has one modification (apart from fixing a typo in my name, 
thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the 
legacy-interface /proc/acpi/battery/*/state file is supposed to show the 
present discharge/charge rate in either mA or mW, depending on the 
capacity_mode used. However, I've just been using the current (in mA) 
returned by the Smart Battery System, which is clearly incorrect when 
capacity_mode=2 (mW) is selected.

I've fixed this in a rather cunning way. The SBS is more sophisticated 
than normal control-method batteries, in that individual batteries can 
report their time to empty or full (applications reporting on CM 
batteries have to calculate these times from the last full capacity and 
discharge/charge rates). What I've done in the latest release is to 
calculate what value of the 'present rate' field will produce the 
correct time to empty or full when combined with the last full capacity. 
The upshot is, not only does the 'present rate' field now give sensible 
values when capacity_mode=2, but also the times reported by applications 
using the legacy interface will be direct reflections of the proper SBS 
times.

The SBS driver seems to be working reasonably well now -- there are no 
outstanding bugs. My next task is to work out how best to aim for kernel 
integration, and to figure out how to set up event handling. Don't 
expect the pace of development to be as fast as the past few days -- I 
need sleep like the rest of you!

cheers,

Rich


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Pedro Venda]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:
| Tonight's build:
|
| http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
|
| ...only has one modification (apart from fixing a typo in my name,
| thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the
| legacy-interface /proc/acpi/battery/*/state file is supposed to show the
| present discharge/charge rate in either mA or mW, depending on the
| capacity_mode used. However, I've just been using the current (in mA)
| returned by the Smart Battery System, which is clearly incorrect when
| capacity_mode=2 (mW) is selected.
|
| I've fixed this in a rather cunning way. The SBS is more sophisticated
| than normal control-method batteries, in that individual batteries can
| report their time to empty or full (applications reporting on CM
| batteries have to calculate these times from the last full capacity and
| discharge/charge rates). What I've done in the latest release is to
| calculate what value of the 'present rate' field will produce the
| correct time to empty or full when combined with the last full capacity.
| The upshot is, not only does the 'present rate' field now give sensible
| values when capacity_mode=2, but also the times reported by applications
| using the legacy interface will be direct reflections of the proper SBS
| times.
|
| The SBS driver seems to be working reasonably well now -- there are no
| outstanding bugs. My next task is to work out how best to aim for kernel
| integration, and to figure out how to set up event handling. Don't
| expect the pace of development to be as fast as the past few days -- I
| need sleep like the rest of you!

yes, you definately deserve it. :-) very good work. again many thanks for your
time and dedication.

I think we should try to solve the issues with the current battery and ac ACPI
drivers. that is something that's giving some problems to most people trying the
driver.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: pjvenda-pQd4kjVL+REh2FBCd0jGRA@public.gmane.org
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB78pZeRy7HWZxjWERAsdDAKCRuMdt7ZGU1/jWmtrmQdsTVwwp8wCeL6lq
nfYvCiNBUUkA5T0E29VZVN0=
=mQIp
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Rich Townsend]

Pedro Venda wrote:
> Rich Townsend wrote:
> | Tonight's build:
> |
> | http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
> |
> | ...only has one modification (apart from fixing a typo in my name,
> | thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the
> | legacy-interface /proc/acpi/battery/*/state file is supposed to show the
> | present discharge/charge rate in either mA or mW, depending on the
> | capacity_mode used. However, I've just been using the current (in mA)
> | returned by the Smart Battery System, which is clearly incorrect when
> | capacity_mode=2 (mW) is selected.
> |
> | I've fixed this in a rather cunning way. The SBS is more sophisticated
> | than normal control-method batteries, in that individual batteries can
> | report their time to empty or full (applications reporting on CM
> | batteries have to calculate these times from the last full capacity and
> | discharge/charge rates). What I've done in the latest release is to
> | calculate what value of the 'present rate' field will produce the
> | correct time to empty or full when combined with the last full capacity.
> | The upshot is, not only does the 'present rate' field now give sensible
> | values when capacity_mode=2, but also the times reported by applications
> | using the legacy interface will be direct reflections of the proper SBS
> | times.
> |
> | The SBS driver seems to be working reasonably well now -- there are no
> | outstanding bugs. My next task is to work out how best to aim for kernel
> | integration, and to figure out how to set up event handling. Don't
> | expect the pace of development to be as fast as the past few days -- I
> | need sleep like the rest of you!
> 
> yes, you definately deserve it. :-) very good work. again many thanks 
> for your
> time and dedication.
> 
> I think we should try to solve the issues with the current battery and 
> ac ACPI
> drivers. that is something that's giving some problems to most people 
> trying the
> driver.

Well, I could make it so that the driver would refuse to compile if 
either of these were enabled in the kernel. That's something I 
originally considered doing, before I moved to the current behaviour of 
silently not compiling the legacy interfaces if ac or battery were 
enabled. It seems that such behaviour is confusing.

The best solution would be to perform a run-time check. I'll see if I 
can add code to dynamically detect if the ac_adapter and battery 
directories are empy on module insertion, and only add the legacy 
interfaces if they are.

cheers,

Rich

PS Last night, I got a proof-of-concept for event notifications working. 
I still haven't got battery alarms working, but we should now be able to 
do event-driven AC and battery present/charging/discharging statuses.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Thu, Jan 20, 2005 at 11:04:02AM -0500, Rich Townsend wrote:

> The best solution would be to perform a run-time check. I'll see if I 
> can add code to dynamically detect if the ac_adapter and battery 
> directories are empy on module insertion, and only add the legacy 
> interfaces if they are.

not "empty" but "do not exist". We will probably find machines that have
working CM Battery but can also be used with SBS.
Or maybe it is possible from kernelspace to check if a module is loaded
to lock each other out => if battery or ac is loaded, sbs will refuse
to load and the other way round.

> PS Last night, I got a proof-of-concept for event notifications working. 
> I still haven't got battery alarms working, but we should now be able to 
> do event-driven AC and battery present/charging/discharging statuses.

It would be pretty cool to throw an event on every change of battery charge
level (some HP notebooks do this even with CM battery), so there is no need
to poll for battery charge level.
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Pedro Venda]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seyfried wrote:
| On Thu, Jan 20, 2005 at 11:04:02AM -0500, Rich Townsend wrote:
|
|
|>The best solution would be to perform a run-time check. I'll see if I
|>can add code to dynamically detect if the ac_adapter and battery
|>directories are empy on module insertion, and only add the legacy
|>interfaces if they are.
|
|
| not "empty" but "do not exist". We will probably find machines that have
| working CM Battery but can also be used with SBS.
| Or maybe it is possible from kernelspace to check if a module is loaded
| to lock each other out => if battery or ac is loaded, sbs will refuse
| to load and the other way round.

I think the only way to do this is to integrate the sbs code into the battery
and ac_adapter drivers. that way at load time, the kernel code can check which
type of driver to use or both if possible/useful. that could be hard, I'm aware
of that.

|
|
|>PS Last night, I got a proof-of-concept for event notifications working.
|>I still haven't got battery alarms working, but we should now be able to
|>do event-driven AC and battery present/charging/discharging statuses.
|
|
| It would be pretty cool to throw an event on every change of battery charge
| level (some HP notebooks do this even with CM battery), so there is no need
| to poll for battery charge level.

wasn't there a not-so-recent-but-almost discussion about this issue in the
acpi-devel mailing list? I think people argued that acpi would NOT generate
events! that could mean that the acpi layer wouldn't generate events at all or
that it wouldn't generate events on behalf of hardware unable to generate events.

care to comment?

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: pjvenda-pQd4kjVL+REh2FBCd0jGRA@public.gmane.org
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QCceRy7HWZxjWERArT0AJ9Kxk1il9RjoV1/Ow4+Dl63L0yR4wCgz4+B
cf9OpRuKZaKnKHzZe02Csd8=
=KSIG
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: Re: Smart Battery System driver

[Stefan Seyfried]

On Fri, Jan 21, 2005 at 01:16:12PM +0000, Pedro Venda wrote:

> wasn't there a not-so-recent-but-almost discussion about this issue in the
> acpi-devel mailing list? I think people argued that acpi would NOT generate
> events! that could mean that the acpi layer wouldn't generate events at all 
> or
> that it wouldn't generate events on behalf of hardware unable to generate 
> events.

i have no idea ;-) I know that hp nx5000's continuously notify me via 
/proc/acpi/event if the charge level changes, so i only have to poll battery
after an notification and that is very handy IMO :-)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl