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

Smart Battery System driver

[Rich Townsend]

Hi all --

Recently, Bruno Ducrot posted a driver that allows access to smart
batteries, through the /dev/i2c interface. This came at just the right
time for me, since I'd recently purchased an Acer TravelMate 4502, and
had no way to monitor the status of the smart battery.

However, this driver is primarily to allow access to the SMBus inside
the embedded controller that communicates with the Smart Battery System
(SBS); other tools are required to read the battery status. Bruno
provided a userspace tool, but there is still a requirement for some
form of /proc/acpi interface that current battery-monitoring tools can read.

Accordingly, I've written a first shot at an SBS ACPI driver. This
driver, which can be downloaded from

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

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

Instructions for compilation and installation, plus some anticipated
FAQs, can all be found in the accompanying README file. This is my first
ever shot at kernel programming (and in fact my first real program in
C!), so please expect there to be a number of goofs; but it seems to
work OK on my system (2.6.10-gentoo-r4, with battery monitoring using
wmacpi-1.99). Let me know what you find!

On a final note, DON'T use the SBS driver if you have the ACPI battery
driver enabled in the kernel (either built-in, or as a module) -- the
two will clash over their use of /proc/acpi/battery, and things will get
Ugly(tm).

cheers,

Rich Townsend



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

[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

[Johannes Kuhlmann]

I thought it wouldn't be necessary to apply the patch because Rich
didn't mention it in his README file.

Regards,
Johannes


On Sat, 15 Jan 2005 11:57:11 +0100, Johan Vromans <jvromans-2pNSKKP3PSKEVqv0pETR8A@public.gmane.org> 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...
> 
> -- 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
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>


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

[François Valenduc]

Hello,

Thanks for your driver. With this new version, the AC adapter status is 
available, which is better. There are even two ac_adapter directory in 
/proc/acpi. However, I don't find anymore battery information. I have 
seen that directory structure has changed and that now, 
/proc/acpi/battery is empty. I have tried the cat command on the new sbs 
sub-directory but I didn't find usual battery info. Also with the first 
version you sended, I noticed that the remaining battery time was too 
low. For example, with a battery fully loaded, I am supposed to have 
only around 40 minutes of autonomy, which is a bit short !

Thanks for your help,
Sincerely yours,
François Valenduc

Rich Townsend a écrit :

> 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
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>



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

[François Valenduc]

Hello again,

In fact, I now have battery and ac adapter info. I just had to remove AC 
adapter support in the ACPI support in kernel configuration. 
Neverthelss, I still get strange values for the remaining time. Now, 
when battery is full loaded, I am suposed to have an autonomy of 54 
hours ! That would be wonderful but I don't think it's realstic !

Would you haveAny ideas to solve the problem. Thanks in advance


>
> Rich Townsend a écrit :
>
>> 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
>> _______________________________________________
>> Acpi-devel mailing list
>> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>>
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
>



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

[Karol Kozimor]

Thus wrote Rich Townsend:
> ...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.

The best way to do this would be to insert a Notify statement in the code.
Here's a snippet from the appropriate method on my machine:

Notify (\_SB.ACAD, 0x80)

Of course, since you have a smart battery it is unlikely that you have an
AC adapter device present in the DSDT, so you'd have to hack up a device
in your tables and acpi_install_notify_handler() against it to have it 
reported.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@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: Re: Smart Battery System driver

[Bruno Ducrot]

On Sun, Jan 16, 2005 at 03:55:57AM -0500, Rich Townsend wrote:
> Johan Vromans wrote:
...

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

> *) 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.

Look http://marc.theaimsgroup.com/?l=acpi4linux&m=109760298204539&w=2
More, the acpi-i2c-ec need to be event driven, which is not the case
yet.

> 
> *) 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?

This have to be done in i2c-acpi-ec which will overwrite that one and
must not be run if we do it correctly.
I guess this method is for OS which do not implement that one, as its
the case for now..

Remember, we have that:
                    Device (SMBC)
                    {
                        Name (_HID, "ACPI0001")
                        Name (_EC, 0x1820)
                                       ^^
				   which will correspond to
				   this _Q20 that we have to
				   overwrite.



                        Device (SBS0)
                        {
                            Name (_HID, "ACPI0002")
                            Name (_SBS, 0x02)
                        }
                    }

Many thanks again for your work,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

[Pedro Venda]

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

Rich Townsend wrote:
| 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.

Any chance of permanently fixing the ACPI ec driver with this patch? I'm sure
it'll continue to be needed and such change would spare us from patching every
kernel every day... just a thought... After all, all it does is exporting some
symbols... care to comment?

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

hi rich,

I haven't been very busy, so no time to comment or test your driver.

| *) 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.

nice! :-)

