New SmartBattery DSDT-based controller

New SmartBattery DSDT-based controller

[Rich Townsend]

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

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

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

Re: Re: New SmartBattery DSDT-based controller

[Rich Townsend]

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>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).
> 
> 
> 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.

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

> 
> Good job, Richard!

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

> The i2c device stuff doesn't work simultaneously because the original
> SMBus controller section in the DSDT has been commented out.

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

Re: Re: New SmartBattery DSDT-based controller

[Rich Townsend]

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>The i2c device stuff doesn't work simultaneously because the original
>>SMBus controller section in the DSDT has been commented out.
> 
> 
> 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!

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.

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

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

Re: Re: New SmartBattery DSDT-based controller

[Karol Kozimor]

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

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/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: New SmartBattery DSDT-based controller

[Matthew Garrett]

On Sun, 2005-01-30 at 08:38 -0500, Rich Townsend wrote:

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

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 | 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: New SmartBattery DSDT-based controller

[Matthew Garrett]

On Sat, 2005-01-29 at 14:02 -0500, Rich Townsend wrote:

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

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 | 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: New SmartBattery DSDT-based controller

[Rich Townsend]

Matthew Garrett wrote:
> On Sat, 2005-01-29 at 14:02 -0500, Rich Townsend wrote:
> 
> 
>>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.
> 
> 
> 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.
> 

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> writes:

> The alternative approach of modifying the user's DSDT on the fly is
> likely to be excessively fragile.

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

Re: New SmartBattery DSDT-based controller

[Pavel Machek]

Hi!

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

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

Re: New SmartBattery DSDT-based controller

[Pedro Venda]

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

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

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

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

Re: Re: New SmartBattery DSDT-based controller

[David Goodenough]

On Monday 31 January 2005 09:50, Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> > 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).
>
> 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"?

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

David
>
> -- 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: New SmartBattery DSDT-based controller

[Johan Vromans]

David Goodenough <david.goodenough-6b45v/Ft3lbby3iVrkZq2A@public.gmane.org> writes:

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

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

Johan Vromans <jvromans-2pNSKKP3PSKEVqv0pETR8A@public.gmane.org> writes:

>> This would be wonderful.  Do you know of a patch that implements this?
>
> No, but I'll take a look.

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

Re: Re: New SmartBattery DSDT-based controller

[Rich Townsend]

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>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).
> 
> 
> 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"?

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

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

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

Re: New SmartBattery DSDT-based controller

[Bruno Ducrot]

On Sat, Jan 29, 2005 at 02:02:58PM -0500, Rich Townsend wrote:
> Dear All,
...

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

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:

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

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

Re: Re: New SmartBattery DSDT-based controller

[Karol Kozimor]

Thus wrote Johan Vromans:
> Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:
> 
> > That means that if someone owns a tm4502lmi, but different amount of
> > RAM, then all of those ORs will likely fail.
> 
> Interesting. So if I take my notebook to the dealer to add another
> 512Mb of RAM, they replace the DSDT as well?

No, the DSDT is usually auto-generated by BIOS.
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: New SmartBattery DSDT-based controller

[Ville Syrjälä]

On Mon, Jan 31, 2005 at 04:39:09PM +0100, Johan Vromans wrote:
> Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:
> 
> > That means that if someone owns a tm4502lmi, but different amount of
> > RAM, then all of those ORs will likely fail.
> 
> Interesting. So if I take my notebook to the dealer to add another
> 512Mb of RAM, they replace the DSDT as well?

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ä
syrjala-ORSVBvAovxo@public.gmane.org
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

Re: Re: New SmartBattery DSDT-based controller

[Bruno Ducrot]

On Mon, Jan 31, 2005 at 04:39:09PM +0100, Johan Vromans wrote:
> Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:
> 
> > That means that if someone owns a tm4502lmi, but different amount of
> > RAM, then all of those ORs will likely fail.
> 
> Interesting. So if I take my notebook to the dealer to add another
> 512Mb of RAM, they replace the DSDT as well?
> 

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:

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

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

Re: Re: New SmartBattery DSDT-based controller

[Bruno Ducrot]

