Difference between revisions of "Talk:SMAPI support for Linux"

From ThinkWiki
Jump to: navigation, search
(Feedback)
(Moved to tp_smapi and tpctl pages)
 
(29 intermediate revisions by 10 users not shown)
Line 1: Line 1:
== Feedback ==
 
  
Someone reported cd_speed works on T42 but on mine, it doesn't: this is 2378DXU
 
 
--[[User:eBug]] 22:55, 17 Dec 2005 (CET)
 
----
 
 
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]]
 
----
 
 
==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
 
 
== "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.
 
 
--[[User:Thinker|Thinker]] 13:53, 10 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. :)
 
 
--[[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)
 
----
 

Latest revision as of 11:27, 11 January 2006