| *) Added a new legacy interface for the AC adapter, in
| /proc/acpi/ac_adapter/*/state (where * is typically SBS0).

that'd be nice.

| *) 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 :)

true. me neither.

|
| The latest copy of the code can be obtained from:
|
| http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050116.tar.gz

got it. any newer code?

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

my honest not privileged and not acpi/kernel experienced oppinion is:
/proc/acpi/sbs seems sane. also SB?, SBSEL, SBC, etc seems very close to the
ACPI standard, which justifies those names.

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

I've tried your newer driver. reports are on the bottom of the e-mail.

| *) The code to update the Smart Battery System state from the SMBus is
| terribly slow,

| *) 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.

can't help you on any of these questions. lack of knowledge/experience. sorry.

The report:

I've tried to load the module and it still has the mutual-exclusion problem with
the acpi AC and battery drivers. How can that be fixed?

With AC built-in the kernel, the module segfaults on insmod...

After removing the AC driver, it loads fine and reports good results.
Appearently looks nice. Tried with and without battery. Both SBSEL, SBC and SB0
values make sense.

Don't know if it's still relevant, but here's a link for my version of the
smartbattery.c userspace program. just "make" and test it. needs the i2c-dev and
i2c-acpi-ec drivers.

http://arrakis.dhis.org/linux/smartbattery/smartbattery-20050117.tar.gz

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

iD8DBQFB6+dpeRy7HWZxjWERAjZ9AKDuRZ3bHn1pQNLsFFhvjXnH7KlSEgCg5nhi
Vq5ovAO0EWiMFWEfg9hHLzI=
=GCxy
-----END PGP SIGNATURE-----


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

Pedro Venda wrote:

> The report:
> 
> I've tried to load the module and it still has the mutual-exclusion 
> problem with
> the acpi AC and battery drivers. How can that be fixed?
> 
> With AC built-in the kernel, the module segfaults on insmod...

Not surprised, there's probably all manner of crap that happens when one 
tries to mkdir /proc/acpi/ac_adapter more than once.

But I'm not sure why this is happening with the revised version of the 
code (20050116); this version contains #ifndef directives to prevent the 
legacy interfaces being compiled in if they are already in the kernel. 
Are you sure your kernel configuration matches your currently-running 
kernel?

> After removing the AC driver, it loads fine and reports good results.
> Appearently looks nice. Tried with and without battery. Both SBSEL, SBC 
> and SB0
> values make sense.

Excellent!

> 
> Don't know if it's still relevant, but here's a link for my version of the
> smartbattery.c userspace program. just "make" and test it. needs the 
> i2c-dev and
> i2c-acpi-ec drivers.
> 
> http://arrakis.dhis.org/linux/smartbattery/smartbattery-20050117.tar.gz

Thanks for the pointer, I'll try this out!

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

[Matthew Garrett]

On Mon, 2005-01-17 at 20:36 -0500, Rich Townsend wrote:

> But I'm not sure why this is happening with the revised version of the 
> code (20050116); this version contains #ifndef directives to prevent the 
> legacy interfaces being compiled in if they are already in the kernel. 
> Are you sure your kernel configuration matches your currently-running 
> kernel?

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

Thanks,
-- 
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: Re: Smart Battery System driver

[Zdzisław A. Kaleta]

Dnia wtorek 18 stycznia 2005 12:11, Matthew Garrett napisał:
> 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?
As I have wrote earlier the klaptopdaemon (kde applet) can take info from 
exsting files under /proc/acpi created by the acpi_sbs module.
At least under 2.6.10 kernel ;-/
-- 
z.a.kaleta (sanskryt), registered Linux User #279350


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

[Zdzisław A. Kaleta]

Dnia wtorek 18 stycznia 2005 12:23, Zdzisław A. Kaleta napisał:
> Dnia wtorek 18 stycznia 2005 12:11, Matthew Garrett napisał:
> > 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?
>
> As I have wrote earlier the klaptopdaemon (kde applet) can take info from
> exsting files under /proc/acpi created by the acpi_sbs module.
> At least under 2.6.10 kernel ;-/
I want to add that kaptopdemon just generated the sount signal and print extra 
window in which has informed me that to the end of battery is only 15 
minutes and later the info that only 5 minutes left.
The smartbattery program show the same info.
This was impossble before.
-- 
z.a.kaleta (sanskryt), registered Linux User #279350


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

Matthew Garrett wrote:
> On Mon, 2005-01-17 at 20:36 -0500, Rich Townsend wrote:
> 
> 
>>But I'm not sure why this is happening with the revised version of the 
>>code (20050116); this version contains #ifndef directives to prevent the 
>>legacy interfaces being compiled in if they are already in the kernel. 
>>Are you sure your kernel configuration matches your currently-running 
>>kernel?
> 
> 
>>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?

We can't have the legacy interface (/proc/acpi/battery) if standard 
battery support is built in, since standard battery support *defines* 
the legacy interface! The legacy interfaces in acpi-sbs only exist to 
fake the existence of a standard (i.e., control method, CM) battery.

Regarding auto-loading of the correct module, it is likely that at some 
point in the future there may be some sort of merge between the SBS work 
done by myself and Bruno Ducrot, and the standard battery code 
battery.c. This will involve quite a bit of design effort, since the 
ACPI spec considers SBS and CM batteries to be totally different beasts 
(I don't know why they didn't define a unified interface for batteries).

But at the moment we're still at the phase of getting the SBS system 
working properly.

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

[Pedro Venda]

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

Rich Townsend wrote:
| 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.

I'm sorry to mention... but it segfaults everytime when I insmod it with the
battery plugged.

what kind of debug information do you need to sort this out? Or is it already known?

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

iD8DBQFB7QiLeRy7HWZxjWERApwWAKC85v+B6urVcd8nyr7C7duFTbNJ2wCfa4Gd
n9ad3nRo8e5ynB+uBMBlrLc=
=EX4F
-----END PGP SIGNATURE-----


-------------------------------------------------------
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: Smart Battery System driver

[Johan Vromans]

Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:

> http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050119.tar.gz
> Keep the bug reports coming!

Good work! Seems to function properly on my TravelMate 4001WLMi.

The Gnome Battery applet does not detect when the AC state changes. Is
that part of the required but still to be implemented event interface?

-- 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:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050119.tar.gz
>>Keep the bug reports coming!
> 
> 
> Good work! Seems to function properly on my TravelMate 4001WLMi.
> 
> The Gnome Battery applet does not detect when the AC state changes. Is
> that part of the required but still to be implemented event interface?

Yes -- in the sense that a notify event should be issued on AC state 
change, but the code to do that isn't yet there.

However, I'm surprised that the GB applet doesn't get the AC state from 
polling /proc/acpi/adapter/AC0/state. I use wmacpi, and that shows up 
the AC state fine...

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: Smart Battery System driver

[Johan Vromans]

Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:

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

It seems you install the modules in /lib/modules/XXX/i2c etc. instead
of /lib/modules/XXX/kernel/driver/i2c etc. Is that intentional?

I got bitten by this since I previously installed the i2c-acpi-ec
driver in /lib/modules/XXX/kernel/driver/i2c, which apparently took
precedence over the one installed in /lib/modules/XXX/i2c.

-- Johan


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

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050119.tar.gz
> 
> 
> It seems you install the modules in /lib/modules/XXX/i2c etc. instead
> of /lib/modules/XXX/kernel/driver/i2c etc. Is that intentional?
> 
> I got bitten by this since I previously installed the i2c-acpi-ec
> driver in /lib/modules/XXX/kernel/driver/i2c, which apparently took
> precedence over the one installed in /lib/modules/XXX/i2c.

I do this because everything in /lib/modules/XXX/kernel/* gets clobbered 
when you do a make modules_install from the kernel source tree; any 
module not part of the source tree is deleted. That's why external 
modules really don't belong in the /lib/modules/XXX/kernel/* tree -- IMHO.

Of course, this will eventaully be moot, when/if the SBS stuff actually 
gets put into the kernel. I have recently realized that the whole SBS 
functionality can be implemented in terms of control methods in the 
DSDT, without the need for any kernel drivers. It may be interesting to 
have a shot at implementing the SBS this way, and then making some sort 
of autopatch script which adds the SBS code to a supplied DSDT.

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: Smart Battery System driver

[Johan Vromans]

Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:

> I do this because everything in /lib/modules/XXX/kernel/* gets
> clobbered when you do a make modules_install from the kernel source
> tree; 

I see.

> I have recently realized that the whole SBS functionality can be
> implemented in terms of control methods in the DSDT, without the
> need for any kernel drivers.

Nice. This would require a kernel recompile/reboot  for each DSDT
modification...

-- Johan


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

[Bernard Blackham]

On Thu, Jan 20, 2005 at 10:31:20PM +0100, Johan Vromans wrote:
> > I have recently realized that the whole SBS functionality can be
> > implemented in terms of control methods in the DSDT, without the
> > need for any kernel drivers.
> 
> Nice. This would require a kernel recompile/reboot  for each DSDT
> modification...

http://gaugusch.at/kernel.shtml has a patch to allow you to include
your DSDT in an initrd to save you having to recompile the kernel.

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>


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

Johan Vromans wrote:
| Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
|
|
|>I do this because everything in /lib/modules/XXX/kernel/* gets
|>clobbered when you do a make modules_install from the kernel source
|>tree;
|
|
| I see.
|
|
|>I have recently realized that the whole SBS functionality can be
|>implemented in terms of control methods in the DSDT, without the
|>need for any kernel drivers.
|
|
| Nice. This would require a kernel recompile/reboot  for each DSDT
| modification...

not nice, I guess. 99.9% of the interested (me included) wouldn't be able to
patch their DSDT and with generated ASL (is it ASL or AML or... ACPI language)
code for their specific case.

but academically interesting :-)

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

iD8DBQFB8QGAeRy7HWZxjWERAiBTAKChHU1ZOOuJLe1QmG/seChXZO2v1wCgulDn
MSYoH67MOpPTB27v0ad467c=
=dJMG
-----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

[Johan Vromans]

[Quoting Pedro Venda, on January 21 2005, 13:20, in "Re: [ACPI] Re: Smart"]
> 99.9% of the interested (me included) wouldn't be able to patch
> their DSDT and with generated ASL (is it ASL or AML or... ACPI
> language) code for their specific case.

I found it almost trivial to correct the DSDT and customize the kernel
to use it. No hard or mysterious tricks involved...

-- Johan



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

Johan Vromans wrote:
| [Quoting Pedro Venda, on January 21 2005, 13:20, in "Re: [ACPI] Re: Smart"]
|
|>99.9% of the interested (me included) wouldn't be able to patch
|>their DSDT and with generated ASL (is it ASL or AML or... ACPI
|>language) code for their specific case.
|
|
| I found it almost trivial to correct the DSDT and customize the kernel
| to use it. No hard or mysterious tricks involved...

ok, but it'd take a tree of hacked DSDT for all sorts of laptops to make the
patching automatic. I guess for me or you it'd be simple to patch, but talk
about a linux user that uses suse linux or mandrake to make it easier to
use/administrate...

not flaming distros here! I'm just saying those try to do things automatically
on behalf of people (which is not bad in many cases) and it'd be hard to do such
automatic patching.

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

iD8DBQFB8QTneRy7HWZxjWERArduAJ9qAaDlzbF2BD6gzjdpcbH4HSkdVACfdokt
fACjOib484Y7LlqxKQ+PR0A=
=KTsH
-----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:
> Johan Vromans wrote:
> | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> |
> |
> |>I do this because everything in /lib/modules/XXX/kernel/* gets
> |>clobbered when you do a make modules_install from the kernel source
> |>tree;
> |
> |
> | I see.
> |
> |
> |>I have recently realized that the whole SBS functionality can be
> |>implemented in terms of control methods in the DSDT, without the
> |>need for any kernel drivers.
> |
> |
> | Nice. This would require a kernel recompile/reboot  for each DSDT
> | modification...
> 
> not nice, I guess. 99.9% of the interested (me included) wouldn't be 
> able to
> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI 
> language)
> code for their specific case.

What if you just had to run a perl script, and then add an "initrd=" 
line to your kernel boot parameters? Because the code would be *so* much 
cleaner if a lot of the tasks were moved to the DSDT; in particular, we 
could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on 
I2C.

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:
| Pedro Venda wrote:
|
|> Johan Vromans wrote:
|> | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
|> |
|> |
|> |>I do this because everything in /lib/modules/XXX/kernel/* gets
|> |>clobbered when you do a make modules_install from the kernel source
|> |>tree;
|> |
|> |
|> | I see.
|> |
|> |
|> |>I have recently realized that the whole SBS functionality can be
|> |>implemented in terms of control methods in the DSDT, without the
|> |>need for any kernel drivers.
|> |
|> |
|> | Nice. This would require a kernel recompile/reboot  for each DSDT
|> | modification...
|>
|> not nice, I guess. 99.9% of the interested (me included) wouldn't be
|> able to
|> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|> language)
|> code for their specific case.
|
|
| What if you just had to run a perl script, and then add an "initrd="
| line to your kernel boot parameters? Because the code would be *so* much
| cleaner if a lot of the tasks were moved to the DSDT; in particular, we
| could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on
| I2C.

I'd agree that the i2c-acpi dependency is not pretty.

on the other hand... I'm still not liking the CM (dump, limited) interface to
control SBS (smart, sophisticated) batteries. yes, CM gets the information from
the SBS hardware but I can't stop feeling loosing capabilities.

any way, I'm willing to cooperate with you on either decision, although I
seriously dislike the DSDT thing.

regards,
pedro venda.

|
| 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
| _______________________________________________
| Acpi-devel mailing list
| Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
| https://lists.sourceforge.net/lists/listinfo/acpi-devel


- --

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

iD8DBQFB8QbJeRy7HWZxjWERAtVTAKDE8wO1QtEOSXAt+blvQka7KDGC0ACgtTLO
ANWFnIdDuWs8CRQv1hkpTe8=
=cSaT
-----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:
> | Pedro Venda wrote:
> |
> |> Johan Vromans wrote:
> |> | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> |> |
> |> |
> |> |>I do this because everything in /lib/modules/XXX/kernel/* gets
> |> |>clobbered when you do a make modules_install from the kernel source
> |> |>tree;
> |> |
> |> |
> |> | I see.
> |> |
> |> |
> |> |>I have recently realized that the whole SBS functionality can be
> |> |>implemented in terms of control methods in the DSDT, without the
> |> |>need for any kernel drivers.
> |> |
> |> |
> |> | Nice. This would require a kernel recompile/reboot  for each DSDT
> |> | modification...
> |>
> |> not nice, I guess. 99.9% of the interested (me included) wouldn't be
> |> able to
> |> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
> |> language)
> |> code for their specific case.
> |
> |
> | What if you just had to run a perl script, and then add an "initrd="
> | line to your kernel boot parameters? Because the code would be *so* much
> | cleaner if a lot of the tasks were moved to the DSDT; in particular, we
> | could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on
> | I2C.
> 
> I'd agree that the i2c-acpi dependency is not pretty.
> 
> on the other hand... I'm still not liking the CM (dump, limited) 
> interface to
> control SBS (smart, sophisticated) batteries. yes, CM gets the 
> information from
> the SBS hardware but I can't stop feeling loosing capabilities.

Ah, but there doesn't have to be any loss of capabilities. There are two 
separate issues here:

1) Implementing the SMBus access through control methods, as described 
by the API in the SMBus-CM specification (which I'll be trying out very 
soon)

2) Implementing a control-method wrapper for SBS, so that it can be 
accessed using the API described in Sec. 10.2 of the ACPI specification.

Issue (1) basically removes the need for the i2c_acpi_ec module, and 
indeed the need to have any i2c or smbus support in the kernel; 
everything is done through the embedded controller. This is highly 
desirable.

Issue (2) would allow SBS batteries to appear to the kernel as CM 
batteries, meaning that the stock battery.ko module can be used. This, 
however, is obviously a backward-compatibility step, and not the way 
forward; however, it may be a 'clean' interim solution to implementing 
SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM 
batteries through a standard interface.

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:
| Pedro Venda wrote:
|
|> Rich Townsend wrote:
|> | Pedro Venda wrote:
|> |
|> |> Johan Vromans wrote:
|> |> | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
|> |> |
|> |> |
|> |> |>I do this because everything in /lib/modules/XXX/kernel/* gets
|> |> |>clobbered when you do a make modules_install from the kernel source
|> |> |>tree;
|> |> |
|> |> |
|> |> | I see.
|> |> |
|> |> |
|> |> |>I have recently realized that the whole SBS functionality can be
|> |> |>implemented in terms of control methods in the DSDT, without the
|> |> |>need for any kernel drivers.
|> |> |
|> |> |
|> |> | Nice. This would require a kernel recompile/reboot  for each DSDT
|> |> | modification...
|> |>
|> |> not nice, I guess. 99.9% of the interested (me included) wouldn't be
|> |> able to
|> |> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|> |> language)
|> |> code for their specific case.
|> |
|> |
|> | What if you just had to run a perl script, and then add an "initrd="
|> | line to your kernel boot parameters? Because the code would be *so*
|> much
|> | cleaner if a lot of the tasks were moved to the DSDT; in particular, we
|> | could get rid of i2c_acpi_sbs, and thus remove the dependency of
|> ACPI on
|> | I2C.
|>
|> I'd agree that the i2c-acpi dependency is not pretty.
|>
|> on the other hand... I'm still not liking the CM (dump, limited)
|> interface to
|> control SBS (smart, sophisticated) batteries. yes, CM gets the
|> information from
|> the SBS hardware but I can't stop feeling loosing capabilities.
|
|
| Ah, but there doesn't have to be any loss of capabilities. There are two
| separate issues here:
|
| 1) Implementing the SMBus access through control methods, as described
| by the API in the SMBus-CM specification (which I'll be trying out very
| soon)
|
| 2) Implementing a control-method wrapper for SBS, so that it can be
| accessed using the API described in Sec. 10.2 of the ACPI specification.
|
| Issue (1) basically removes the need for the i2c_acpi_ec module, and
| indeed the need to have any i2c or smbus support in the kernel;
| everything is done through the embedded controller. This is highly
| desirable.
|
| Issue (2) would allow SBS batteries to appear to the kernel as CM
| batteries, meaning that the stock battery.ko module can be used. This,
| however, is obviously a backward-compatibility step, and not the way
| forward; however, it may be a 'clean' interim solution to implementing
| SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM
| batteries through a standard interface.

ahhh, there's a nice explanation. thanks :-)

so, just to clear things up, solution (1) doesn't need DSDT patching?? that'd be
excelent "value-for-money". it'd provide access to SBS information without ugly
acpi-i2c dependencies.

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

iD8DBQFB8WMceRy7HWZxjWERAhKuAJ9uxEDnia3IOkTJBXWI30jYgCaNHwCeNvJ5
HWHutp6t9GOKO3IHvnHEtqs=
=g4zf
-----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:

<snip>

> | Ah, but there doesn't have to be any loss of capabilities. There are two
> | separate issues here:
> |
> | 1) Implementing the SMBus access through control methods, as described
> | by the API in the SMBus-CM specification (which I'll be trying out very
> | soon)
> |
> | 2) Implementing a control-method wrapper for SBS, so that it can be
> | accessed using the API described in Sec. 10.2 of the ACPI specification.
> |
> | Issue (1) basically removes the need for the i2c_acpi_ec module, and
> | indeed the need to have any i2c or smbus support in the kernel;
> | everything is done through the embedded controller. This is highly
> | desirable.
> |
> | Issue (2) would allow SBS batteries to appear to the kernel as CM
> | batteries, meaning that the stock battery.ko module can be used. This,
> | however, is obviously a backward-compatibility step, and not the way
> | forward; however, it may be a 'clean' interim solution to implementing
> | SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM
> | batteries through a standard interface.
> 
> ahhh, there's a nice explanation. thanks :-)
> 
> so, just to clear things up, solution (1) doesn't need DSDT patching?? 
> that'd be
> excelent "value-for-money". it'd provide access to SBS information 
> without ugly
> acpi-i2c dependencies.
> 

No, both require DSDT patching -- unless there is a way to add objects 
into the ACPI namespace dynamically (anyone got any ideas on this?).

This of course is a big barrier to adoption. But having said that, 
patching a DSDT is no more difficult than patching a kernel. You just 
tweak the source code, compile it, and then add an initrd= argument to 
the kernel boot parameters.

However, maybe someone could do some work on making it even easier? Any 
thoughts?

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
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel



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

[Zdzisław A. Kaleta]

Dnia piątek 21 stycznia 2005 14:26, Rich Townsend napisał:
> Pedro Venda wrote:
> > Johan Vromans wrote:
> > | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> > |>I do this because everything in /lib/modules/XXX/kernel/* gets
> > |>clobbered when you do a make modules_install from the kernel source
> > |>tree;
> > |
> > | I see.
> > |
> > |>I have recently realized that the whole SBS functionality can be
> > |>implemented in terms of control methods in the DSDT, without the
> > |>need for any kernel drivers.
> > |
> > | Nice. This would require a kernel recompile/reboot  for each DSDT
> > | modification...
> >
> > not nice, I guess. 99.9% of the interested (me included) wouldn't be
> > able to
> > patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
> > language)
> > code for their specific case.
>
> What if you just had to run a perl script, and then add an "initrd="
> line to your kernel boot parameters? Because the code would be *so* much
> cleaner if a lot of the tasks were moved to the DSDT; in particular, we
> could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on
> I2C.
>
> cheers,
>
> Rich
What about people who didn't use initrd in their kernel?
-- 
z.a.kaleta (sanskryt), registered Linux User #279350


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

[Pavel Machek]

Hi!

> |>I do this because everything in /lib/modules/XXX/kernel/* gets
> |>clobbered when you do a make modules_install from the kernel source
> |>tree;
> |
> |
> | I see.
> |
> |
> |>I have recently realized that the whole SBS functionality can be
> |>implemented in terms of control methods in the DSDT, without the
> |>need for any kernel drivers.
> |
> |
> | Nice. This would require a kernel recompile/reboot  for each DSDT
> | modification...
> 
> not nice, I guess. 99.9% of the interested (me included) wouldn't be able to
> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI 
> language)
> code for their specific case.
> 
> but academically interesting :-)

Well, we could just ask Acer to include that SBS code into their
DSDTs....
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


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

Pavel Machek wrote:
| Hi!
|
|
|>|>I do this because everything in /lib/modules/XXX/kernel/* gets
|>|>clobbered when you do a make modules_install from the kernel source
|>|>tree;
|>|
|>|
|>| I see.
|>|
|>|
|>|>I have recently realized that the whole SBS functionality can be
|>|>implemented in terms of control methods in the DSDT, without the
|>|>need for any kernel drivers.
|>|
|>|
|>| Nice. This would require a kernel recompile/reboot  for each DSDT
|>| modification...
|>
|>not nice, I guess. 99.9% of the interested (me included) wouldn't be able to
|>patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|>language)
|>code for their specific case.
|>
|>but academically interesting :-)
|
|
| Well, we could just ask Acer to include that SBS code into their
| DSDTs....
| 								Pavel

which apparently is a waste of time. from some e-mails I've seen around, they
are very reluctant to support anything linux-related.

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

iD8DBQFB8+CVeRy7HWZxjWERAtWDAKChdQD+2XgjEo2WXkxM2syyZzwnegCfXOew
49zml3i6YKUDBy1LsaPMmRU=
=ymwH
-----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

[Stefan Seyfried]

On Sun, Jan 23, 2005 at 05:36:21PM +0000, Pedro Venda wrote:

> | Well, we could just ask Acer to include that SBS code into their
> | DSDTs....
> | 								Pavel
> 
> which apparently is a waste of time. from some e-mails I've seen around, 
> they
> are very reluctant to support anything linux-related.

That's not exactly true. Although they tell this to every end-user (funny
sice they are buying the stuff), some people at acer seem to be willing
to cooperate with Linux distributors. Of course, it depends on the phase
of the moon and what that people had to lunch today and for sure the right
hand at acer does not know what the left hand is doing (and the other way
round). But not everything is lost, there may still be some hope (and i
will of course not buy acer until this is fixed).
-- 
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: Smart Battery System driver

[Jeroen Wijnhout]

On Wednesday 19 January 2005 05:32, Rich Townsend wrote:
> 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:

I've tried the above driver on my Acer TM4001WLMi and it sort of doesn't work. 
The problem is that after modprobing i2c_acpi_ec and acpi_sbs I've got two 
battery and two ac_adapter directories in /proc (very weird if you ask me).

So before modprobing:
ls -l /proc/acpi
gives
total 0
dr-xr-xr-x   10 root root 0 2005-01-19 19:36 .
dr-xr-xr-x  103 root root 0 2005-01-19 20:36 ..
dr-xr-xr-x    2 root root 0 2005-01-19 19:44 ac_adapter
-rw-r--r--    1 root root 0 2005-01-19 19:44 alarm
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    5 root root 0 2005-01-19 19:44 button
-rw-r--r--    1 root root 0 2005-01-19 19:44 debug_layer
-rw-r--r--    1 root root 0 2005-01-19 19:44 debug_level
-r--------    1 root root 0 2005-01-19 19:44 dsdt
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 embedded_controller
-r--------    1 root root 0 2005-01-19 19:36 event
-r--------    1 root root 0 2005-01-19 19:44 fadt
dr-xr-xr-x    4 root root 0 2005-01-19 19:44 fan
-r--r--r--    1 root root 0 2005-01-19 19:44 info
dr-xr-xr-x    4 root root 0 2005-01-19 19:44 power_resource
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 processor
-rw-r--r--    1 root root 0 2005-01-19 19:44 sleep
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 thermal_zone
-rw-r--r--    1 root root 0 2005-01-19 19:44 wakeup

Then, after modprobing the modules
total 0
dr-xr-xr-x   10 root root 0 2005-01-19 19:36 .
dr-xr-xr-x  103 root root 0 2005-01-19 20:36 ..
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 ac_adapter
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 ac_adapter
-rw-r--r--    1 root root 0 2005-01-19 19:45 alarm
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    5 root root 0 2005-01-19 19:45 button
-rw-r--r--    1 root root 0 2005-01-19 19:45 debug_layer
-rw-r--r--    1 root root 0 2005-01-19 19:45 debug_level
-r--------    1 root root 0 2005-01-19 19:45 dsdt
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 embedded_controller
-r--------    1 root root 0 2005-01-19 19:36 event
-r--------    1 root root 0 2005-01-19 19:45 fadt
dr-xr-xr-x    4 root root 0 2005-01-19 19:45 fan
-r--r--r--    1 root root 0 2005-01-19 19:45 info
dr-xr-xr-x    4 root root 0 2005-01-19 19:45 power_resource
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 processor
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 sbs
-rw-r--r--    1 root root 0 2005-01-19 19:45 sleep
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 thermal_zone
-rw-r--r--    1 root root 0 2005-01-19 19:45 wakeup

Something works:
cat ac_adapter/AC0/state
gives
state: off-line

However,
ls battery
gives nothing (empty dir).

There is an sbs dir, that has all the correct info. The only thing that seems 
to give problems is the battery directory. Also it would be nice if there was 
only one battery and ac_adapter dir.

best,
Jeroen
-- 
Kile - a LaTeX Environment for KDE
http://kile.sourceforge.net


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

[Olaf Jansen-Olliges]

Hi Joeren, 

> I've tried the above driver on my Acer TM4001WLMi and it sort of doesn't
> work. The problem is that after modprobing i2c_acpi_ec and acpi_sbs I've
> got two battery and two ac_adapter directories in /proc (very weird if you
> ask me).

you should not have ac_adapter or battery before "modprobing" have you diabled 
the ac_adapter and battery section in your kernel configuration? (as 
mentioned in the README)

Good luck 
 Olaf


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

[Johan Vromans]

Olaf Jansen-Olliges <o.jansen-n+qsWun7DryELgA04lAiVw@public.gmane.org> writes:

> you should not have ac_adapter or battery before "modprobing" have
> you diabled the ac_adapter and battery section in your kernel
> configuration? (as mentioned in the README)

This is (in) my rc.local:

    # Experimental: drivers for smartbattery reading.
    modprobe i2c-dev
    modprobe i2c-acpi-ec
    modprobe -r ac
    modprobe -r battery
    modprobe acpi-sbs

-- Johan


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

Johan Vromans wrote:
> Olaf Jansen-Olliges <o.jansen-n+qsWun7DryELgA04lAiVw@public.gmane.org> writes:
> 
> 
>>you should not have ac_adapter or battery before "modprobing" have
>>you diabled the ac_adapter and battery section in your kernel
>>configuration? (as mentioned in the README)
> 
> 
> This is (in) my rc.local:
> 
>     # Experimental: drivers for smartbattery reading.
>     modprobe i2c-dev
>     modprobe i2c-acpi-ec
>     modprobe -r ac
>     modprobe -r battery
>     modprobe acpi-sbs

Note that i2c-dev isn't needed by i2c-acpi-ec or acpi-sbs. Also,
you can get acpi-sbs to automatically load i2c-acpi-ec by adding the line

below acpi-sbs i2c-acpi-ec

...to /etc/modules.conf. With this line in place, your rc.local would 
look like

modprobe -r ac
modprobe -r battery
modprobe acpi-sbs

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

[Olaf Jansen-Olliges]

Hi Johan, 

>    # Experimental: drivers for smartbattery reading.
>    modprobe i2c-dev
>    modprobe i2c-acpi-ec
>    modprobe -r ac
>    modprobe -r battery
>    modprobe acpi-sbs


i've tested it again on my machine. I only get values for my battery when i 
disable 

- CONFIG_ACPI_AC and
- CONFIG_ACPI_BATTERY

in my kernel configuration. Even when they are marked to be build as modules i 
get no values! Perhaps you should try to compile a new kernel with this 
variables set to no.

greetings
 Olaf


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

[Jeroen Wijnhout]

On Wednesday 19 January 2005 20:10, Olaf Jansen-Olliges wrote:
> Hi Joeren,
>
> > I've tried the above driver on my Acer TM4001WLMi and it sort of doesn't
> > work. The problem is that after modprobing i2c_acpi_ec and acpi_sbs I've
> > got two battery and two ac_adapter directories in /proc (very weird if
> > you ask me).
>
> you should not have ac_adapter or battery before "modprobing" have you
> diabled the ac_adapter and battery section in your kernel configuration?
> (as mentioned in the README)

This was enabled, so I will have to recompile the kernel I guess.

best,
Jeroen

P.S.: Next time I will read the README before asking a question ;-)
-- 
Kile - KDE Integrated LaTeX Editor
http://kile.sourceforge.net


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

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: Smart Battery System driver

[Antoni Villalonga]

2005/1/20, Rich Townsend :
> Tonight's build:
> 
> http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz

I'm sorry for reply an old mail.
But, it's the last release of acpi_sbs kernel module?

I know about sbs-linux project in sourceforge, but I get a big delay
(about ~20 seconds) with my Acer TM 4001 when I try to read battery
status.

There are any way to fix it?

Thanks!!

(Sorry my English, I'm not an English speaker)
-- 
$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/k1uMJSBkQmQ@public.gmane.org


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hi Antoni, 

> But, it's the last release of acpi_sbs kernel module?

i think yes.

>
> I know about sbs-linux project in sourceforge, but I get a big delay
> (about ~20 seconds) with my Acer TM 4001 when I try to read battery
> status.

perhaps you have the same problem which is discussed in this thread:

https://sourceforge.net/tracker/index.php?func=detail&aid=1191536&group_id=129330&atid=714494


I've an ACER Extensa 3002WLMI which is said to be the same machine. With the 
information given there i have no problems on my machine :-) Perhaps we should 
integrate this information in a new Version/Patchfile and send it to Rich.

If you need more Information (or if ir works for you) please let me know.

> (Sorry my English, I'm not an English speaker)
same problem here :-)

Regards
        Olaf

BTW: have you got suspend to disk / ram working on your machine?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Yu Luming]

On Tuesday 06 September 2005 14:19, Olaf Jansen-Olliges wrote:
> Hi Antoni,
>
> > But, it's the last release of acpi_sbs kernel module?
>
> i think yes.
>
> > I know about sbs-linux project in sourceforge, but I get a big delay
> > (about ~20 seconds) with my Acer TM 4001 when I try to read battery
> > status.
>
> perhaps you have the same problem which is discussed in this thread:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=1191536&group_id=
>129330&atid=714494
>
>
> I've an ACER Extensa 3002WLMI which is said to be the same machine. With
> the information given there i have no problems on my machine :-) Perhaps we
> should integrate this information in a new Version/Patchfile and send it to
> Rich.

Please try if  this works too 
http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73 

Thanks,
Luming


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hi Luming, 


> Please try if  this works too
> http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73

I'd like to try the given patch...

but
--->

The requested 
URL /pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/acpi-20050729-2.6.12.patch.gz 
was not found on this server.
<---

can you please give me a hint where i am wrong.

Regards
	Olaf


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Yu Luming]

On Tuesday 06 September 2005 14:54, Olaf Jansen-Olliges wrote:
> Hi Luming,
>
> > Please try if  this works too
> > http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73
>
> I'd like to try the given patch...
>
> but
> --->
>
> The requested
> URL
> /pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/acpi-20050729-2.6
>.12.patch.gz was not found on this server.
> <---
>
> can you please give me a hint where i am wrong.
>
> Regards
> 	Olaf

Hmm, I don't know.  But you can find the ec patch here:
http://bugzilla.kernel.org/attachment.cgi?id=5574&action=view


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hi Luming, 

> Hmm, I don't know.  But you can find the ec patch here:
> http://bugzilla.kernel.org/attachment.cgi?id=5574&action=view

got it :-) 
Thanks a lot. I'll give it a try and let you know if this works for me.

Olaf


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hi Luming, 


> Please try if  this works too
> http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73

with this patch ( i applied it to a fresh 2.6.13 vanilla kernel ) a older 
problem reoccured on my machine. When i type (fast) sometimes keystrokes are 
missed. But the time for reading the battery state is OK. Can i give you more 
information or help in debugging? 

With ec_burst=1 it seems to be slightly better but i'm afraid some keys are 
lost then too.

Thanks a lot
	Olaf


BTW.: if this is only a problem on my (rotten) ACER. The patch from Rich 
Townsend works here really sufficient for me. But I am really willing to help 
you - if you want me to do so


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Yu Luming]

On Tuesday 06 September 2005 16:41, Olaf Jansen-Olliges wrote:
> Hi Luming,
>
> > Please try if  this works too
> > http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73
>
> with this patch ( i applied it to a fresh 2.6.13 vanilla kernel ) a older
> problem reoccured on my machine. When i type (fast) sometimes keystrokes
> are missed. But the time for reading the battery state is OK. Can i give
> you more information or help in debugging?

Thanks for testing.  Without ec_burst=1,  the driver still use spin lock. 
If ec_burst=1 doesn't work for you, I will be a little supprised.
>
> With ec_burst=1 it seems to be slightly better but i'm afraid some keys are
> lost then too.
>
So, please report any issue with ec_burst=1.

Thanks,
Luming


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hi Luming,

since I'm not able to get my ati-card or my ipw2200 up and running with this 
Kernel. I will have to solve this problems first. But afterwards i'll test 
again and let you know.

Thanks a lot for your assistance
	Olaf


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Olaf Jansen-Olliges]

Hello Luming, 

> Thanks for testing.  Without ec_burst=1,  the driver still use spin lock.
> If ec_burst=1 doesn't work for you, I will be a little supprised.

now i've got everything up and running with kernel 2.6.13-git6. 
And yes you are right. With your patch my machine is lucky again :-) Readout 
of battery is fast and with ec_burst=1 there seems to be no problem with 
missing keys.


Thanks again
	Olaf

P.S.: If i should do some special testing or you please let me know.

System:
Acer Extensa 3002 WLMI
gentoo linux with kernel-2.6.13-git6
ipw2200-1.0.6 (WPA with wpa_supplicant)
ATI fglrx 8.14.13


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Yu Luming]

On Tuesday 06 September 2005 11:25, Antoni Villalonga wrote:
> 2005/1/20, Rich Townsend :
> > Tonight's build:
> >
> > http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
>
> I'm sorry for reply an old mail.
> But, it's the last release of acpi_sbs kernel module?
>
> I know about sbs-linux project in sourceforge, but I get a big delay
> (about ~20 seconds) with my Acer TM 4001 when I try to read battery
> status.
Please try this patch:
http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73


>
> There are any way to fix it?
>
> Thanks!!
>
> (Sorry my English, I'm not an English speaker)


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[Antoni Villalonga]

2005/9/6, Antoni Villalonga:
> I know about sbs-linux project in sourceforge, but I get a big delay
> (about ~20 seconds) with my Acer TM 4001 when I try to read battery
> status.
> 
> There are any way to fix it?
> 
> Thanks!!

Thanks to Olaf and Yu!

It doesn't work for me, I don't have more time today at weekend I'll retry. :-)

THANKS!!

-- 
$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/k1uMJSBkQmQ@public.gmane.org


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[François Valenduc]

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

Antoni Villalonga a écrit :

>2005/9/6, Antoni Villalonga:
>  
>
>>I know about sbs-linux project in sourceforge, but I get a big delay
>>(about ~20 seconds) with my Acer TM 4001 when I try to read battery
>>status.
>>
>>There are any way to fix it?
>>
>>Thanks!!
>>    
>>
>
>Thanks to Olaf and Yu!
>
>It doesn't work for me, I don't have more time today at weekend I'll retry. :-)
>
>THANKS!!
>
>  
>
See the bug report here: 
https://sourceforge.net/tracker/index.php?func=detail&aid=1191536&group_id=129330&atid=714494
I have exactely the same laptop than you and I manage to read battery 
state without problem using a modified DSDT table. If you use kernels 
2.6.11 or 2.6.12, you can use the attached patch which includes the 
changes suggested in the bug report. If you use kernel 2.6.13, this 
patch doesn't apply cleanly. However, without extra patch, it works 
correctly for me.

François Valenduc

[-- Attachment #2: acpi-ec-nospinlock-2.6.11.diff --]
[-- Type: text/x-patch, Size: 5716 bytes --]

diff -urN linux-2.6.11.5-original/drivers/acpi/ec.c linux-2.6.11.5/drivers/acpi/ec.c
--- linux-2.6.11.5-original/drivers/acpi/ec.c	2005-03-21 15:58:25.000000000 +0000
+++ linux-2.6.11.5/drivers/acpi/ec.c	2005-03-21 16:03:55.000000000 +0000
@@ -31,6 +31,7 @@
 #include <linux/delay.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
+#include <asm/semaphore.h>
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
@@ -54,8 +55,8 @@
 #define ACPI_EC_EVENT_OBF	0x01	/* Output buffer full */
 #define ACPI_EC_EVENT_IBE	0x02	/* Input buffer empty */
 
