New SmartBattery DSDT-based controller

Dear All,

I've been quiet with recent updates on my Smart Battery driver, because I've been digging deeper into how smart batteries are dealt with in a variety of systems. What I've found is this: at the most basic level, there are three ways of dealing with smart batteries (or for that matter, any SMBus-based device) that are run by an ACPI-aware embedded controller (EC):

1) Direct fiddling with the SMBus registers that make up part of the EC address space. This is what Bruno Ducrot's i2c-acpi-ec module was for:
it exposed kernel-space functions to allow one to perform the required fiddling. My acpi-sbs module then used these functions to examine the status of the smart battery.

2) The use of an SMBus operating region, which makes each SMBus device (i.e., battery, charger, selector, system manager) look like a set of registers that can be read from or written to. Although quite elegant, this approach requires a corresponding address space driver to be implemented in the operating system (unlike approach 1 above). Unfortunately, no such implementation currently exists for Linux.

3) The use of ACPI methods, as specified by the SMBus Control Method
Interface specification. These present a unified, consistent interface
to the SMBus, but internally may rely on a variety of approaches (such
as 1 above) to do the actual hardware control. This SMBus-CMI approach can be used with non-EC SMBus segments as well.

In most smart battery systems, these details are hidden from the
operating system, since the DSDT contains device definitions (BAT0,
BAT1, BAT2 etc) that make the smart battery appear -- to the OS -- like
a traditional Control Method (CM) battery. Laptop manufacturers that I've seen do this include Compaq, Gateway & Sony. HOWEVER, some manufacturers -- Acer in particular -- have not included the CM code in their DSDT, preferring to rely instead on a set of software-based tools to examine the battery status (most likely, via approach 1 above). And, of course, these tools are Windows specific.

This is where my new DSDT stuff comes in: I have written the necessary DSDT code to add CM definitions for smart-battery based systems. I've tried to make this code as platform-independent as possible, by accessing the SMBus where possible via approach 3 (the uniform SMBus Control Method Interface), but there is still a certain degree of platform dependence to the code.

So it looks like the best way to move forward at the moment is:

1) Get a copy of your DSDT
2) Send it to me, with the *full* make/model of your machine
3) I'll add in the CM definitions to your DSDT
4) I'll post the modified DSDT on my website.
5) Download the modified DSDT, and install it following the instructions at http://forums.gentoo.org/viewtopic.php?t=122145 (see section 9; although in Gentoo forums, these instructions should work on most systems).

Eventually, the modified DSDTs can be put back into the ACPI4Linux database; but I'm more interested at the moment in ironing out any glitches in the code.

To get the ball rolling, I have on my website the two modified DSDTs:

Acer TravelMate 4502lmi:
http://shayol.bartol.udel.edu/~rhdt/download/tm4502lmi-sbs-cm.aml
(this is my own 1.6GHz Centrino machine, I've confirmed this works)

Acer TravelMate 4001wlmi:
http://shayol.bartol.udel.edu/~rhdt/download/tm4001wlmi-sbs-cm.aml
(this is based on the *fixed* DSDT posted on Johan Vromans' web page, for his 1.5Ghz Centrino machine; I've not been able to test it, but I expect it to work).

These of course can be converted into source code using an AML disassembler, but if you want to see the code that these DSDTs were compiled from (including lots of comments on the new CM code), just change the extension from .aml to .asl in the URL.

I look forward to DSDTs and bug reports!

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

As far as I can see, works like a charm.
Compiling the DSDT gives a couple of warnings, but these seem harmless. For an unknown reason I can't currently access the i2c devices, so I cannot compare the output of both methods.

Good job, Richard!

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

The warnings are nothing to worry about; the methods defined by the SMBus Control Method Interface have reserved names, in that they begin with underscores, and that causes the compiler to whine a little.

The i2c device stuff doesn't work simultaneously because the original SMBus controller section in the DSDT has been commented out. I figured that there wouldn't be much use for it, but you can try uncommenting it in the source code and recompiling. Look for the device named "SMBS".

Glad it works! I'm still trying to get the alarm polling working properly, this looks on the whole to be a good solution.

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

Okay, fixed. Everythng seems to be up an running, and both the new batery (hmm, am I experiencing character loss here, or is it my typing?) status and the i2c method give consistent results. Again, good work!

While we're at it -- did you manage to control the fans? I can read the status, and write to it, but I do not hear a difference.

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

You probably *are* experiencing character loss. I still haven't fixed the problem that low-level EC access can sometimes lead to lost interrupts. I've tried to mitigate the problem by putting a 1ms sleep after each access, but that isn't perfect.

However, I'm glad you're getting consistent results with the i2c method.

Nah, but I'll have a dig around.

BTW, a warning for those with Smart Batteries (or, for that mattery, any LiIon battery): you can damage your battery by running it all the way to empty. I kind of knew about this already, from stuff I'd read on the internet; but I got a nasty reminder last night. I ran my battery to empty, to see which smart battery alarms went off (disappointing; there were no alarms triggered, and only a single warning flag was set ~5 secs before empty). Unfortunately, this procedure led to the loss of ~3% of my battery capacity.

Maybe when I get the in-the-works SourceForge project going, I'll set up a PayPal donation fund for a new battery :).

cheers,

Rich

PS Overnight, I got a number of new DSDTs from various people; I'll be fixing these today and posting them on the website.

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

Thus wrote Rich Townsend:

While it's possible, it's very unlikely. More probably your fuel gauge just recalibrated itself to compensate for the gradual capacity loss. While it's true Li-Ion cells don't like to be completely discharged, it's hardly possible to do so under normal conditions. The power requirements of a typical notebook cause the current to be cut off before the cell voltage drops below the dangerous level. That said, the capacity also degrades with time, temperature and the number of charges, so any of these could be involved.

Standard disclaimer: the above is not meant to be authoritative.

Best regards,

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


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

This is unlikely - the battery will prevent itself from being overly discharged. However, LiIon batteries will lose some amount of capacity over time anyway. What you're probably seeing is the battery recalibrating itself (ie, you'd already lost 3% of capacity, and the battery was just lying to you about how charged it was)

Matthew Garrett | [email protected]



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

While this is a neat hack, there's no real way that distributions are ever going to adopt this approach - DSDTs are copyrighted by the vendors, and without permission they're not going to be distributed by the Linux vendors. The alternative approach of modifying the user's DSDT on the fly is likely to be excessively fragile. The only reasonable solution is to provide a mechanism to read the battery directly.

Matthew Garrett | [email protected]



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

Yeah, this has occurred to me. I'm looking into cooking up some Perl, to allow the users to modify their own DSDTs. Of course, this is never going to be user friendly, and a long-term solution, as you say, is to read the battery directly.

That's what my acpi-sbs module already does, but I'm reluctuant to spend much time developing the module further, until some form of uniform battery interface for the kernel is designed and implemented. Having two seperate /proc/acpi interfaces, one for CM batteries and one for smart batteries, is not the way to go.

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

Maybe I'm missing something, but isn't the AML interpreter part of the OS? In that case, it should be possible to have the additional DSDT code inserted 'on the fly'.

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

Hi!

Actually, it is now time to call Acer saying "hey, Linux community actually did the work for you; add this to your BIOS and your batteries will start to work under Linux as control-method batteries". It would help if you could release that DSDT part under public domain; it is unlikely that Acer is going to put GPLed part into their BIOS.
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

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

hello,

I don't have time to try it out until about the end of next month, but I will indeed test it.

Again thanks for your work and dedication on this annoying issue.

As I've said before...

| So it looks like the best way to move forward at the moment is:
|
| 1) Get a copy of your DSDT
| 2) Send it to me, with the *full* make/model of your machine
| 3) I'll add in the CM definitions to your DSDT
| 4) I'll post the modified DSDT on my website.
| 5) Download the modified DSDT, and install it following the instructions
| at http://forums.gentoo.org/viewtopic.php?t=122145 (see section 9;
| although in Gentoo forums, these instructions should work on most systems).

