ThinkWiki - User contributions [en]

Talk:Tp smapi

2008-02-15T15:05:40Z

Runia: add: comment to smapi/hdaps kernel oops

== Feedback ==

Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.

--[[User|StefanSchmidt]]

force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.

About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)

''(deleted, see below for how to create a patch file)''

Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.

Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?

Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)

A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:

1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.

----

Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).

On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).

About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.

The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

[[User:roam|roam]] 13:43, 11 January 2008 (CET)

I need invert=1 for hdaps. The additional invert parameters (2-7) didn't work for me with tp_smapi 0.33. They work with 0.34.

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

Have you developed this further since then? I just got my first dual-battery-setup for my Z60m. Anyway, it says it doesn't support hotplugging the battery? What does this mean? Do things break if I change batteries or switch a DVD drive to the ultrabay slot while it's running?

Anyway, I deciphered your source code enough that it basically seems to poll the stuff under /sys/devices/platform/BAT?/* every 10 seconds. Anyway, I don't see what's so tough about hotswapping - the BAT1 directory does not seem to vanish either by issuing echo 1 > /sys/devices/platform/bay.0/eject or just yanking it out. The /sys/devices/platform/BAT1/installed goes to zero though.

Can you add a check to the condition if (b0->on_ac == 0) ...change this to

if ((b0->on_ac == 0) && (b0->installed == 1) && (b1->installed == 1))

then the equal discharging logic would handle hotswapping too (ie. situations where you're running only on 1 battery instead of 2).

I hope you keep on honing this.

One of the few things I miss from Dell is that when operating with dual batteries, it discharges both of them evenly.

--[[User:Zarhan|Zarhan]] 18:31, 13 May 2007 (CEST)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)

The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
[[category:X60]]
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.

--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)

Is this consistently reproducible? What's the oops message and stackdump (you can snap a digicam shot)? Does this happen when...
* rebooting with tp_smapi loaded but hdaps not loaded?
* rebooting with neither tp_smapi nor hdaps loaded?
* rebooting with vanilla hdaps loaded (instead of the tp_smapi version)?
* removing just these modules ("rmmod") instead of rebooting?

--[[User:Thinker|Thinker]] 01:56, 17 April 2007 (CEST)
----

Hey Thinker,
Sorry, failed to follow the thread. Didn't pay attention to that bug any more. Skipped use of smapi on next kernel release for some reason. IRC, the panic could be prevented running the kernel w/o hdaps loaded.. hdaps didn't work out correctly for me anyway..

Cheers,

--[[User:Runia|Runia]] 16:05, 15 February 2008 (CET)

== battery start/stop thresholds saved after reboot? ==

Hi

Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)

On my x61s, these values are remembered after powering off the ThinkPad while it is on battery. I didn't try to remove the battery. But it looks like the x61s behaves as Thinker described, not as Hmh did.

--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)

Curious. That would mean the x61s does not power off the EC even while on battery and powered off, or that it is storing the SMAPI thresholds away in CMOS. Care to test it? If you want to check that theory, just hexdump /dev/nvram, change a threshold, than hexdump it again...

--[[User:Hmh|hmh]] 12:09, 11 November 2007 (UTC)

Seems like it's the former choice: I didn't see any nvram changes after changing the thresholds. Shutting down the system while on battery does not reset thresholds. Shutting down while on battery and then removing the battery does reset them to start_charge_threshold=96, stop_charge_threshold=100, though. I guess they put the EC in some low-power sleep mode while the notebook is turned off and on battery. The specs linked from [[Embedded_Controller_Chips]] list sleep mode currents below 5µA, which is probably negligible compared to self-discharge of Li-Ion batteries.

--[[User:Jannic|Jannic]] 14:36, 12 November 2007 (UTC)

== stop_charge_thresh on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).

----

Same problem, I want to know what I can do to help figure out why this works in windows and not with tp_smapi.<br>I am running tp_smapi 0.32 on 2.6.20 Ubuntu Feisty (7.04)<br>Here is the debug output from tp_smapi.<br>
{{cmdroot|echo 30 > /sys/devices/platform/smapi/BAT0/start_charge_thresh}}<br>
{{cmdroot|dmseg}}
<pre>[68311.752000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0
[68311.812000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38
[68311.812000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
[68311.812000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS
[68311.812000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0
[68311.868000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0
[68311.868000] smapi smapi: smapi_request: req_in: BX=2117 CX=11d DI=0 SI=0
[68311.924000] smapi smapi: smapi_request: req_out: AX=80 BX=2117 CX=11d DX=b2 DI=0 SI=0 r=0
[68311.924000] smapi smapi: set_real_thresh: set start to 29 for bat=0</pre>
{{cmdroot|echo 85 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh}}<br>
{{cmdroot|dmesg}}
<pre>[68385.652000] smapi smapi: smapi_request: req_in: BX=2116 CX=100 DI=0 SI=0
[68385.708000] smapi smapi: smapi_request: req_out: AX=80 BX=2116 CX=31d DX=b2 DI=0 SI=0 r=0
[68385.708000] smapi smapi: smapi_request: req_in: BX=211a CX=100 DI=0 SI=0
[68385.764000] smapi smapi: smapi_request: req_out: AX=8680 BX=211a CX=100 DX=b2 DI=0 SI=0 r=-38
[68385.764000] smapi smapi: smapi_request: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
[68385.764000] smapi smapi: __get_real_thresh: cannot get stop_thresh of bat=0: Function is not supported by SMAPI BIOS</pre>
<p>

--[[User:Airbornespent|Airbornespent]] 16:18, 13 August 2007 (UTC)
----

Looks like the T42(p) is using a different SMAPI interface for the stop threshold. For example, it could be using the same interface as inhibit_charge_minutes_interface, and monitoring the charge levels manually. Maybe you can use a debugger (e.g., SoftICE) to find out what SMAPI calls are made when you change the thresholds under Windows.

--[[User:Thinker|Thinker]] 17:40, 13 August 2007 (UTC)
----

What BIOS and EC version? If a T42/p is doing this, all the T4X but the two T43 types should also suffer the same problem... Not to mention a bunch of R5x models, etc (BIOS TP-1R).

--[[User:Hmh|hmh]] 23:17, 13 August 2007 (UTC)
----

This is copy and pasted from the DMI info I put on the DMI list page yesterday:
1RETDPWW (3.21 ) 06/02/2006 Handle 0x0029, DMI type 11, 5 byte String 1: IBM ThinkPad Embedded Controller -[1RHT71WW-3.04 ]-

I just noticed that the T40 through the T42p use this EC model. The T43s are different. No one with a T40-T42 has claimed success with the stop_charge_thresh on the tp_smapi status table.

I will try to get windows on a harddrive and pop it in my t42p to use softICE or whatever debuggers soon.

--[[User:Airbornespent|Airbornespent]] 15:39, 15 August 2007 (UTC)
----

I've installed windows, I can again confirm that the start and stop thresholds work with the maximiser. I couldn't seem to find softICE but I got a debugger called syser. I have no clue what I should be looking for though, a certain set of CPU calls, addresses, etc? Any advice would be great. If you are more familiar with softICE I will find and install that.

I just had an idea though. Maybe I can set the thresholds to known values in windows, and then reboot to linux without removing the AC, then the thresholds would be saved on the EC. Is there then a way I can dump the settings in linux and if I do this with several known thresholds that might be enough information to figure this out?

--[[User:Airbornespent|Airbornespent]] 19:48, 15 August 2007 (UTC)
----

You need to trace the SMAPI calls made when the thresholds are changed. You can look at tp_smapi.c or the vanilla kernel drivers/char/mwave/smapi.c to see how SMAPI work. Basically, the parameters are loaded into registers, with the SMAPI function code in register EBX. Then, a byte is written to IO ports 0xB2 and 0x4F. The write to port 0xB2 invokes the BIOS SMAPI code in SMM mode. So the first thing to check is what SMAPI functions are called, i.e., the value of EBX before each wrote to port 0xB2. You can see some of the known codes in the SMAPI_* constants near the top of smapi.c.

--[[User:Thinker|Thinker]] 21:57, 15 August 2007 (UTC)
----

== Does smapi interface include communication with eeprom? ==

There exists a windows program (which I haven't tracked down yet) which will reset the eeprom in the battery to clear an error. Could the smapi interface do the same?

Or are there other ways to do this? I have a relatively new battery (< 10 cycles) with all my tests showing the cells are fine, but since it reports "damage" to the thinkpad, it won't charge it.

----

No. Can you provide a link to that Windows program and (more important) information about how it works?

--[[User:Thinker|Thinker]] 02:17, 25 June 2007 (UTC)
----

Acc plus v1.3 [http://www.microsys.ro/accplus.htm] communicates over SMBus via a parallel port adapter. It says it can reset the eeprom via direct connection to the chip. But version 1.4 claims to be able to reset the chip via SMBus. I haven't verified this claim because only v1.3 is available for download. But I figured anything that can be done via the parallel port adapter ought to be able to be done natively by the thinkpad.

The Smart Battery Workshop also claims to be able to reset the eeprom. This is the program that is hard to track down because all the links you find are broken. I finally found it by searching for "smart battery workshop" on download.com [http://download.com]. They use those random urls so I can't post a direct link.

In summary: mostly these programs are just a way to communicate with the battery over SMBus using a parallel port. But there's the tantalizing claims of being able to reset the chip too....

--[[User:Kdnelson|Kdnelson]] 03:14, 3 August 2007 (UTC)
----

If I read this correctly, both AccPlus and Smart Battery Workshop require you to take out the battery and communicate with it via a parallel-to-SMBus adapter. This is out of scope for tp_smapi. AccSmart probably uses the Smart Battery interface through the laptop's internal SMBus bus; this is already supported by Linux's smart battery drivers, but doesn't work on ThinkPads since we don't know of any way the CPU can directly access the SMBus.

--[[User:Thinker|Thinker]] 13:56, 3 August 2007 (UTC)
----

== kernel 2.6.24 compatibility ==

Version 0.32 of tp_smapi seems to be incompatible with the prereleases of 2.6.24. Does anybody know if there are updated patches available?

--[[User:Jannic|Jannic]] 13:13, 1 November 2007 (UTC)

Update: It were the renames of BIT() to BIT_MASK in commit 7b19ada2ed3c1eccb9fe94d74b05e1428224663d which did not
apply cleanly to my tp_smapi patched tree. This looks like a minor change which should be fixable easily.

--[[User:Jannic|Jannic]] 13:58, 3 November 2007 (UTC)
----

Windows Keys

2007-04-16T22:07:51Z

Runia: add: hint to get right keycode

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;" |
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
In 2005 Lenovo introduced Windows keys on new ThinkPad keyboards. The unfortunate side-effect of this, is that all the keys on the spacebar row are now very small, making it much more likely to hit the wrong key by accident.</div>
|}
__NOTOC__
== Linux support ==
{{Todo|?}}

=== Simulating Windows keys ===
If your model does not have these keys, you can [[How to get special keys to work|map special keys]] to the {{key|Windows}} and {{key|Menu}}.

For example, to make the {{key|Fn}} key behave as a {{key|Menu}} key (except keys ''combination'' don't work), add the following to {{path|~/.Xmodmap}} and run {{cmd|xmodmap ~/.Xmodmap|}}:
keycode 227 = Menu

Hint: examine correct keycode using ''xev''. Here with a recent (2007-04) {{X60}} it is 115 and 117, left and right resp.

== Windows support ==
The keys are natively supported in Windows.
=== Simulating Windows keys ===
For {{Windows}}, it is possible to use the [http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-44185 Keyboard customizer utility] to remap certain keys to act as windows and menu keys. The keyboard customizer utility also performs some additional functions, such as assigning shortcut keys on an external keyboard.

==Models featuring this Technology==
*ThinkPad {{T60}}, {{T60p}}
*ThinkPad {{X60}}, {{X60s}}
*ThinkPad {{Z60m}}, {{Z60t}}

[[Category:Glossary]]

User:Runia

2007-04-16T22:00:56Z

Runia: add: lnk to tf

Have a look at [http://think-future.com/ my page in the net].

Feel free to drop me a message. :-)

How to get the internal SD card working

2007-04-16T21:59:30Z

Runia: chg: stress that starting from 2.6.17-rc1 no patch required

=Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter=

1. First of it all you need a working kernel 2.6 source.

2. Get the patches at http://mmc.drzeus.cx/wiki/Linux/Drivers/sdhci all the *.bin.

=> Note that with kernel versions >= 2.6.17-rc1, the driver is included in the kernel, and patching is unnecessary.

3. Patch your kernel

cd /usr/src/linux
patch -p1 < sdhci-0001.bin
patch -p1 < pci-sdhc-0001.bin
patch -p1 < mmc-respopcode-0001.bin

4. reconfigure your kernel with menuconfig

make menuconfig

5. activate "Device Drivers" -> "MMC/SD Card support"

<*> MMC support
<*> MMC block device driver
<M> Secure Digital Host Controller Interface support (EXPERIMENTAL)

6. recompile your kernel & reboot

make clean && make && make modules_install.. dont forget to copy your new kernel. ;)

7. Modprobe your new kernel module:

modprobe sdhci

8. Mount your SD card

mount /dev/mmcblk0p1 /mnt

9. RocknRoll

== Ubuntu 6.10 'edgy eft': ==
To get the card reader working on edgy:

Add the module 'tifm_sd' to /etc/modules and restart. Now this module gets loaded on sys bootup and a card is detected when inserted. The card reader is found as /dev/mmcblk0 and mounted automatically on card insert.

'''Step-by-step:'''

1. Make a backup of your 'modules' in case something goes wrong:
{{cmduser|sudo cp /etc/modules /etc/modules.backup}}
2. Open the file with gedit:
{{cmduser|sudo gedit /etc/modules}}
3. Add the following entry to the end of the file:
tifm_sd
4. Save and close the file. On the next boot, the sd-card reader works.

As mentioned below, this is already reported as a bug: [https://launchpad.net/distros/ubuntu/+bug/53268 BUG #53268]

== Update for FC5 running the newest 2.6.17 kernel: ==

1. modprobe mmc_block

2. modprobe sdhci

3. mount /dev/mmcblk0p1 /mnt

4. RocknRoll

Tested on my X41 with 04:00.1 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 13)

=== Automated module loading ===

I'm using ASPLinux release 11 (Seliger) based on FC4 and kernel 2.6.17-1.2142asp.

* 1. I created the script <code>/etc/sysconfig/modules/sd.modules</code> to load modules on boot. Don't forget to chmod it 775.

<pre>
#!/bin/sh

start () {
for i in mmc_core mmc_block sdhci; do
/sbin/modprobe $i >/dev/null 2>&1
done
}

stop () {
for i in sdhci mmc_block mmc_core; do
/sbin/rmmod $i >/dev/null 2>&1
done
}

restart() {
stop
start
}

case $1 in
start)
start
;;
stop)
stop
;;
restart)
echo -n "Reloading SD modules"
restart
echo ".. DONE"
;;
*)
start
esac
</pre>

* 2. This script will run after reboot. When you insert a card the automount system in KDE or Gnome will catch the medium on the fly. I found that it only works if the medium is inserted at boot time due to a '''BUG''' :-(. That's why my script is longer then it has to be...

'''BUG''' Currently the bug exists in automounting an SD card. The SD card is mounted properly when the card is inserted at boot time (or at time when modules is loaded). Otherwise it is not mounted ([https://launchpad.net/distros/ubuntu/+bug/53268 BUG #53268]). The temporary workaround is to remove && insert the module while the medium is in the reader (<code>/etc/sysconfig/modules/sd.modules restart</code>). Note that you have to be root to perform this.

Tested on my Z60t with 14:00.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)

=Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)=

To get the TI 5in1 Card Reader (like it is built in the {{Z61m}}) to work, you need a recent kernel (I use 2.6.19 on {{Debian}} Sid here, should work with 2.6.18 too) with some special options enabled:

{{kernelconf|CONFIG_TIFM_CORE|[M]|TI Flash Media interface support (EXPERIMENTAL)|Misc devices|Device Drivers||}}

{{kernelconf|CONFIG_TIFM_7XX1|[M]|TI Flash Media PCI74xx/PCI76xx host adapter support (EXPERIMENTAL)|Misc devices|Device Drivers||}}

{{kernelconf|CONFIG_MMC|[M]|MMC support|MMC/SD Card support|Device Drivers||}}

{{kernelconf|CONFIG_MMC_BLOCK|[M]|MMC block device driver|MMC/SD Card support|Device Drivers||}}

{{kernelconf|CONFIG_MMC_TIFM_SD|[M]|TI Flash Media MMC/SD Interface support (EXPERIMENTAL)|MMC/SD Card support|Device Drivers||}}

After rebuilding your kernel, you should get some new modules: tifm_core, tifm_7xx1, mmc_core, mmc_block, tifm_sd. The first two will get autoloaded on boot, if you use some kind of hardware-autodetection, the others won't, so edit your {{path|/etc/modules}} (or however the file where the modules to load on boot are listed is called by your distribution) and add these modules there.

After a reboot, or after you've loaded the modules by-hand with modprobe, you can put a SD-Card into the slot and see the light blink once. You should see something like this in your {{cmduser|dmesg}} output:

tifm_7xx1: sd card detected in socket 1
mmcblk0: mmc0:b368 SMI 999424KiB
mmcblk0: p1
mmcblk0: error 4 sending stop command
end_request: I/O error, dev mmcblk0, sector 1998840
Buffer I/O error on device mmcblk0, logical block 249855}}

Don't care about the errors, my card is still working.
Now you can mount the card with {{cmdroot|mount /dev/mmcblk0p1 /somewhere}} and work with it.

{{NOTE|This works only for SD cards at the moment, the driver isn't able to handle MMC/MS/MS PRO/xD yet.}}

SD Card slot

2007-04-16T21:52:03Z

Runia: /* Linux support */