-#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
-#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */
+#define ACPI_EC_MSLEEP		1	/* Sleep 1ms between polling */
+#define ACPI_EC_MSLEEP_COUNT	10	/* Wait 10ms max. during EC ops */
 #define ACPI_EC_UDELAY_GLK	1000	/* Wait 1ms max. to get global lock */
 
 #define ACPI_EC_COMMAND_READ	0x80
@@ -87,7 +88,7 @@
 	struct acpi_generic_address	command_addr;
 	struct acpi_generic_address	data_addr;
 	unsigned long			global_lock;
-	spinlock_t			lock;
+	struct semaphore		sem;
 };
 
 /* If we find an EC via the ECDT, we need to keep a ptr to its context */
@@ -106,7 +107,7 @@
 	u8			event)
 {
 	u32			acpi_ec_status = 0;
-	u32			i = ACPI_EC_UDELAY_COUNT;
+	u32			i = ACPI_EC_MSLEEP_COUNT;
 
 	if (!ec)
 		return -EINVAL;
@@ -118,7 +119,7 @@
 			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
 			if (acpi_ec_status & ACPI_EC_FLAG_OBF)
 				return 0;
-			udelay(ACPI_EC_UDELAY);
+			msleep(ACPI_EC_MSLEEP);
 		} while (--i>0);
 		break;
 	case ACPI_EC_EVENT_IBE:
@@ -126,7 +127,7 @@
 			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
 			if (!(acpi_ec_status & ACPI_EC_FLAG_IBF))
 				return 0;
-			udelay(ACPI_EC_UDELAY);
+			msleep(ACPI_EC_MSLEEP);
 		} while (--i>0);
 		break;
 	default:
@@ -137,7 +138,7 @@
 }
 
 
-static int
+int
 acpi_ec_read (
 	struct acpi_ec		*ec,
 	u8			address,
@@ -145,7 +146,6 @@
 {
 	acpi_status		status = AE_OK;
 	int			result = 0;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_read");
@@ -161,7 +161,10 @@
 			return_VALUE(-ENODEV);
 	}
 	
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_READ, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
@@ -180,7 +183,8 @@
 		*data, address));
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
@@ -189,7 +193,7 @@
 }
 
 
-static int
+int
 acpi_ec_write (
 	struct acpi_ec		*ec,
 	u8			address,
@@ -197,7 +201,6 @@
 {
 	int			result = 0;
 	acpi_status		status = AE_OK;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_write");
@@ -211,7 +214,10 @@
 			return_VALUE(-ENODEV);
 	}
 
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_WRITE, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
@@ -232,7 +238,8 @@
 		data, address));
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
@@ -284,14 +291,13 @@
 EXPORT_SYMBOL(ec_write);
 
 
