From: Andrew Lutomirski <luto@mit.edu>
To: linux-kernel@vger.kernel.org,
ibm-acpi-devel@lists.sourceforge.net,
platform-driver-x86@vger.kernel.org,
Anton Vorontsov <cbou@mail.ru>,
David Woodhouse <dwmw2@infradead.org>
Subject: [RFC] Controlling the ThinkPad battery charger
Date: Sun, 8 May 2011 08:35:32 -0400 [thread overview]
Message-ID: <BANLkTinWna2sDDjbNC5xyGX3ELROs=Wd0w@mail.gmail.com> (raw)
I've figured out how the ThinkPad SMAPI charge control works (at least
well enough to program thresholds on some models), and I'd like to get
this functionality into mainline. (This is inspired by, and borrows
magic numbers from, tp_smapi, but it has no code at all from tp_smapi
and therefore shouldn't have the lack-of-authorship issue.) My
question is: what's the best way to expose this functionality?
Currently, I have a little driver (not yet in mergeable shape) that
creates a platform device and sticks some sysfs attributes in it
depending on which thresholds it can figure out how to program. It's
here:
https://gitorious.org/linux-test-utils/tp_charge/blobs/master/kmod/tp_charge.c
I'd like to find a better way, though. Some quick Googling suggests
that some Vaio laptops can do this, but I'm afraid that all my laptops
are ThinkPads. Two ideas:
1. Integrate this with thinkpad_acpi and keep exposing it as a
thinkpad-specific thing (device? new class_device?) in sysfs.
2. Integrate it with power_supply.
I like option 2 better, since it means that a userspace tool (like
GNOME) could learn how to operate a battery charge controller once and
then other laptops and devices could reuse the same interface. The
problem is that the ACPI battery driver can't see the charge control.
So either it would need a hook to allow per-vendor control like this
or the power_supply class would need to recognize separate charge
controllers.
I have no intention of creating a kitchen sink like tp_smapi. But I
might want to add things like forced discharge or outright disabling
of charging. On possible added complication: on ThinkPads, the charge
thresholds stay in effect until reprogrammed or until the battery is
removed, even if the computer is off.
Any thoughts? I've never touched the driver model before.
--Andy
next reply other threads:[~2011-05-08 12:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-08 12:35 Andrew Lutomirski [this message]
2011-05-09 13:56 ` [RFC] Controlling the ThinkPad battery charger Matthew Garrett
2011-05-09 14:45 ` [ibm-acpi-devel] " Henrique de Moraes Holschuh
2011-05-09 15:10 ` Andrew Lutomirski
2011-05-09 15:29 ` Henrique de Moraes Holschuh
2011-05-09 15:47 ` Andrew Lutomirski
2011-05-10 18:43 ` Pavel Machek
2011-05-10 19:57 ` Henrique de Moraes Holschuh
2011-05-10 20:58 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTinWna2sDDjbNC5xyGX3ELROs=Wd0w@mail.gmail.com' \
--to=luto@mit.edu \
--cc=cbou@mail.ru \
--cc=dwmw2@infradead.org \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).