Talk:SMAPI support for Linux

From ThinkWiki
Revision as of 21:42, 10 January 2006 by Wyrfel (Talk | contribs)
Jump to: navigation, search


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

--spiney 21:25, 5 Dec 2005 (CET)

None of the fuctions is working on my T40, kernel 2.6.14-mm2.

--lammic, 2005.12.05

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

--berndtnm, 2005.12.06

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

--Thinker 00:46, 7 Dec 2005 (CET)

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

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

--Micampe 14:39, 7 Dec 2005 (CET)

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

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

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

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

--Thinker 14:16, 16 Dec 2005 (CET)

System T40p:

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

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.


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.

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


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?

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

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

# 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

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.

--SystemParadox 21:51, 4 Jan 2006 (CET)

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

--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 cat-ing those three files:

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

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

--Thinker 12:10, 10 Jan 2006 (CET)

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

--spiney 12:23, 10 Jan 2006 (CET)

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

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

-- lammic, 2005.12.09

"thinkpad" module kernel compatibility

Ajunge, how do you compile the "thinkpad" module compile on kernel >=2.6.9? The latest thinkpad version (5.8) still uses "get_cpu_ptr" and "set_cpu_ptr", which were removed in 2.6.9.

--Thinker 13:53, 10 Dec 2005 (CET)

The Debian thinkpad-source package in unstable (version 5.8-4) works just fine; I'm compiling it with 2.6.14 without any problems. And get_cpu_ptr is present; it's defined in include/linux/percpu.h.

--TedTso 18:56, 17 Dec 2005 (EDT)

Stock thinkpad_5.8.tar.gz doesn't #include percpu.h anyway, and doesn't compile on vanilla or 2.6.15-rc5. Maybe Debian patched it? In that case the article page should ref the patch.

--Thinker 11:50, 18 Dec 2005 (CET)

Oops, my mistake. I forgot that I had patched my copy of thinkpadpm.c. I replaced the use of get_cpu_ptr and set_cpu_ptr with get_cpu_val() and set_cpu_val(). I just double checked, and it tpctl is working for me on 2.6.15-rc5.

--TedTso 14:45, 19 Dec 2005 (EDT)

Care to send a patch? It would be useful on the article page, and maybe we can get it into upstream.

--Thinker 23:11, 19 Dec 2005 (CET)

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

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

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

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

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


KDIR=/lib/modules/$(uname -r)/build

TMPDIR=$(mktemp -d)

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\
        This adds SMAPI support on IBM ThinkPads, mostly used for battery\
        charge control. For more information about this driver see\
        <> .\
        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

BTW, GeSHi-based syntax-highlighting would be great...

--spiney 19:28, 16 Dec 2005 (CET)

Ah, neat sed foo. How about 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?

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

--spiney 20:44, 16 Dec 2005 (CET)

Makefile escaping is horrible, keep avoiding it... Anyway, the updated make patch seems to do the right thing.

--Thinker 21:36, 16 Dec 2005 (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 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.

-- 04:31, 2 Jan 2006 (CET)

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

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

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

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

--Thinker 08:48, 3 Jan 2006 (CET)


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.

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

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:

# cd /sys/devices/platform/smapi/ # cat ac_connected

0 # cat BAT{0,1}/state discharging idle

# echo 1 > BAT1/force_discharge1 # cat BAT{0,1}/state idle discharging

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

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

# cat eject > /proc/acpi/ibm/bay

Great! Which ThinkPad model is it? Could you also # cat /sys/devices/platform/smapi/BAT{0,1}/force_discharge2 and report the dmesg output (after # make load or # 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 acpid.

--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 force_discharge2 might work. The next tp_smapi version will remove force_discharge2 and rename force_discharge1 to force_discharge.

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

--Thinker 16:31, 10 Jan 2006 (CET)

Well, I still do not preclude the fact that force_discharge2 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.

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

Wyrfel 20:42, 10 Jan 2006 (CET)