-static int
+int
 acpi_ec_query (
 	struct acpi_ec		*ec,
 	u32			*data)
 {
 	int			result = 0;
 	acpi_status		status = AE_OK;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_query");
@@ -312,7 +318,10 @@
 	 * Note that successful completion of the query causes the ACPI_EC_SCI
 	 * bit to be cleared (and thus clearing the interrupt source).
 	 */
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_QUERY, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
@@ -324,7 +333,8 @@
 		result = -ENODATA;
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
@@ -348,7 +358,6 @@
 {
 	struct acpi_ec		*ec = (struct acpi_ec *) ec_cxt;
 	u32			value = 0;
-	unsigned long		flags = 0;
 	static char		object_name[5] = {'_','Q','0','0','\0'};
 	const char		hex[] = {'0','1','2','3','4','5','6','7',
 				         '8','9','A','B','C','D','E','F'};
@@ -358,9 +367,11 @@
 	if (!ec_cxt)
 		goto end;	
 
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		return_VOID;
+	}
 	acpi_hw_low_level_read(8, &value, &ec->command_addr);
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up(&ec->sem);
 
 	/* TBD: Implement asynch events!
 	 * NOTE: All we care about are EC-SCI's.  Other EC events are
@@ -623,7 +634,7 @@
 
 	ec->handle = device->handle;
 	ec->uid = -1;
-	spin_lock_init(&ec->lock);
+	sema_init(&ec->sem, 1);
 	strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
 	strcpy(acpi_device_class(device), ACPI_EC_CLASS);
 	acpi_driver_data(device) = ec;
@@ -832,7 +843,7 @@
 	status = acpi_evaluate_integer(handle, "_GPE", NULL, &ec_ecdt->gpe_bit);
 	if (ACPI_FAILURE(status))
 		return status;
-	spin_lock_init(&ec_ecdt->lock);
+	sema_init(&ec_ecdt->sem, 1);
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->handle = handle;
 
@@ -909,7 +920,7 @@
 	ec_ecdt->status_addr = ecdt_ptr->ec_control;
 	ec_ecdt->data_addr = ecdt_ptr->ec_data;
 	ec_ecdt->gpe_bit = ecdt_ptr->gpe_bit;
-	spin_lock_init(&ec_ecdt->lock);
+	sema_init(&ec_ecdt->sem, 1);
 	/* use the GL just to be safe */
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->uid = ecdt_ptr->uid;

Re: Re: Smart Battery System driver

[Antoni Villalonga]

2005/9/6, Antoni Villalonga:
> 2005/9/6, Antoni Villalonga:
> > I know about sbs-linux project in sourceforge, but I get a big delay
> > (about ~20 seconds) with my Acer TM 4001 when I try to read battery
> > status.
> >
> > There are any way to fix it?
> >
> > Thanks!!
> 
> Thanks to Olaf and Yu!
> 
> It doesn't work for me, I don't have more time today at weekend I'll retry. :-)
> 
> THANKS!!

It works now.

The delay of `cat /proc/acpi/battery/BAT0/state` its nearly 0.170 seconds.

Read form this file block my pc while it is reading.I advise it if i'm
moving the mouse or typing, it stop for a moment.

$ while true; cat /proc/acpi/battery/BAT0/state > /dev/null; done
It block totally the computer <:D

Thanks to all!

PS: I use linux-2.6.13

-- 
$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/k1uMJSBkQmQ@public.gmane.org


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[David Gómez]

Hi Antoni ;)