{| width="100%"
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#F8F8FF; align:right;">
The SD Card slot (Secure Digital) is found on select ThinkPads and Docking stations.

In addition to SD Cards, SD Card slots can also accept the older MMC (MultiMedia Card).
</div>
|}
__NOTOC__
* [[Wikipedia:Secure Digital card|Wikipedia article on SD Cards]]
* [[Wikipedia:Multimedia Card|Wikipedia article on MMC Cards]]

==PCI-based SD Card slot==
This implementation is called "SD Card with IO support", and supports in addition to regular SD memory cards also special SDIO cards (e.g. Bluetooth, WiFi, etc).

=== Linux support ===
lspci reports it as a Ricoh device with PCI ID 1180:0822 (X Series, Z60m, Z60t), or 1180:0841 (Z Series).

The [http://mmc.drzeus.cx/wiki/Linux/Drivers/sdhci sdhci project] has developed a driver that supports these and other SD controller chips. The driver has been reported to work on ThinkPad {{X40}}, {{X41}}, {{Z60m}}, {{Z60t}} and {{X60}} models, and has been available in mainline kernel since 2.6.17-rc1. See also "[[How to get the internal SD-CARD working]]".

=== Models featuring this Technology ===
* ThinkPad {{X40}}, {{X41}}, {{X41T}}
* ThinkPad {{X60}}, {{X60s}}
* ThinkPad {{Z60m}}, {{Z60t}}

==USB based SD Card slot==
This implementation only supports SD Memory cards.

=== Linux support ===
Should be supported by the Linux USB Storage drivers (usb-storage).

=== Models featuring this Technology ===
* [[ThinkPad Advanced Dock]]

[[Category:Components]]

Talk:Tp smapi

2007-04-16T21:50:29Z

Runia: add: cat:X60

== Feedback ==

Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.

--[[User|StefanSchmidt]]

force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.

About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)

''(deleted, see below for how to create a patch file)''

Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.

Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?

Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)

A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:

1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.

----

Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).

On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).

About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.

The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)

The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
[[category:X60]]
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.

--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)

== battery start/stop thresholds saved after reboot? ==

Hi

Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)
----

== stop_charge_thres on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).

Talk:Tp smapi

2007-04-16T21:48:02Z

Runia: add: sig

== Feedback ==

Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.

--[[User|StefanSchmidt]]

force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.

About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)

''(deleted, see below for how to create a patch file)''

Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.

Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?

Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)

A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:

1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.

----

Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).

On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).

About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.

The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)

The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.

--[[User:Runia|Runia]] 23:48, 16 April 2007 (CEST)

== battery start/stop thresholds saved after reboot? ==

Hi

Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)
----

== stop_charge_thres on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).

Talk:Tp smapi

2007-04-16T21:47:21Z

Runia: add: X60 tp_smapi 2.6.20 issue

== Feedback ==

Great, great work! Really! This completely rocks. I just stopped my battery from charging at 77% and restarted charging a bit later, no problems whatsoever. BTW, this is on kernel 2.6.14.3.

--[[User:Spiney|spiney]] 21:25, 5 Dec 2005 (CET)
----
None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--[[User:Lammic|lammic]], 2005.12.05

Works for me on a T41 running 2.6.12-10-686 (Ubuntu 5.10).

--[[User:berndtnm|berndtnm]], 2005.12.06