On Mon, Jan 31, 2005 at 06:48:41PM +0100, Johan Vromans wrote:
> Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> writes:
> 
> > Most, if not all, ACPI tables are generated at POST.
> 
> Interesting. So this makes overriding the DSDT (using a compiled in
> version, or the initrd method) a hazardous exercise?
> 

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

Re: New SmartBattery DSDT-based controller

[Rich Townsend]

Bruno Ducrot wrote:

<snip>
> 
> You should provide at least diffs or else be prepared for rewrite some.

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.

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

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

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

Re: New SmartBattery DSDT-based controller

[Bruno Ducrot]

On Mon, Jan 31, 2005 at 11:34:49AM -0500, Rich Townsend wrote:
> >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)?
> 
> 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/*

This is part of long goal indeed.

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

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

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

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

Re: New SmartBattery DSDT-based controller

[Karol Kozimor]

Thus wrote Rich Townsend:
> >That means that if someone owns a tm4502lmi, but different amount of
> >RAM, then all of those ORs will likely fail.
> 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 

And it's precisely so, though perhaps not in every possible case.
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

sbs-linux: smart batteries on SourceForge (was New SmartBattery DSDT-based controller)

[Rich Townsend]

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

Re: sbs-linux: smart batteries on SourceForge (was New SmartBattery DSDT-based controller)

[François Valenduc]

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

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

Rich Townsend a écrit :

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


[-- Attachment #2: dsdt.bz2 --]
[-- Type: application/octet-stream, Size: 25736 bytes --]

Re: sbs-linux: smart batteries on SourceForge (was New SmartBattery DSDT-based controller)

[Olaf Jansen-Olliges]

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

Hello Francoise, (sorry for the missing cedille), 

Am Sonntag, 6. Februar 2005 14:33 schrieb François Valenduc:
> 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.

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/


[-- Attachment #2: DSDT.aml --]
[-- Type: application/octet-stream, Size: 26211 bytes --]

Re: sbs-linux: smart batteries on SourceForge

[Johan Vromans]

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

> I've finished the first cut of the DSDT hackery needed to get smart
> battery systems (SBS) working like 'traditional' control method (CM)
> batteries. 

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

Re: sbs-linux: smart batteries on SourceForge

[Johan Vromans]

Johan Vromans <jvromans-2pNSKKP3PSKEVqv0pETR8A@public.gmane.org> writes:

> Do your chages for TravelMate4001 still disable I2C access?

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

Re: Re: sbs-linux: smart batteries on SourceForge

[Rich Townsend]

Johan Vromans wrote:
> Johan Vromans <jvromans-2pNSKKP3PSKEVqv0pETR8A@public.gmane.org> writes:
> 
> 
>>Do your chages for TravelMate4001 still disable I2C access?
> 
> 
> Yes, they do.
> Rich, is there a real need to do so?
> 

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

Re: sbs-linux: smart batteries on SourceForge

[Johan Vromans]

[Quoting Rich Townsend, on February 6 2005, 13:34, in "Re: sbs-linux: smart"]
> > Do your chages for TravelMate4001 still disable I2C access?
> 
> Yes, they do. I found weird behaviour arises if I2C access remains 
> enabled. I'm looking further into this, because I would prefer to keep 
> the I2C stuff going.

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

Re: sbs-linux: smart batteries on SourceForge

[Johan Vromans]

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

> Full instructions are provided in the accompanying README file.

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

Re: Re: sbs-linux: smart batteries on SourceForge

[Rich Townsend]

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>Full instructions are provided in the accompanying README file.
> 
> 
> 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

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

Re: Re: sbs-linux: smart batteries on SourceForge

[David Goodenough]

On Monday 07 February 2005 12:06, Rich Townsend wrote:
> Johan Vromans wrote:
> > Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> >>Full instructions are provided in the accompanying README file.
> >
> > 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
>
> 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?
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
>
> 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: sbs-linux: smart batteries on SourceForge

[Hendrik Jürgens]

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

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

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

Re: Re: New SmartBattery DSDT-based controller

[Rich Townsend]

Johan Vromans wrote:
> Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
> 
> 
>>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.
> 
> 
> 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?

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

Re: New SmartBattery DSDT-based controller

[Johan Vromans]

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

> However, I should mention that, long-term, I see the acpi-sbs module
> as *sort of* the way to go. 

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