On Sep 06 at 05:25:24, Antoni Villalonga wrote:
> 2005/1/20, Rich Townsend :
> > Tonight's build:
> > 
> > http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
> 
> I'm sorry for reply an old mail.
> But, it's the last release of acpi_sbs kernel module?

It seems so. By the way, it doesn't compile against 2.6.13...

-- 
David Gómez                                      Jabber ID: davidge@jabber.org


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Smart Battery System driver

[ultrakorne]

Rich Townsend wrote:
> 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
> 

this works fine (no more interrupting the charge).
at every boot, with ac ever plugged i lost 1% of the charge, the led in 
front of the laptop is green ( full charge ) but the driver says 97%

thx again for your great work!


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

ultrakorne wrote:
> Rich Townsend wrote:
> 
>> 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
>>
> 
> this works fine (no more interrupting the charge).
> at every boot, with ac ever plugged i lost 1% of the charge, the led in 
> front of the laptop is green ( full charge ) but the driver says 97%

That's because the battery won't switch the charger on until the charge 
level drops below a certain value. Also, once the battery is fully 
charged, it begins slowly to discharge again. This is because the 
battery's internal circuitry requires a small amount of power.

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

[Bruno Ducrot]

On Mon, Jan 17, 2005 at 10:03:25PM -0500, Rich Townsend wrote:
> 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?