Including stop_charge_thresh? That one seems to be missing on the T42p.

--[[User:Thinker|Thinker]] 00:46, 7 Dec 2005 (CET)
----

tp_smapi works just fine on an R52 with Ubuntu Breezy stock kernel.

--[[User:Micampe|Micampe]] 12:52, 7 Dec 2005 (CET)

----

''To set the thresholds for starting and stopping battery charging (in percent of current capacity):''

'''current''' really? That'd be weird, I'd expect it to be percent of '''total''' capacity.

--[[User:Micampe|Micampe]] 14:39, 7 Dec 2005 (CET)

"Current full charge capacity", as opposed to "current remaining capacity" or "designed full charge capacity"...

--[[User:Thinker|Thinker]] 15:05, 7 Dec 2005 (CET)
----

Battery features don't work with my T41p. I can't check this with windows. Can anybody try these features?

-- Nils, 7 Dec 2005
----

Nils, does cdrom_speed work for you on the T41p? Could you provide the details requested in the README (dmesg etc.)?

--[[User:Thinker|Thinker]] 21:57, 7 Dec 2005 (CET)
----

CDRom Speed seems to work. (I see no warnings, but I have to do a speed test.) Now, I've send all outputs to the email-address in the readme.

-- Nils, 8 Dec 2005
----

All the features except the stop_charge_thresh seem to work here on a t42p.
One note, the start_charge_thresh seems to really be stop_charge_thresh. Ie, If I set that to lower than my current battery %, it will never charge,
and if I set it to 100 the battery charges all the way.

--[[User:Nirik|Nirik]] 16 Dec 2005
----

Nirik, "all the features" as of which version? For example, do the force_discharge{1,2} in tp_smapi 0.12 also work for you? See the table in the article page. About start_charge, that's odd. Can you send me a log of what you did, what was the result a what was the dmesg output for each operation?

--[[User:Thinker|Thinker]] 14:16, 16 Dec 2005 (CET)
----

System T40p:

<pre>
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge1
fairlight:/sys/devices/platform/smapi/BAT0# echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge2
fairlight:/sys/devices/platform/smapi/BAT0# dmesg
tp_smapi: req_in: BX=2118 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=8680 BX=2118 CX=100 DX=b2 DI=0 SI=0 ret=-38
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge1 of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: req_in: BX=2104 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=80 BX=2103 CX=100 DX=78 DI=0 SI=0 ret=0
tp_smapi: cannot get force_discharge2 of battery 0: bx=2103
</pre>

So it seems force_discharge1 is not supported at all. But force_discharge2? By the way, i think wiki is a _very_ good idea for collecting information, but not for discussion. I would prefer a maillinglist. We can use sourceforge.

--[[User|StefanSchmidt]]

force_discharge2 is indicating a real error condition (bx=2103 which has bit 0x02 on), but I have no idea what the error is or how to fix it. Sorry. If you can trigger this function under Windows and have SoftICE or equivalent, maybe it can be worked out.

About the Wiki discussion, I'm not sure a mailing list is justified yet, but you can use the linux-thinkpad list or the e-mail address in the README.

--[[User:Thinker|Thinker]] 21:42, 16 Dec 2005 (CET)

OK, then i use linux-thinkpad to get more people involved. I'am away the next weeks, but i hope to find some time to hacking on tp_smapi.

--[[User:StefanSchmidt]]
----

Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU

--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
----

eBug, how does it fail? If the file doesn't exist, it means you didn't enable PROVIDE_CD_SPEED (see the README). If it does exist, can you provide the dmesg output when you read an write to the file?

--[[User:Thinker|Thinker]] 11:53, 18 Dec 2005 (CET)
----

To confirm:
tp_smapi 0.13 works with hdaps module loaded on T41 (2373-8RG). However, force_discharge*, inhibit_charge_minutes, start_charge_thresh, stop_charge_thresh don't seem to be implemented on this model.

--[[User:LJSBRokken|LJSBrokken]] 21 Dec 2005
----

tp_smapi version 0.13 with T23 (2647-3QG) (I have dual batteries)...

None of the functions which make any changes work...

<pre># cd /sys/devices/platform/smapi && cat BAT*/* > /dev/null
cat: BAT0/force_discharge1: Function not implemented
cat: BAT0/force_discharge2: Input/output error
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge1: Function not implemented
cat: BAT1/force_discharge2: Input/output error
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented</pre>

However, all the battery status information is available, and functions appear for both BAT0 and BAT1, regardless of when the UltraBay battery was inserted or ejected- this is very useful, it is the only way I can monitor my UltraBay battery unless it was present on boot.

--[[User:SystemParadox|SystemParadox]] 21:51, 4 Jan 2006 (CET)
----

SystemParadox, what's the dmesg output produced by "cat BAT0/force_discharge2"?

--[[User:Thinker|Thinker]] 22:02, 4 Jan 2006 (CET)
----

After the upgrade to 0.14 (with kernel 2.6.15, using the patch) I can't use inhibit_charge and start/stop_charge_thresh any longer (getting an input/output error), the dmesg debug output when {{cmd|cat|}}-ing those three files:

<pre>
tp_smapi: tp_smapi 0.14 loading...
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: req_in: BX=2114 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=ea210080 BX=ec192114 CX=c18d0700 DX=f7cc00b2 DI=f7f50000 SI=c18d0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Unknown error code
tp_smapi: req_in: BX=2116 CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d2116 CX=c0160328 DX=ec7600b2 DI=ec760000 SI=a0810000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=2116)
tp_smapi: cannot get start thresh of battery 0: Unknown error code
tp_smapi: req_in: BX=211a CX=100 DI=0 SI=0
tp_smapi: req_out: AX=c03b0080 BX=c18d211a CX=c016032c DX=eb4500b2 DI=eb450000 SI=241e0000 ret=-5
tp_smapi: SMAPI error: Unknown error code (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Unknown error code
</pre>

--[[User:Spiney|spiney]] 08:12, 10 Jan 2006 (CET)
----

Oops, the transition to 32-bit SMAPI calls was broken. Fixed in 0.15. Thanks for the quick report!

--[[User:Thinker|Thinker]] 12:10, 10 Jan 2006 (CET)
----

Yep, 0.15 works again. Quick response, bravo! :)

--[[User:Spiney|spiney]] 12:23, 10 Jan 2006 (CET)
----

On a T22, nothing seems to work with 0.16.

[[http://www.rafb.net/paste/results/fcUUDs49.html|dmesg output]] when doing cat *

I am using an Ultrabay2000 battery, so it would be really usefull to be able to control that

--[[User:nusse|nusse]]
----

Nusse: Not even the extended battery status? That does work on T23. About the control features, I believe they're not available on the T23; did you have any kind of (dis)charge control under WindowS?

--[[User:Thinker|Thinker]] 20:59, 11 Jan 2006 (CET)
----

I don't really know what 'extended battery' status means, but here an example:
<pre>
$ cat current_* /sys/devices/platform/smapi/BAT1
cat: current_avg: Input/output error
cat: current_now: Input/output error
</pre>
This is what happens when i cat any file in this directory and also in ../BAT1 :(

--[[User:nusse|nusse]] Thu Jan 12 22:07:26 CET 2006
----

Nusse: Yes, that's what I meant. What's the {{cmdroot|dmesg}} output generated by these commands?

--[[User:Thinker|Thinker]] 00:27, 13 Jan 2006 (CET)
----

Thinker: I attached some link to my first comment but it seems to be down and the link was wrong anyway.
<pre>
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
thinkpad controller read(%hx,%hx): failed writing to 0x1610
thinkpad controller read(%hx,%hx): failed writing to 0x1610
</pre>

--[[User:nusse|nusse]] Fri Jan 13 14:35:57 CET 2006
----

Nusse: Thanks; but there's not much we can do. Maybe the T22 uses a different interface, or doesn't have that feature.

--[[User:Thinker|Thinker]] 23:23, 15 January 2006 (CET)
----

Thinker: Is there anything I can do to check if the interface is different? Changing 0x1610 to some random number?

Is there a chance to get it by try and error?

--[[User:nusse|nusse]] Mon Jan 16 19:10:12 CET 2006
----

0x1610 is the number of an IO port it writes to, so changing it to a random number will pretty much guarantee a system crash...

The only way I can think of for figuring out the T22 interface is to see what the Windows software does.

--[[User:Thinker|Thinker]] 19:47, 16 January 2006 (CET)
----

I have a R40 (2722-B3G), and several things don't work with 0.16 on linux 2.6.15.1:

<pre>
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2118)
tp_smapi: cannot get force_discharge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2114)
tp_smapi: cannot get inhibit charge of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=2116)
tp_smapi: cannot get start thresh of battery 0: Function is not supported by SMAPI BIOS
tp_smapi: SMAPI error: Function is not supported by SMAPI BIOS (func=211a)
tp_smapi: cannot get stop thresh of battery 0: Function is not supported by SMAPI BIOS
</pre>

Don't know about Windows, haven't booted it for weeks nor used it for years...

--[[User:Wonka|Wonka]] 19:00, 19 January 2006 (CET)
----

Wonka: do the other features (i.e., extended battery status) work on your R40?

--[[User:Thinker|Thinker]] 20:30, 20 January 2006 (CET)
----

--[[User:lisch|lisch]] 16:14, 11 April 2006 (CDT)