Do you really think this is as simple as running a perl script? Ok, these are debug builds, but will you produce DSDTs for every laptop model with a smartbattery someone owns and asks you to patch their DSDT like in an assembly line?

While it's definately the most elegant, I'm sorry, but I still don't see future for this method.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/Pn/eRy7HWZxjWERAh5hAKDJMeIgxIVpxu/fJ8ukHRodVBVSaQCgzr8a XWYV49SFdSVqtVE+SF+V4cQ=
=oOcm
-----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

Although appending the DSDT to the initrd is a neat trick, wouldn't it be better to have a kernel boot parameter, e.g. "dsdt_override=myDSDT.aml"?

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

This would be wonderful. Do you know of a patch that implements this?

David

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

No, but I'll take a look.

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

Seems to be a bit harder than I expected. At the point where the ACPI table is overridden, you cannot do anything yet (in particular, no disk I/O)... So the only way to implement this would be to get the DSDT table from the initrd, making the 'improvement' to the current initrd patch not worth the trouble.

On a side note: wouldn't it be better if the initrd patch started to look for the DSDT signature *backwards* from the end? This would guarantee that always the last DSDT appended is used. In other words, updating the initrd is easy: just append a new signature + table. If you're like me, you'll probably going to build a new kernel + new initrd way before it gets to big ...

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

One of the approaches mentioned in the Gentoo forums guide (section 9b, IIRC), is almost equivalent to this: within grub, the extra line "initrd=myDSDT.aml" is added beneath the kernel line. However, I agree that it would be better if this could be done using a kernel parameter; I think it is not too unreasonable to expect "normal" users to mess around with kernel parameters.

My current thinking of the best way to incorporate the DSDT modifications, is to do it via patches. This would avoid the clumsiness of having a large on-line database of modified tables, and also circumvent any copyright issues.

Thanks to all who have already sent me DSDTs to fix; I'll be publishing patches to these tables Real Soon Now. At the moment, I'm re-implementing the SMBus control method interface, to replace the reference implementation taken from appendix B of the SMBus-CMI specification.

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

AFAIK, this only designates the initrd to be used. The 'load DSDT from initrd' patch uses this to read the DSDT, however, this only works if you do not already have an initrd. In the latter case, the 'signature trick' must be used to append the DSDT to the existing initrd.

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

...

You should provide at least diffs or else be prepared for rewrite some. THere is those stuff in those ASLs:

ducrot@neptune:~/acpi_hack$ grep SystemMemo tm4502lmi-sbs-cm.asl
    OperationRegion (MNVS, SystemMemory, 0x1DEECE59, 0x60)
                OperationRegion (VNVS, SystemMemory, 0x1DEECEB9, 0x00010004)
                OperationRegion (SMI1, SystemMemory, 0x1DEFCEBD, 0x00000090)

That means that if someone owns a tm4502lmi, but different amount of RAM, then all of those ORs will likely fail.

I don't see the point of making this if this is only for smartbatt. Do you have to override the DSDT for something else (and then, well, why not)?

Cheers,

Bruno Ducrot

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


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

Interesting. So if I take my notebook to the dealer to add another 512Mb of RAM, they replace the DSDT as well?

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

Thus wrote Johan Vromans:

No, the DSDT is usually auto-generated by BIOS.
Best regards,

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


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

No, the BIOS modifies the DSDT. This also happens for other stuff like enabling and disabling intergrated peripherals from the BIOS. At least on one of my laptops the BIOS renames some of the device's methods when the device is disabled (_PRS -> B_PR, _DIS -> B_DI etc.)

Ville Syrjälä
[email protected]
http://www.sci.fi/~syrjala/


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

Of course not. Most, if not all, ACPI tables are generated at POST.

Cheers,

Bruno Ducrot

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


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

Interesting. So this makes overriding the DSDT (using a compiled in version, or the initrd method) a hazardous exercise?

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

See for example
http://marc.theaimsgroup.com/?l=acpi4linux&m=103146429324320&w=4
and
http://marc.theaimsgroup.com/?l=acpi4linux&m=103184128003152&w=4