Exactly.  This must be implemented in i2c-acpi-ec, and a event notifier
sohuld be done in order to pass this to the children.  Also I have to
modify i2c-acpi-ec in order to make this driver event driven (we write to
the PCRTL, then wait for an event (query number will be 0x20 in this
perticular case) from the EC before processing further), and in the
handler, if the alarm bit is set, then notify the child.
That what I meant in a previous mail with 'overriden the _Q20',
by the fact that I think its only a dummy alarm ack in order to be
sure the smbus is still functionnal even if the OS do not provide
a driver for accessing the smbus.  I never meant to do this in DSDT.
I'm sorry for the confusion.

> *) perhaps the battery simply isn't generating the alarms?

This may be another trouble.


-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

Bruno Ducrot wrote:
> On Mon, Jan 17, 2005 at 10:03:25PM -0500, Rich Townsend wrote:
> 
>>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?
> 
> 
> Exactly.  This must be implemented in i2c-acpi-ec, and a event notifier
> sohuld be done in order to pass this to the children.  Also I have to
> modify i2c-acpi-ec in order to make this driver event driven (we write to
> the PCRTL, then wait for an event (query number will be 0x20 in this
> perticular case) from the EC before processing further), and in the
> handler, if the alarm bit is set, then notify the child.
> That what I meant in a previous mail with 'overriden the _Q20',
> by the fact that I think its only a dummy alarm ack in order to be
> sure the smbus is still functionnal even if the OS do not provide
> a driver for accessing the smbus.  I never meant to do this in DSDT.
> I'm sorry for the confusion.