On my X32, with two batteries, I get just what I expect. Looks good:
<pre>$ cat BAT?/* > /dev/null
cat: BAT0/force_discharge: Function not implemented
cat: BAT0/inhibit_charge_minutes: Function not implemented
cat: BAT0/start_charge_thresh: Function not implemented
cat: BAT0/stop_charge_thresh: Function not implemented
cat: BAT1/force_discharge: Function not implemented
cat: BAT1/inhibit_charge_minutes: Function not implemented
cat: BAT1/start_charge_thresh: Function not implemented
cat: BAT1/stop_charge_thresh: Function not implemented
$
</pre>
==Changing the CD speed when the CD is being accessed will hang your computer==

I don't have this problem on my T40p. CDROM is mounted and file on CD is opened. Change speed do '''not''' hang my system.

-- Stefan Schmidt
----

An open file looks fine if you're not reading/writing at that point. But my T43 does hangs on this:
# dd if=/dev/scd0 of=/dev/null &
# echo 1 > /sys/devices/platform/smapi/cdrom_speed

--[[User:Thinker|Thinker]] 16:41, 7 Dec 2005 (CET)
----

OK, sorry. I was to fast. My system hangs on this commands, too. :(

-- Stefan Schmidt

Works well. Great.

T42 2373-8zh. Working :cdrom_speed and start_charge_thresh. Untest : inhibit_charge_minutes.

-- Haifeng Chen

cdrom_speed works on my T40.

-- [[User:Lammic|lammic]], 2005.12.09

== Kernel Patch? ==

Hello Thinker,

would it be possible to provide the SMAPI support as kernel patch as well? Something along the lines of: (0.12 against 2.6.15-rc5)

''(deleted, see below for how to create a patch file)''

Deleted the tp_smapi.c file at the end, out of obvious reasons, and I'm not sure about the placement in the ACPI section, OTOH there it would be found easily next to ibm_acpi.

Providing a patch would help when recompiling the kernel often, I hate recompiling external modules every time (even got me a kernel-upgrade script to do most of it automatically). But of course it's up to you. :)

--[[User:Spiney|spiney]] 09:52, 16 Dec 2005 (CET)
----

I'll be glad to add this, but I don't want to go through additional manual steps in the release process (there are already quite a few). Can you add a "make patch" functionality to the Makefile, or something of the sort, to automatically generate a full patch (including tp_smapi.c) against current kernel sources?

Also, this shouldn't be under drivers/acpi, since it doesn't use ACPI at all (that's why I didn't make it a patch to ibm_acpi). I think the right place is drivers/firmware, like the dell_rbu driver for Dell laptops.

BTW, the convention for kernel patches is to start them once level higher:
diff -Nurp kernel-2.6.14-vanilla kernel-2.6.14-patched

--[[User:Thinker|Thinker]] 17:12, 16 Dec 2005 (CET)
----

Of course it's from the wrong level, as usual I was just lazy/inattentive. And at one point I'll remember who likes what patch format, promise. ;)

A patch target as in "create a new file holding a correct diff to current kernel source" would be rather difficult, since line numbers might change etc., but applying the patch should be straighforward with a bit of sed. Of course I could just do that, create a patch with the diff command and then apply the new patch file in reverse. ;)

--[[User:Spiney|spiney]] 18:36, 16 Dec 2005 (CET)
----

If it does that on a local copy (no changes the original kernel tree) and cleans up after itself, that's fine with me. :-)

--[[User:Thinker|Thinker]] 18:50, 16 Dec 2005 (CET)
----

Ok, here's a shell script that creates the patch, feel free to use it under the terms of the GPL. For example call it from your Makefile with the patch target: (I didn't want to put all the script into the Makefile, since the rules about escaping in Makefiles, well, escape me ;)

<pre>
#!/bin/bash

KDIR=/lib/modules/$(uname -r)/build
FDIR=drivers/firmware
OPWD=$(pwd)

TMPDIR=$(mktemp -d)
cd $TMPDIR

mkdir -p a/$FDIR
cp $KDIR/$FDIR/{Kconfig,Makefile} a/$FDIR
cp -r a b
sed -i -e '/endmenu/i\
config IBM_SMAPI\
tristate "IBM ThinkPad SMAPI Support"\
depends on X86\
---help---\
This adds SMAPI support on IBM ThinkPads, mostly used for battery\
charge control. For more information about this driver see\
<http://www.thinkwiki.org/wiki/SMAPI_support_for_Linux> .\
\
If you have an IBM ThinkPad laptop, say Y or M here.\
' b/$FDIR/Kconfig
sed -i -e '$a\
obj-$(CONFIG_IBM_SMAPI) += tp_smapi.o' b/$FDIR/Makefile
cp $OPWD/tp_smapi.c b/$FDIR
diff -Nurp a b > $OPWD/tp_smapi-$(uname -r).patch
rm -r a b
cd $OPWD
</pre>

BTW, [http://qbnz.com/highlighter/ GeSHi]-based syntax-highlighting would be great...

--[[User:Spiney|spiney]] 19:28, 16 Dec 2005 (CET)
----

Ah, neat sed foo. How about [http://tpctl.sourceforge.net/tmp/Makefile this] escapade, then?

What's the sed spell needed to replace the Makefile's
VER := 0.13
with auto-parsing of
#define TP_VERSION "0.13"
from tp_smapi.c?

--[[User:Thinker|Thinker]] 20:37, 16 Dec 2005 (CET)
----

Hmm, something like
VERFROMC=$(sed -ne 's/^#define TP_VERSION "$.*$"/\1/gp' tp_smapi.c)
sed -i -e "s/^VER := .*$/VER := $VERFROMC/" Makefile
should do (untested, from the top of my head, maybe the temporary variable isn't even necessary?). And neat Makefile wizardry, at one point I'll learn the syntax.

--[[User:Spiney|spiney]] 20:44, 16 Dec 2005 (CET)
----

Makefile escaping is horrible, keep avoiding it... Anyway, the updated [http://tpctl.sourceforge.net/tmp/Makefile make patch] seems to do the right thing.

--[[User:Thinker|Thinker]] 21:36, 16 Dec 2005 (CET)
----

Small documentation request: just needed to create a patch for the not-yet-installed 2.6.16-rc2, which is no problem with
make KSRC=/path/to/linux-2.6.16-rc2 KVER=2.6.16-rc2 patch
but I guess it would be a good addition to the README file. :)

--[[User:Spiney|spiney]] 10:48, 8 February 2006 (CET)
----

Right, added (to next release).

--[[User:Thinker|Thinker]] 13:40, 8 February 2006 (CET)
----

==Installation questions==
Amazing! I've loaded this module in my T43 which is running SuSE 10 with the kernel of 2.6.13-15. I have three points to share:

1. The battery control part seems to work but has a minor problem. I set the stop_charge_threshold to 70, but the battery stops charging at 55%. Don't know why and how to fix it. :P

2. I don't have the cd speed control function. Here is what I have under /sys/devices/platform/smapi/:

./ ../ ac_connected BAT0/ BAT1/ bus@ driver@ power/

3. SuSE 10 doesn't have the necessary C files under .../drivers/hwmon/, I copied them from a 2.6.14.5 kernel source. Maybe it causes the two problems above. :(

When I have time, I'll install the new kernel to see if the problems are gone and report the result.

--[[User:68.51.153.96|68.51.153.96]] 04:31, 2 Jan 2006 (CET)
----

1. It should stop charging at 70, but will only ''start'' charging when remaining capacity has dipped below <tt>start_charge_thresh</tt>.

2. See the note about PROVIDE_CD_SPEED.

3. That's should be needed only for patching the HDAPS driver in order to make it compatible with tp_smapi. If your kernel (which version is it?) doens't inlude the HDAPS driver anyway, you don't need to patch....

--[[User:Thinker|Thinker]] 09:28, 2 Jan 2006 (CET)
----

Thanks Thinker.

1. I discharged and recharged the battery again. This time, it stops at 68% percent, which is pretty good.

2. I missed the NOTE in README, for I just followed this wiki. :P

3. My kernel version is 2.6.13-15.

By the way, I just got this T43 whose model number is 266896U. I feel that the noise of the fan is much louder than my previous T21. I think it is so since it has a CPU with bigger power but am wondering if other T43 has the same big noise?

--[[User:Tyne|Tyne]] 00:14, 3 Jan 2006 (CET)
----

The note about PROVIDE_CD_SPEED is also in the Wiki...

About the T43 fan noise: yes, this is a very common (and annoying) problem. See [[Problem_with_fan_noise]] and our [[ACPI fan control script]], and send Lenovo a complaint in hope they'll fix this at the firmware level.

--[[User:Thinker|Thinker]] 08:48, 3 Jan 2006 (CET)
----
I spent hours, trying to compile this on ubuntu edgy without success. It starts with warnings about missing files:

<pre>
root@t40:/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31# make install
make -C /lib/modules/2.6.17-11-386/source M=/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31 O=/lib/modules/2.6.17-11-386/build modules
make[1]: Betrete Verzeichnis '/usr/src/linux-source-2.6.17'
/usr/src/linux-source-2.6.17/Makefile:450: .config: No such file or directory

WARNING: Symbol version dump /lib/modules/2.6.17-11-386/build/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o
cc1: error: include/linux/autoconf.h: No such file or directory
[...]
</pre>
and then many thousand lines later it finally stops:
<pre>
[...]
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:357: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_invalidateâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:378: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c: In function â€˜thinkpad_ec_initâ€™:
/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.c:460: error: â€˜CONFIG_HZâ€™ undeclared (first use in this function)
make[3]: *** [/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31/thinkpad_ec.o] Fehler 1
make[2]: *** [_module_/home/bernd/Desktop/tp_smapi-0.31/tp_smapi-0.31] Fehler 2
make[1]: *** [modules] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-source-2.6.17'
make: *** [modules] Fehler 2
</pre>

There must be something fundamentally wrong with the makefile. I have for example never seen that a symlink has to point from /lib/modules/someversion/somewhere to /usr/src/linux. I have installed other modules in the past and they all worked with installed linux-headers package. I didn't ever have to download 40MB kernel source, unpack it, configure it to have a .config and compile the whole kernel just to have 2 or three of the other files needed. This cannot be the correct way to install a driver.

[[User:7bit|7bit]] 07:42, 27 March 2007 (CEST)
----

== Formatting ==

Wyrfel, that was some heavy editing you did... I agree with most changes (including the saner color choice). I did like those HINT floats, though - they keep the hints from interrupting the flow of text too much, and this particular text needs any help it can get.

--[[User:Thinker|Thinker]] 17:04, 3 Jan 2006 (CET)
----
Hei Thinker,

I'll look into it again. I felt that the floating HINTs were tearing the text apart too much. Maybe we could fix it by placing the clear marks somewhere else.

[[User:Wyrfel|Wyrfel]] 18:46, 3 Jan 2006 (CET)
----

== Dual battery operation with tp_smapi ==

It looks like it is working quite fine with tp_smapi-0.13 and 2.6.15 (it may also work with other versions, but those are the ones I have running right now).

The juicy details:

{{cmdroot|cd /sys/devices/platform/smapi/}}
{{cmdroot|cat ac_connected}}

{{cmdresult|0}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|discharging}}
{{cmdresult|idle}}

{{cmdroot|echo 1 > BAT1/force_discharge1}}
{{cmdroot|cat BAT{0,1}/state}}
{{cmdresult|idle}}
{{cmdresult|discharging}}

Checking capacity values shows that the corrent battery is being depleted.

And remember, before you yank the CD/DVD drive out, issue:

{{cmdroot|cat eject > /proc/acpi/ibm/bay}}

----

Great! Which ThinkPad model is it? Could you also {{cmdroot|cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2}} and report the dmesg output (after {{cmdroot|make load}} or {{cmdroot|1=modprobe tp_smapi debug=1}})?

About the eject command, I think it should be possible to do that automatically when the Ultrabay handle is ejected, via <tt>acpid</tt>.

--[[User:Thinker|Thinker]] 15:45, 10 Jan 2006 (CET)
----

It's a T43 (2669). cat'ing force_discharge2 gives me an I/O error and I see

tp_smapi: cannot get force_discharge2 of battery 0: bx=2103

tp_smapi: cannot get force_discharge2 of battery 1: bx=2103

I find these errors irrelevant from the user's point of view, though.

Indeed, it should be possible to automatise the "eject" command. I should also be noted that once a force_discharge1 is set, it will NOT unset automatically, event when the AC is plugged back in. An obvious fix is to fiddle with the appropriate ACPI event to force_discharge1 back to 0 for all batteries once the AC is attached.

----

Thanks, this eliminates the last situation I imagined <tt>force_discharge2</tt> might work. The next tp_smapi version will remove <tt>force_discharge2</tt> and rename <tt>force_discharge1</tt> to <tt>force_discharge</tt>.

If you write those ACPI scripts, it would be great if you put them on the Wiki.

--[[User:Thinker|Thinker]] 16:31, 10 Jan 2006 (CET)
----

Well, I still do not preclude the fact that <tt>force_discharge2</tt> may be useful for something else on other models.

The ACPI scripts (as well as an installation guide) is underway. It may take a while, though.

----

See the new article: [[Using an Ultrabay battery]].

--[[User:Thinker|Thinker]] 17:05, 10 Jan 2006 (CET)
----

Hei Thinker,

i just renamed the new page. Will adjust your links later on. Keeping the redirect page until that's done. Please set any new links you create to the new page (the pages of the individual UltraBay batteries should contain a pointer).

On a sidenote: I would like to split the SMAPI support under Linux page into a tp_smapi driver page, just listing the features, and a "How to use tp_smapi" page. I would also split the thinkpad/tpctl page off that again. Any objections?

[[User:Wyrfel|Wyrfel]] 20:42, 10 Jan 2006 (CET)
----

ACK about the page rename (the old one did sound a bit out of line to my ear, but I couldn't spot why...).

About the splitting tp_smapi vs. thinkpad/tpctl, no objection.

About splitting tp_smapi: currently most of that section doubles as both a spec and a HOWTO, which I think is a convenient and concise way to describe things (hey, it must be right, the Perl docs do it!). I'm not sure there's much benefit in duplicating that. Perhaps we should wait for a critical mass of additional lore to accumulate?

--[[User:Thinker|Thinker]] 21:04, 10 Jan 2006 (CET)
----
Ok, i agree on the latter.

[[User:Wyrfel|Wyrfel]] 00:57, 11 Jan 2006 (CET)
----

==Article name capitalization==

Wikimedia autocapitalizes the article name upon submit. How do I concince Wikimedia that I really want a lowercase "t"? The underline is probably too much too ask...

--[[User:Thinker|Thinker]] 11:03, 11 Jan 2006 (CET)
----

Impossible, according to [http://en.wikipedia.org/wiki/Wikipedia:Canonicalization Wikipedia:Canonicalization].

--[[User:Thinker|Thinker]] 12:04, 11 Jan 2006 (CET)
----

==Status Table==
For at least the T series i think that charge control was not supported prior to the T42, hardware/BIOS side. Perhaps "N/A" flags would be better here?

I also created <nowiki>{{Isup}}</nowiki> style templates for status, they just include images, like {{Isup}}.
Not emotional about it, just wanted to let you know in case you want to use them.

Third and last...would it possibly be better to make the table headers more human readable like i.e. "lower charge threshold" or something like that instead of "start_charge_thresh"?

[[User:Wyrfel|Wyrfel]] 19:21, 11 Jan 2006 (CET)
----

About "N/A", sure, if we get reliable data about the hardware capabilities. Alas, most negative reports were just "it doesn't work", and in some cases gave contradictory information (SMAPI interface says a function is unsupported but user says it works under Windows).

About {{Iyes}} and friends, they're very cute, but I think think they're harder to parse visually and would add some clutter to an already dense table.

The table headers are just the names of the control files - that's important to keep, sine it's the most natural lookup key. Adding friendly description would be great, if we can fit them in (not everyone has an SXGA+ display...). I tried and failed.

--[[User:Thinker|Thinker]] 20:38, 11 Jan 2006 (CET)
----

I have a T41p and the windows tools still don't offer me battery management, even though it's quite a while since the T42 came out.

I'm ok with the rest.

[[User:Wyrfel|Wyrfel]] 22:35, 11 Jan 2006 (CET)
----

For the {{X40}}, I can report success using the stop_charge_thresh feature with BIOS v2.03 (1UETC8WW) and Embedded Controller Program v1.60 (1UHTB0WW).

[[User:Peterco|Peterco]] 12:07, 28 February 2006 (CET)
----

== Z60t ==

Tested on Z60t. No errors using cat. Setting thresholds works. Status and capacity queries work. --[[User:Alon|Alon]] 21:44, 4 May 2006 (CEST)

== Problem setting thresholds with X40 ==

My X40, kernel 2.6.16 and tp_smapi 0.20. I try to set the thresholds to 40% and 90% using:
<pre>
# echo 90 > stop_charge_thresh
# echo 40 > start_charge_thresh
</pre>
which should work, and the kernel reports from dmesg:
<pre>
tp_smapi: successfully loaded (smapi_port=0xb2).
tp_smapi: battery 0: changed start threshold to 85(+1)
tp_smapi: battery 0: changed stop threshold to 90
tp_smapi: battery 0: changed start threshold to 39(+1)
</pre>
but, on confirmation here is what happens:
<pre>
# cat stop_charge_thresh
90
# cat start_charge_thresh
91
</pre>
Any clues as to why start doesn't keep? Or why its always at 1 above stop_charge_thresh?

--[[User:Xmm0|Xmm0]] 15:01, 17 May 2006 (CEST)
----

Is it any different if you first set start_charge_thresh and then stop_charge_thresh?

Can you please load tp_smapi with module option "debug=1" and report the dmesg output genereated by each command?

--[[User:Thinker|Thinker]] 16:31, 17 May 2006 (CEST)
----

== Battery daemon feedback requested ==

I am writing a battery-management daemon to control charging and discharging BAT0 and BAT1 in accordance with usage patterns that extend Li-Ion and Li-Py battery life.

By default, the machine fully discharges BAT1 first, and it is said that deep-cycling all the time dramatically shortens their lifetime.

My Z61t is the test machine, and it is configured with two batteries, the stock 4-cell, and an "Advanced Ultrabay", which about doubles the runtime of the machine.

Currently there are two "modes" of the daemon:

Discharging mode.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force discharge from the battery with more capacity left
(the current value for THRESHOLD is 10%)
</pre>
I believe the preceeding will prevent either battery from being deep-cycled disproportionately.

Charging mode. I am less sure what the "right" algorithm is here. The following is a proposal.
<pre>
* look at the "remaining_percent" values for both batteries
* if one is more than THRESHOLD percent less than the other one,
force charging to the battery with less capacity left
* honor pre-set values in stop_charge_thresh and start_charge_thresh
</pre>

I would like to get feedback in the form of "better" algorithms or requests for this daemon.

--[[User:Zak Smith|Zak]] 19:03, 12 September 2006 (CEST)

It sounds like your algorithm will indeed minimize wear on both batteries. A side benefit is that charging will toggle between the batteries, which may help keep them cooler while charging and thus prolong their life. OTOH, if you plan to occasionally swap the UltraBay battery for other devices, you may want to fully charge the system battery (up to stop_charge_thresh) first.

--[[User:Thinker|Thinker]] 22:57, 12 September 2006 (CEST)

I have noticed that when force_discharge is set and the batteries switch, the gnome battery monitoring applet gets totally confused about remaining runtime. Besides being a nuisance, this could presumably cause premature emergency shutduwn.

I have also noticed that the reported remaining runtimes vary greatly between acpi, the applet, and /proc/acpi/battery/*/state