It's not exactly an hazardous exercise, but you may experience some strange logs errors if you blindly override DSDT.

Cheers,

Bruno Ducrot

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


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

Bruno Ducrot wrote:

<snip>

Yep, I realized this once I had sent my original email. Also, diffs get around the copyright issue of posting vendors' ASL on the web.

I would be very surprised by this. If this were true, a simple RAM upgrade would invalidate the DSDT --- certainly not the case. But as I say, your point about diffs is well made.

Maybe sometimes things are better done by fixing the DSDT, rather than adding more bloat into the kernel. And I use the word 'fixing' carefully; many modern laptops use smart batteries, but expose these batteries to the OS via the tradition Control Method (CM) interface. In that sence, Acer's DSDTs are broken, because they lack the necessary CM wrapper for the smart battery system (SBS).

There's certainly a case to be made that smart batteries should be dealt with natively in the kernel, since an SBS has many more data than a CM interface can expose. However, there are a number of design questions that need to be addressed before this issue can be tackled in a proper manner (I consider my acpi-sbs module to be little more than a proof-of-concept). In particular,

*) Others have pointed out that a unified kernel API for batteries & power sources is required, to hide the messy CM vs. SBS details away. What should this API do? Will it provide /proc entries? How will it keep backward compatibility with all of those applications that look in /proc/acpi/battery/*

*) How should we deal with systems that present a CM interface in their DSDT, but are internally implemented using SBS? Should the DSDT interface be bypassed, to expose the full SBS data?

*) With SBS being accessed via the SMBus, how do we deal with the messyness of having ACPI-related code depend on I2C code? Should the SMBus access be performed totally independent of the rest of the kernel I2C framework?

Just some thoughts...

On a final note: yes, I know the DSDT hacking solution seems awful to those who would rather do it all in the kernel. However, my viewpoint is this: I had an itch to scratch. I have scratched it. Others can scratch too. Don't sweat over the elegance of the scratching, it will all come out OK in the end...

cheers,

Rich

PS To all who have sent me their DSDTs: thanks, I'll be releasing a set of patches later on this week. Sit tight!

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

This is part of long goal indeed.

Yes and no. The kernel really need only a few (especially gauge stuff). The rest should be done in userspace IMHO.

Just that I don't see why you don't want your own acpi-sbs stuff, with some kind of compatibility with existing acpi/ac /proc interface. Thats this exact point I don't see the light yet. I don't have the hardware to play with, btw. Just... well, maybe I will see the light soon.

Cheers,

Bruno Ducrot

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


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

Thus wrote Rich Townsend:

And it's precisely so, though perhaps not in every possible case. Best regards,

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


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

Hi all --

I've finished the first cut of the DSDT hackery needed to get smart battery systems (SBS) working like 'traditional' control method (CM) batteries. This sounds like a kludge, but it's worth pointing out that many modern laptops already use SBS batteries internally, but expose them as CM batteries.

The new code can be downloaded from the new SourceForge project I've established:

https://sourceforge.net/projects/sbs-linux/

The package to download is SBS-CM-20050205. Basically, this package provides patches against the DSDT (in source form, as decompiled using the Intel compiler), that adds in the SBS-CM support. Full instructions are provided in the accompanying README file.

The following systems are "supported":

*) Acer Extensa 3002WLMi
*) Acer TravelMate 4000LMi
*) Acer TravelMate 4001LMi
*) Acer TravelMate 4001WLMi
*) Acer TravelMate 4002LMi
*) Acer TravelMate 4502LMi
*) Acer TravelMate 4502WLMi
*) Acer Extensa 3202XCi

I'm currently working on the Acer Aspire 1692WLMi, which already contains a broken SBS-CM implementation. The Acer TravelMate 382 and Ferrari 3400 also already contain SBS-CM implementations, but I'm not sure to what extent they work or not.

As well as the DSDT patches, I provide in the package my embedded controller patch, that improves the EC responsiveness by switching from spinlocks to semaphores. I've tried out the other patches mentioned recently on this list, but they either don't work, or reduce EC access rates to a crawl.

Note that battery events, including alarms, are properly handled; so you should get notifications in /proc/acpi/event when something interesting happens. In tandem with acpid, you can use these notifications to, e.g., shutdown your system when the battery gets low.

Bug reports, feature requests, etc, should be submitted using the SourceForge project page -- not to the acpi-devel list, since it would be a bit rude to flood the list with this stuff. But of course, general smart battery discussion should continue on acpi-devel.

Happy battery monitoring!

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

Hello everybody,
Finally I found a recent IASL binary which seems to work. However, the use of this customized DSDT is not satisfactory. First, the FAN is now always on. Second, when the battery is fully loaded, the battery level is reported at 9% of remaining capacity. I own an ACER Travelmate 4001Lmi, so I tried the patch dedicated to this model, but the result is not correct. The only positive point is that the bug addressed with the patch acpi-ec-nospinlock doens't seem to occur. There is no loss of reactivity when I use the SBS-CM method to access the battery. I have put in the attachement the original an pacthed DSDT table.

Thanks for your help,
François Valenduc

Hello Francoise, (sorry for the missing cedille),

Am Sonntag, 6. Februar 2005 14:33 schrieb François Valenduc:

when I'am right you have used the Version 20040715 of iasl. When i use this version my Machine missbehaves as well ;-) It even shuts down immediately. I've patched and compiled a version for your laptop with version 20051203.

Pehrhaps you may give this on a try.

Olaf

P.S.: eventually we should use toe sourceforge forum to discuss this issue - as purposed by Rich --> https://sourceforge.net/projects/sbs-linux/

Good work!

Do your chages for TravelMate4001 still disable I2C access?

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

Yes, they do.
Rich, is there a real need to do so?

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

Well, I found that parts of the SBS-CM stuff stopped working with the I2C access enabled. I'm still looking into this, but for the moment it seems that I2C must be disabled.

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

[Quoting Rich Townsend, on February 6 2005, 13:34, in "Re: sbs-linux: smart"]

That would be very nice.
Just for the record, I'm running 'your' SBS-DSDT right now, with no apparent problems (I used the compiled-in DSDT technique).

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

If I understand the instructions correctly, _every_ change to the BIOS settings would require me to:
- boot a non-DSDT-overriding kernel
- extract the (possibly modified) DSDT
- repeat the patch procedure, building a new DSDT
- strip the old one from my initrd, and append the new DSDT
- reboot the new kernel

This is quite cumbersome.
Is there any insight in what changes to BIOS settings would lead to changes in the DSDT?

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

Things like enabling/disabling mobo devices such as the parallel and serial ports; changing the power policies; modifying the IRQ assingment stuff.

But how often does one do all this, once one's laptop is properly configured?

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

I suppose the next question is can I do any harm by using a DSDT that is out of step with that the BIOS thinks it should be, or I just loose the effect of the change I have made?

David

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

Hi!

have another problem with my smartbattery.
My clock is going wrong after using der sbs interfaces (DSDT-Fix and also the userspace interface). For example after 5h of running time and using a battery monitor (could also be watch cat /proc...) my clock is about 30 minutes behind current time. =( i've tested it without any battery driver and theres no "lagging" of my clock.

Hendrik

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Actually, I think this approach has it attractive sides as well. I'm currently using your acpi-sbs snapshot of 20050120. Did you produce anything better before you switched to the DSDT approach?

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

No, I got sidetracked by the DSDT stuff (and by my 3 month-old daughter!).

However, I should mention that, long-term, I see the acpi-sbs module as *sort of* the way to go. But first, we need a proper framework for dealing with batteries under Linux, that exposes a unified interface to userspace. This framework would abstract away all of the hardware dependent stuff, so that whether a system has a CM battery or an SBS battery, it appears exactly the same outside the kernel. The "future" acpi-sbs module would be implemented as part of this framework, as would a new module for CM batteries.

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

I fully agree. For most purposes, the current acpi-sbs module already performs a great job. Most userspace tools function correctly with the CM 'emulation'. There may be parts missing, though.

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