OK, thanks for the clarification. Out of interest, how do I install 
event handlers for the EC? A quick look through ec.c doesn't show any 
obvious way to do it.

> 
> 
>>*) perhaps the battery simply isn't generating the alarms?
> 
> 
> This may be another trouble.

Yeah, I think that may be the real problem. Even without proper alarm 
handling in i2c-acpi-ec, the alarms sent by the battery should still 
show up in the _Q20 method I hacked into my DSDT. Is it possible to fake 
an SMBus alarm, to track whether it is getting through the EC driver 
code properly

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

[Bruno Ducrot]

On Tue, Jan 18, 2005 at 10:39:36AM -0500, Rich Townsend wrote:
> Bruno Ducrot wrote:
> >On Mon, Jan 17, 2005 at 10:03:25PM -0500, Rich Townsend wrote:
> >
> >>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?
> >
> >
> >Exactly.  This must be implemented in i2c-acpi-ec, and a event notifier
> >sohuld be done in order to pass this to the children.  Also I have to
> >modify i2c-acpi-ec in order to make this driver event driven (we write to
> >the PCRTL, then wait for an event (query number will be 0x20 in this
> >perticular case) from the EC before processing further), and in the
> >handler, if the alarm bit is set, then notify the child.
> >That what I meant in a previous mail with 'overriden the _Q20',
> >by the fact that I think its only a dummy alarm ack in order to be
> >sure the smbus is still functionnal even if the OS do not provide
> >a driver for accessing the smbus.  I never meant to do this in DSDT.
> >I'm sorry for the confusion.
> 
> OK, thanks for the clarification. Out of interest, how do I install 
> event handlers for the EC? A quick look through ec.c doesn't show any 
> obvious way to do it.

Simple.  Need to add this into ec.c ;)

> 
> >
> >
> >>*) perhaps the battery simply isn't generating the alarms?
> >
> >
> >This may be another trouble.
> 
> Yeah, I think that may be the real problem. Even without proper alarm 
> handling in i2c-acpi-ec, the alarms sent by the battery should still 
> show up in the _Q20 method I hacked into my DSDT. Is it possible to fake 
> an SMBus alarm, to track whether it is getting through the EC driver 
> code properly

I don't know.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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