--[[User:Zak Smith|Zak]] 21:46, 14 September 2006 (CEST)

What do you mean by "acpi" vs. "/proc/acpi/battery/*/state"?

The most accurate readout is probably {{path|/sys/devices/platform/smapi/BAT0/remaining_running_time}}, but I don't think any applet uses that yet.

--[[User:Thinker|Thinker]] 12:07, 15 September 2006 (CEST)

By acpi, I meant the output of the acpi (1) command. I'll get some comparative numbers later and post them here.

--[[User:Zak Smith|Zak]] 20:37, 15 September 2006 (CEST)

Odd, my version of {{path|/usr/bin/acpi}} doesn't report remaining time, just percent (which is the same as {{path|/sys/devices/platform/smapi/BAT0/remaining_percent}}).

--[[User:Thinker|Thinker]] 21:32, 15 September 2006 (CEST)

I have been running batteryd for a while with good results. I will upload it here shortly.

I disabled the preferential charging mode, and only control discharging.

--[[User:Zak Smith|Zak]] 23:15, 14 November 2006 (CET)

http://demigod.org/~zak/src/batteryd.cc

--[[User:Zak Smith|Zak]] 20:18, 5 December 2006 (CET)

== Instructions for X60 with Bios 1.11 under Debian Etch ==

Could someone please provide step-by-step instructions of how to make this work with Debian? What have I to do after apt-get install kernel-patch-tpsmapi? Thank you!

--[[User:PeterBursch|PeterBursch]] 21:39, 15 September 2006 (CEST)

== tp_smapi 0.30 with kernel 2.6.20? ==

<pre>T60:~/tp_smapi-0.30# uname -rm
2.6.20 x86_64

T60:~/tp_smapi-0.30# make load
if lsmod | grep -q '^hdaps '; then rmmod hdaps; fi
if lsmod | grep -q '^tp_smapi '; then rmmod tp_smapi; fi
if lsmod | grep -q '^thinkpad_ec '; then rmmod thinkpad_ec; fi
if lsmod | grep -q '^tp_base '; then rmmod tp_base; fi # old thinkpad_ec
make -C /lib/modules/2.6.20/source M=/root/tp_smapi-0.30 O=/lib/modules/2.6.20/build modules
make[1]: Entering directory `/usr/src/linux-2.6.20'
CC [M] /root/tp_smapi-0.30/thinkpad_ec.o
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX'
/root/tp_smapi-0.30/thinkpad_ec.c:83: warning: parameter names (without types) in function declaration
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:94: warning: implicit declaration of function 'down_interruptible'
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: (Each undeclared identifier is reported only once
/root/tp_smapi-0.30/thinkpad_ec.c:94: error: for each function it appears in.)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_try_lock':
/root/tp_smapi-0.30/thinkpad_ec.c:109: warning: implicit declaration of function 'down_trylock'
/root/tp_smapi-0.30/thinkpad_ec.c:109: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
/root/tp_smapi-0.30/thinkpad_ec.c: In function 'thinkpad_ec_unlock':
/root/tp_smapi-0.30/thinkpad_ec.c:122: warning: implicit declaration of function 'up'
/root/tp_smapi-0.30/thinkpad_ec.c:122: error: 'thinkpad_ec_mutex' undeclared (first use in this function)
make[3]: *** [/root/tp_smapi-0.30/thinkpad_ec.o] Error 1
make[2]: *** [_module_/root/tp_smapi-0.30] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.20'
make: *** [modules] Error 2
</pre>

:Works here with 2.6.21-rc1 (didn't try 2.6.20) without problems --[[User:Zhenech|Zhenech]] 14:32, 22 February 2007 (CET)

:I have this problem when compiling for x86_64 too. It seems to be limited to 64bit kernels though. I've notified the author of tp_smapi about it, so lets hope a solution is found soon. --[[User:Esmil|Esmil]] 20:08, 6 March 2007 (CET)

The author was happy about the report, but didn't have time too look at it right now, so I thought I'd give it my best shot. Apparently I should have done that sooner, cause this seems to fix it (for me at least):
<pre>
diff -Naur tp_smapi-0.30/hdaps.c tp_smapi-0.30-64bit_fix/hdaps.c
--- tp_smapi-0.30/hdaps.c 2006-09-03 12:13:34.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/hdaps.c 2007-03-07 00:43:26.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/timer.h>
#include <linux/dmi.h>
#include <linux/thinkpad_ec.h>
+#include <linux/jiffies.h>

/* Embedded controller accelerometer read command and its result: */
static const struct thinkpad_ec_row ec_accel_args =
diff -Naur tp_smapi-0.30/thinkpad_ec.c tp_smapi-0.30-64bit_fix/thinkpad_ec.c
--- tp_smapi-0.30/thinkpad_ec.c 2006-09-02 21:46:18.000000000 +0200
+++ tp_smapi-0.30-64bit_fix/thinkpad_ec.c 2007-03-07 00:43:13.000000000 +0100
@@ -34,6 +34,7 @@
#include <linux/delay.h>
#include <linux/thinkpad_ec.h>
#include <linux/jiffies.h>
+#include <asm/semaphore.h>
#include <asm/io.h>

#define TP_VERSION "0.30"
</pre>
Copy the above to {{path|64bit_fix.patch}}, enter the {{path|tp_smapi-0.30}} directory and type
:{{cmduser|patch -p1 < /path/to/64bit_fix.patch}}
Now cross your fingers and compile as normal.
--[[User:Esmil|Esmil]] 01:06, 7 March 2007 (CET)
: tp_smapi 0.31 fixes this issue --[[User:Esmil|Esmil]] 19:22, 8 March 2007 (CET)

== X60: tp_smapi 0.31 with kernel 2.6.20 issue ==
1st of all: Thanks alot for your work. I do really appreciate this (tp_smapi/thinkwiki).

2nd: On a Debian (testing) w/ vanilla 2.6.20+tp_smapi+hdaps (w/ modules loaded) the kernel panics (init oops) on reboot just before resetting the system. It has a minor impact, you need to press power-off for 5 secs to switch off the machine. Just FYI.

== battery start/stop thresholds saved after reboot? ==

Hi

Are the values in stop_charge_thresh and start_charge_thresh just used when Linux is running, or are they saved in the battery? Here after a reboot the values are reset to 96/100. I set these values to 40/85 shut the thinkpad down and charged the battery - sadly it did not use the 85% setting and charged the battery to 100%.

--[[User:Burp|Burp]] 15:31, 13 March 2007 (CET)
----

The thresholds are saved in the embedded controller, which keeps them as long as there is AC or battery power. If you take away both, the state is reset. If you use suspend-to-disk, tp_smapi will remember the threholds and restore them during resume; but you'll need to write your own init script to set the thresholds during normal reboot after full power loss.

--[[User:Thinker|Thinker]] 16:19, 13 March 2007 (CET)
----

Under Ubuntu, you can set the thresholds under {{path| /etc/default/tpsmapi-utils}}.

START_CHARGE_THRESH_BAT0=40
#START_CHARGE_THRESH_BAT1=40

STOP_CHARGE_THRESH_BAT0=95
#STOP_CHARGE_THRESH_BAT1=70
----

If I set the value, plug in in the power cord to charge it after I have shut down the thinkpad, it will charge to 100%?
So I have to plug in the power cord while the thinkpad is running and then shut it down to make it work?
--[[User:Burp|Burp]] 17:45, 15 March 2007 (CET)
----

Changes take effect immediately, and last as long as the machine has any power source (battery or AC).

--[[User:Thinker|Thinker]] 18:59, 15 March 2007 (CET)
----

I've experienced the same problem. When I poweroff my X60 after setting the thresh-values and then reboot it, the values are set to 96/100. If I want the thresholds to be regarded I have to plug in the power cord when the thinkpad is running and then shut it down. If I turn it off before connect it to AC, the values are ignored.
So, are the values only saved in standby-mode? This isn't clear for me, and I think I'm not alone with it ;)

--[[User:Alexb|Alexb]] 20:56, 15 March 2007 (CET)

The values are not '''saved''' anywhere. They are set on the EC, and as long as the EC is kept powered on and not rebooted, they are retained. Sleep cycles and reboots on the main machine do not affect the EC. An EC firmware upgrade reboots the EC. Powering off the ThinkPad while it is on battery also powers down the EC. The ThinkPad does not power down the EC while on AC (it has to be powered up to charge the batteries).

I hope that answered all your doubts...

--[[User:Hmh|hmh]] 04:45, 28 March 2007 (CEST)
----

== stop_charge_thres on t42p ==

Hi,

'cat /sys/devices/platform/smapi/BAT0/stop_charge_thres' does not work. I get:
'Function not implemented'. Under windows the ibm tool shows me both thresholds. I am using tp_smapi version 0.31 with kernel 2.6.20 (ubuntu feisty).

Tp smapi

2007-04-16T21:39:08Z

Runia: add: c.f. to discussion (x60, 2.6.20)

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
The <tt>tp_smapi</tt> kernel module exposes some features of the ThinkPad hardware/firmware via a <tt>sysfs</tt> interface. Currently, the main implemented functionality is control of battery charging and extended battery status. The underlying hardware interfaces are [[SMAPI support for Linux|SMAPI]] and direct access to the embedded controller.

For older ThinkPad models, see also [[tpctl]].

{{WARN|This driver uses undocumented features and direct hardware access. It thus cannot be guaranteed to work and could conceivably damage your computer (though so far no incidents have been reported).}}

|}

===Features===
*Battery charge/discharge control
*Battery status information
*PCI bus power saving control

===Project Homepage / Availability===
* Project page: http://tpctl.sourceforge.net/
* You need to [http://sourceforge.net/project/showfiles.php?group_id=1212&package_id=171579 download] only the <tt>tp_smapi</tt> package.

===Installation===
====Installation from source====
You will need the kernel headers and makefiles corresponding to your current kernel version. On {{Fedora}}, this means {{cmdroot|yum install kernel-devel-$(uname -r)}} .

For testing, you can simply compile and load the driver within the current
working directory:
:{{cmdroot|tar xzvf tp_smapi-0.31.tgz}}
:{{cmdroot|cd tp_smapi-0.31}}
:{{cmdroot|make load}}

To compile and install into the kernel's module path:
:{{cmdroot|make install}}

If you use the [[HDAPS]] driver, add <tt>HDAPS=1</tt> to also patch the <tt>hdaps</tt> for compatibility with <tt>tp_smapi</tt> (this requires a kernel source tree matching the current kernel):
:{{cmdroot|1=make load HDAPS=1}}
or, to compile and install into the kernel's module path:
:{{cmdroot|1=make install HDAPS=1}}

To prepare a stand-alone patch against the current kernel tree (including
a patch against <tt>hdaps</tt> and new <tt>Kconfig</tt> entries):
:{{cmdroot|make patch}}

To delete all autogenerated files:
:{{cmdroot|make clean}}

The original kernel tree is never modified by any these commands.
The {{path|/lib/modules}} directory is modified only by {{cmdroot|make install}}.

''Comment: I had to install the complete kernel source tree to make it work (Edgy, T43)''

====Installation in Gentoo====
The {{Gentoo}} portage system carries a [http://packages.gentoo.org/packages/?category=app-laptop;name=tp_smapi tp_smapi package], which follows the latest version pretty closely. On a Gentoo system, you can install and load as follows.

If you use the [[HDAPS]] driver, do this first:

* Configure <tt>hdaps</tt> as module in your kernel
* Add the <tt>HDAPS</tt> use flag in {{path|/etc/make.conf}}
* {{cmdroot|rmmod hdaps}}

Then:

* {{cmdroot|emerge tp_smapi}} (or install tp_smapi with hdaps support manually, as above)
* {{cmdroot|echo "tp_smapi" >> /etc/modules.autoload.d/kernel-2.6}}
* {{cmdroot|echo "hdaps" >> /etc/modules.autoload.d/kernel-2.6}}

Then reboot, or run:
* {{cmdroot|modprobe tp_smapi}}
* {{cmdroot|modprobe hdaps}}

====Installation on Ubuntu/Debian====

Installation on Ubuntu or Debian is quite easy, but there are a few things to look after:

To get your system ready for compiling code, install the build-essentials (as root, of course, as all of the following comands; Ubuntu users have to prepend 'sudo' to every line and enter their own password when prompted):
<pre><nowiki>apt-get install build-essentials</nowiki></pre>

To get tp_smapi to work, obtain the latest source as mentioned above and unpack it. If you want to use HDAPS, you need to install the kernel source matching te kernel you are running. To do so, issue this:
<pre><nowiki>uname -r</nowiki></pre>
This will give you the version of your current kernel. As Ubuntu adds '-generic' to the kernel-version, the following command works for Debian users only:
<pre><nowiki>apt-get install linux-source-`uname -r`</nowiki></pre>
Ubuntu users use the kernel-version they got by the command before, e.g. 'linux-source-2.6.20'

Now change to the tp_smapi dir:
<pre><nowiki>cd tp_smapi-X.YY</nowiki></pre> (X.YY being the version-number of [[tp_smapi]])
and make and install tp_smapi as instructed above.

If you get an error that the kernel version isn't matching, please check that there is a symlink from the modules dir to the kernel source:
<pre><nowiki>root@localhost:~#ls -l /lib/modules/2.6.20-6-generic
lrwxrwxrwx 1 root root 28 2007-02-02 08:39 source -> /usr/src/linux-source-2.6.20</nowiki></pre>
Create the link if the line above is not existent:
<pre><nowiki>root@localhost:~#ln -s /usr/src/linux-source-2.6.20 /lib/modules/2.6.20-6-generic/source</nowiki></pre>

Now the following will build and install the correct modules to their locations:
<pre><nowiki>make install HDAPS=1</nowiki></pre>
To make sure your system loads the modules at boot time, do this:
<pre><nowiki>echo "tp_smapi" >> /etc/modules
echo "hdaps" >> /etc/modules</nowiki></pre>
and update your initramfs:
<pre><nowiki>update-initramfs -u</nowiki></pre>

To get tp_smapi running now, just load the modules:
<pre><nowiki>modprobe tp_smapi hdaps</nowiki></pre>

This description was tested on Kubuntu 'Feisty Fawn' and should work on all Debian-based distros with minor tweaks.

===Battery charge control features===
To set the thresholds for starting and stopping battery charging (in percent of current full charge capacity):
:{{cmdroot|echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh}}
:{{cmdroot|echo 70 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh}}
:{{cmdroot|cat /sys/devices/platform/smapi/BAT0/*_charge_thresh}}
{{HINT|Battery charging thresholds can be used to keep Li-Ion ad Li-Polymer batteries partially charged, in order to [[Maintenance#Battery_treatment|increase their lifetime]].}}
To unconditionally inhibit charging for 17 minutes:
:{{cmdroot|echo 17 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes}}
{{HINT|Charge inhibiting can be used to reduce the power draw of the laptop, in order to use an under-spec power supply that can't handle the combined power draw of running and charging. It can also be used to control which battery is charged when [[How to use UltraBay batteries|using an Ultrabay battery]].}}

To cancel charge inhibiting:
:{{cmdroot|echo 0 > /sys/devices/platform/smapi/BAT0/inhibit_charge_minutes}}

To force battery discharging even if connected to AC, use one of these:
:{{cmdroot|echo 1 > /sys/devices/platform/smapi/BAT0/force_discharge}}
{{HINT|This can be used to choose which battery is discharged when [[How to use UltraBay batteries|using an UltraBay battery]].}}

To cancel forced discharge:
:{{cmdroot|echo 0 > /sys/devices/platform/smapi/BAT0/force_discharge}}

===Battery status features===
To view extended battery status such as charging state, voltage, current, capacity, cycle count and model information:

<pre>
# cat /sys/devices/platform/smapi/BAT0/installed
# cat /sys/devices/platform/smapi/BAT0/state # idle/charging/discharging
# cat /sys/devices/platform/smapi/BAT0/cycle_count
# cat /sys/devices/platform/smapi/BAT0/current_now # instantaneous current
# cat /sys/devices/platform/smapi/BAT0/current_avg # last minute average
# cat /sys/devices/platform/smapi/BAT0/power_now # instantaneous power
# cat /sys/devices/platform/smapi/BAT0/power_avg # last minute average
# cat /sys/devices/platform/smapi/BAT0/last_full_capacity
# cat /sys/devices/platform/smapi/BAT0/remaining_percent
# cat /sys/devices/platform/smapi/BAT0/remaining_running_time
# cat /sys/devices/platform/smapi/BAT0/remaining_charging_time
# cat /sys/devices/platform/smapi/BAT0/remaining_capacity
# cat /sys/devices/platform/smapi/BAT0/design_capacity
# cat /sys/devices/platform/smapi/BAT0/voltage
# cat /sys/devices/platform/smapi/BAT0/design_voltage
# cat /sys/devices/platform/smapi/BAT0/manufacturer
# cat /sys/devices/platform/smapi/BAT0/model
# cat /sys/devices/platform/smapi/BAT0/barcoding
# cat /sys/devices/platform/smapi/BAT0/chemistry
# cat /sys/devices/platform/smapi/BAT0/serial
# cat /sys/devices/platform/smapi/BAT0/manufacture_date
# cat /sys/devices/platform/smapi/BAT0/first_use_date
# cat /sys/devices/platform/smapi/BAT0/temperature # in milli-Celsius
# cat /sys/devices/platform/smapi/ac_connected
</pre>

The raw status data is also available, including some fields not listed above (in case you can figure them out):

:{{cmdroot|cat /sys/devices/platform/smapi/BAT0/dump}}

In all of the above, replace <tt>BAT0</tt> with <tt>BAT1</tt> to address the 2nd battery.

Note that the battery status readout conflicts with the stock [[HDAPS|hdaps]] driver, so if you use <tt>hdaps</tt> you will need to load <tt>tp_smapi</tt> using {{cmdroot|1=make load HDAPS=1}} (see [[#Conflict_with_hdaps|Conflict with hdaps]] below).

On [[ACPI]]-enabled systems, most of above information is also available through the files under {{path|/proc/acpi/battery}}. However, the ACPI interface does not include the instantaneous power and cycle count readouts, and does not work well when [[How to use UltraBay batteries|hotswapping UltraBay batteries]].

===Other features===

This controls the "PCI bus power saving" option in the BIOS, and takes effect at the next boot. On a ThinkPad {{T43}} turning this off increases idle power consumption by about 350mW. Out-of-the-box default is 1.
# cat /sys/devices/platform/smapi/enable_pci_power_saving_on_boot
# echo 1 > /sys/devices/platform/smapi/enable_pci_power_saving_on_boot # on
# echo 0 > /sys/devices/platform/smapi/enable_pci_power_saving_on_boot # off

There is also [[sysfs]] attribute for making direct SMAPI requests to the SM BIOS firmware. Don't touch it unless you really know what you're doing. Example:
# echo '211a 100 0 0 > /sys/devices/platform/smapi/smapi_request; cat /sys/devices/platform/smapi/smapi_request
211a 34b b2 0 0 0 'OK'
The 4b" in the 2nd value, converted to decimal is 75: the current charge stop threshold.

===Conflict with <tt>hdaps</tt>===
The extended battery status function conflicts with the [[HDAPS|hdaps]] kernel module (they use the same IO ports). The <tt>tp_smapi</tt> package includes a patch against <tt>hdaps</tt> to make it compatible with <tt>tp_smapi</tt>, and also to fix many problems in the original driver.

To build the patched version, simply append the <tt>HDAPS=1</tt> parameter to the <tt>make</tt> command, for example: {{cmdroot|1=make load HDAPS=1}} (see [[#Installation|Installation]] above).

If you don't do that, you will not be able tp load <tt>tp_smapi</tt> (and its support module <tt>tp_base</tt>) when <tt>hdaps</tt> is loaded, and vice versa. You can use <tt>rmmod</tt> to switch between these modules.

Note that some of the battery status is also visible through ACPI ({{path|/proc/acpi/battery/*}}), independently of <tt>tp_smapi</tt>.

===Troubleshooting===

If you get <tt>thinkpad_ec: no ThinkPad embedded controller!</tt> when trying to load the module on a supported model listed below, you should [[BIOS_Upgrade|upgrade your BIOS]]. Some early BIOS (like 1.x on the X31) don't handle the embedded controller.

===Model-specific status===

<div style="font-size: 92%">
{| border="1" cellspacing="0" cellpadding="2"
|+<tt>tp_smapi</tt> feature support matrix
|-
! ×
! <tt>start_charge_<br />thresh</tt>
! <tt>stop_charge_<br />thresh</tt>
! <tt>inhbit_charge_<br />minutes</tt>
! <tt>force_discharge</tt>
! battery status files
! <tt>cd_speed</tt><br \><span style="font-size: 90%">(removed)</span>
! Notes
|-
! colspan=8 style="text-align:center;background:#efefef;" |
=====A series=====
|-
! {{A22p}} 2629-USG
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} ||
|-
! {{A30}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} ||
|-
! colspan=8 style="text-align:center;background:#efefef;" |
=====G series=====
|-
! {{G41}}
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} ||
|-
! colspan=8 style="text-align:center;background:#efefef;" |
=====R series=====
|-
! [[:Category:R31|R31]]
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || No SMAPI BIOS
|-
! {{R40}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} ||
|-
! {{R50}}
| {{Cunk}} || {{Cno}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{R50e}} 1834-JAG
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} ||
|-
! {{R50p}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cyes}} ||
|-
! {{R51}}
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{R52}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} ||
|-
! {{R60}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} ||
|-

! colspan=8 style="text-align:center;background:#efefef;" |

=====T series=====
|-
! {{T20}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || Has SMAPI BIOS but no function is supported. EC LPC3 protocol fails.
|-
! {{T22}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || Has SMAPI BIOS but no function is supported. EC LPC3 protocol fails.
|-
! {{T23}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} ||
|-
! {{T30}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} ||
|-
! {{T40}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T40p}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T41}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T41p}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T42}}
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T42p}} 2373-KUU
| {{Cyes}} || {{Cno}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{T43}} 2686-DGU
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T43p}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||
|-
! {{T60}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cyes}} || {{Cunk}} ||
|-
! colspan=8 style="text-align:center;background:#efefef;" |

=====X series=====
|-
! {{X20}} 2662-31G
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || tp_smapi 0.20
|-
! {{X24}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{X31}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{X32}}
| {{Cno}} || {{Cno}} || {{Cno}} || {{Cno}} || {{Cyes}} || {{Cunk}} ||
|-
! {{X40}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cyes}} || {{Cunk}} || BIOS v2.03, EC v1.60
|-
! {{X41}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} ||
|-
! {{X60}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} || BIOS v2.07, EC v1.10, 2.6.20 issue (see discussion)
|-
! colspan=8 style="text-align:center;background:#efefef;" |

=====Z series=====
|-
! {{Z60m}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cunk}} ||
|-
! {{Z60t}}
| {{Cyes}} || {{Cyes}} || {{Cunk}} || {{Cunk}} || {{Cyes}} || {{Cunk}} ||
|-
! {{Z61m}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||
|-
! {{Z61t}}
| {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} || {{Cyes}} ||
|}
</div>

Please update the above and report your experience on the [[Talk:tp_smapi|discussion]] page. If the module loads but gives a "<tt>not supported</tt>" or "<tt>not implementeded</tt>" when you try to use some specific file in {{path|/sys/devices/platform/smapi/}}, please report the <tt>dmesg</tt> output and whether the corresponding functionality is available under Windows - maybe your ThinkPad just can't do that.

While at it, you may also want to add your laptop to the [[list of DMI IDs]].

[[Category:Drivers]] [[Category:Patches]]

===Tools using this driver===

The driver's interface can be accessed directly through the files under {{path|/sys/devices/platform/smapi}}, or via the following tools:
* [[KThinkBat]] - display battery status on the KDE <tt>kicker</tt> panel.
* [[gkrellm-ThinkBat]] - battery status plugin for Gkrellm2
* {{CodeRef|thinkpad-smapi.sh}} - script to display various SMAPI information using tp_smapi module.

How to configure the TrackPoint

2005-10-08T10:09:33Z

Runia: /* Using the X server (kernel 2.6.11+) */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |The [[Patch to enable advanced trackpoint configuration|kernel trackpoint driver]] is controlled by echoing values to special files. Common configuration options are outlined below.
{{NOTE|
Prior to kernel 2.6.11 these files were located in <tt>/proc/trackpoint</tt>.

From 2.6.11 on this is no longer the case. Instead use <tt>/sys/devices/platform/i8042/serio0</tt>.

(The newer form is used throughout this document.)
}}
|}

==General Configuration==
The configuration options are reflected by the files you can find in {{path|/sys/devices/platform/i8042/serio0}}. See the [[Patch to enable advanced trackpoint configuration|TrackPoint driver page]] for a complete list.
Configuration is done by echoing the appropriate values into these special files.
{{HINT|If <tt>echo XX > file</tt> isn't working for you, try <tt>echo -n XX > file</tt> instead}}

==Most common Features==
The most common settings are '''Press to Select''', '''sensitivity''', '''speed''' and '''scrolling'''.

===Press to Select===
Press to Select allows you to tap the control stick which will simulate a left click. You can enable this feature by typing the following in to a terminal (you may need to be root):

:{{cmdroot|echo 1 > /sys/devices/platform/i8042/serio0/press_to_select}}

Press to Select should now be enabled. You can disable it in a similar manner:

:{{cmdroot|echo 0 > /sys/devices/platform/i8042/serio0/press_to_select}}

===Sensitivity & Speed===
Adjusting the speed and sensitivity of the TrackPoint requires echoing a value between 0 and 255 into the appropriate file. For example, for a speed of 120 and a sensitivity of 250, type the following into a terminal:

:{{cmdroot|echo 120 > /sys/devices/platform/i8042/serio0/speed}}
:{{cmdroot|echo 250 > /sys/devices/platform/i8042/serio0/sensitivity}}

Feel free to experiment with your settings until you find a combination that is comfortable.

===Scrolling===
====Using a kernel prior to 2.6.11====
The scrolling action is essentially the same as is used in the TrackPoint Windows drivers. To enable this feature, type the following in to a terminal (you may need to be root):

:{{cmdroot|echo 1 > /proc/trackpoint/scroll}}

Then press the middle button and push the stick up and down to scroll. Similarly, to disable scrolling:

:{{cmdroot|echo 0 > /proc/trackpoint/scroll}}

====Using the X server (kernel 2.6.11+)====
The scroll setting has been removed from the trackpoint driver in kernel versions 2.6.11 and above. Scroll emulation should now be handled in the X server. First do:

:{{cmd|echo -n 0 > /sys/devices/platform/i8042/serio0/middle_btn_disable}}

(Note for kernel 2.6.13: There's no more such file /sys/devices/platform/i8042/serio0/middle_btn_disable)

Then, for versions of Xorg since ~Oct '04, add these lines to your TrackPoint configuration section in {{path|/etc/X11/xorg.conf}}:

Option "EmulateWheel" "on"
Option "EmulateWheelButton" "2"

Now restart X and hold down button 2 and move the mouse to scroll, or just press and release button 2 for a middle click.
Please note that the patch allowing to use button 2 for a middle click is currently (27/09/05) NOT included in Debian and Ubuntu packages of Xorg. You can find an updated version of the package in the Experimental branch of debian.

For older versions of Xorg or for Xfree86 ({{path|/etc/X11/XF86Config}}) try this:

Option "Emulate3Buttons" "true"
Option "EmulateWheel" "true"
Option "EmulateWheelButton" "2"

Now restart X and hold down button two and move the mouse for scrolling. To get a middle click, press buttons 1 and 3 simultaneously.

==Soft Transparent Mode==
If you wish to connect a special device to the external PS/2 port, you should consider using "Soft Transparent Mode" so that the TrackPoint controller does not interpret any commands sent to the external PS/2 port. You can enable soft transparent mode by typing the following in to a terminal:

:{{cmdroot|echo 1 > /proc/trackpoint/transparent}}

Disabling soft transparent mode is similar:

:{{cmdroot|echo 0 > /proc/trackpoint/transparent}}

Problem with high power drain in ACPI sleep

2005-10-08T10:03:53Z

Runia: /* Affected Models */

Information about the problem of too high power drain in ACPI sleep mode.

==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-R6G
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-MU3
**2373-82U
**2373-92U
**2373-22G
**2373-19G
**2373-A1U
**2373-42G
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2373-FWG
**2374-ZEP
**2373-F2G
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T42 | T42]]
**[[2378-FVU]]
**[[2373-WBZ]]
**[[2378-RTU]]
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:X40 | X40]]
**2371
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-D5G
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. This fix has not yet made its way into the official kernel (as of linux 2.6.12).

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

==Affected Operating Systems==
*Linux, all flavours.
*Windows, for some models as well (only when using non-IBM drivers).
*FreeBSD (on the A22M)

==Status==
*The cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. Unfortunately, this fix might break non-ThinkPad machines and therefore is not yet in the official kernel sources.
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find a patch which will solve the power drain issue.
{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not properly documented! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch. By default, the patch enables the suspend-to-D2 only on machines where it is know to work. This behaviour can be overridden with a module option.}}
*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
*Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

==Solutions==
===For ThinkPads with Radeon graphic chips===
You must use a patched version of the radeon frame buffer, even if you are only interested in using the X window system. This modified radeon frame buffer then suspends the radeon chip correctly during ACPI sleep. This patch is not yet in the official (kernel.org) kernels.

The [http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/patch-2.6.11-rc2-radeonfb-D2.patch.bz2 patch] contains a list of ThinkPads where it is known to work, and by default only activates on these machines. If you think that your computer would profit from the patch as well, you can force it by including the module parameter {{bootparm|radeon_force_sleep|1}}. If it doesn't work this can result in system hangs.

====Technical Background====
The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}} as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022].

====Fedora Core====
* Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. {{Fedora}} compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).
* Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but '''not''' for the initially shipped version.

There are precompiled patched kernels [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html available] as well, that do not need an initrd modification:
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.11.11-26.i386.rpm linux 2.6.11 for Fedora Core 3]
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.12.2-2.i386.rpm linux 2.6.12 for Fedora Core 4]
These kernels contain additional ThinkPad-related patches, including software suspend2 and trackpoint support. Suspend to disk and suspend to ram should work with them. If your ThinkPad model is not yet whitelisted in the patch, you might have to enable the radeon fix by including the parameter {{bootparm|video|2=radeonfb:radeon_force_sleep=1}} on the kernel command line.

If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (i.e. IBM ThinkPad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.

=====testing radeonfb without changing initrd=====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb radeon_force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

=====including radeonfb into your initrd=====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:radeon_force_sleep=1}}.

====Gentoo====
After installing the patch on {{Gentoo}} (it works fine with gentoo-sources: {{cmdroot|cd /usr/src/linux/drivers/video/aty}}, and execute {{cmdroot|patch -p4 <patchname>}}, then recompile the kernel), one needs to add {{bootparm|video|radeonfb:force_sleep}} to the kernel parameters.

====Another possible solution====
It is possible that [[radeontool]] will help some people with this case.
(simply run radeontool light off before suspend and radeontool light on after resume).
A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).

===For models without radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.

Problem with high power drain in ACPI sleep

2005-10-08T10:03:40Z

Runia: /* Affected Models */

Information about the problem of too high power drain in ACPI sleep mode.

==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-R6G
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-MU3
**2373-82U
**2373-92U
**2373-22G
**2373-19G
**2373-A1U
**2373-42G
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2373-FWG
**2374-ZEP
**2373-F2G
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T42 | T42]]
**[[2378-FVU]]
**[[2373-WBZ]]
**[[2378-RTU]]
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:X40 | X40]]
**2371
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. This fix has not yet made its way into the official kernel (as of linux 2.6.12).

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

==Affected Operating Systems==
*Linux, all flavours.
*Windows, for some models as well (only when using non-IBM drivers).
*FreeBSD (on the A22M)

==Status==
*The cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. Unfortunately, this fix might break non-ThinkPad machines and therefore is not yet in the official kernel sources.
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find a patch which will solve the power drain issue.
{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not properly documented! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch. By default, the patch enables the suspend-to-D2 only on machines where it is know to work. This behaviour can be overridden with a module option.}}
*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
*Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

==Solutions==
===For ThinkPads with Radeon graphic chips===
You must use a patched version of the radeon frame buffer, even if you are only interested in using the X window system. This modified radeon frame buffer then suspends the radeon chip correctly during ACPI sleep. This patch is not yet in the official (kernel.org) kernels.

The [http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/test/patch-2.6.11-rc2-radeonfb-D2.patch.bz2 patch] contains a list of ThinkPads where it is known to work, and by default only activates on these machines. If you think that your computer would profit from the patch as well, you can force it by including the module parameter {{bootparm|radeon_force_sleep|1}}. If it doesn't work this can result in system hangs.

====Technical Background====
The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}} as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022].

====Fedora Core====
* Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. {{Fedora}} compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).
* Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but '''not''' for the initially shipped version.

There are precompiled patched kernels [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html available] as well, that do not need an initrd modification:
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.11.11-26.i386.rpm linux 2.6.11 for Fedora Core 3]
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.12.2-2.i386.rpm linux 2.6.12 for Fedora Core 4]
These kernels contain additional ThinkPad-related patches, including software suspend2 and trackpoint support. Suspend to disk and suspend to ram should work with them. If your ThinkPad model is not yet whitelisted in the patch, you might have to enable the radeon fix by including the parameter {{bootparm|video|2=radeonfb:radeon_force_sleep=1}} on the kernel command line.

If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (i.e. IBM ThinkPad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.

=====testing radeonfb without changing initrd=====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb radeon_force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

=====including radeonfb into your initrd=====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:radeon_force_sleep=1}}.

====Gentoo====
After installing the patch on {{Gentoo}} (it works fine with gentoo-sources: {{cmdroot|cd /usr/src/linux/drivers/video/aty}}, and execute {{cmdroot|patch -p4 <patchname>}}, then recompile the kernel), one needs to add {{bootparm|video|radeonfb:force_sleep}} to the kernel parameters.

====Another possible solution====
It is possible that [[radeontool]] will help some people with this case.
(simply run radeontool light off before suspend and radeontool light on after resume).
A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).

===For models without radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.