linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lutomirski <luto@mit.edu>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: 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: Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger
Date: Mon, 9 May 2011 11:10:55 -0400	[thread overview]
Message-ID: <BANLkTikB2TFF12vdwLqV9NRw4meEyDjvdA@mail.gmail.com> (raw)
In-Reply-To: <20110509144546.GB13275@khazad-dum.debian.net>

On Mon, May 9, 2011 at 10:45 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Sun, 08 May 2011, Andrew Lutomirski wrote:
>> 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
>
> Yeah, there's a little protocol to talk to the EC, otherwise it simply
> ignores writes to the battery threshold registers.  I think you had to set
> bit 7 before you write the threshold to the relevant EC register, or
> something.  Found it by trial-and-error a long time ago, I documented it
> somewhere but never took it forward.  I never bothered to hunt down the
> force-drain/battery-select commands, though.
>
> Anyway, since SMAPI works, and is *stable* (the fact that it works from the
> A21 to the latest Lenovos tells you just how stable), which is a lot more
> than what I can say about the ACPI stuff, I didn't see any reason to mess
> with this.

I must have been unclear.  I'm using SMAPI -- I've reverse-engineered
it from a combination of tp_smapi, the mwave driver, the ancient PDF
on Lenovo's site, and trial-and-error on my X220.  (The X220 fails
requests for the start threshold that work on on the X200s.)

>> 2. Integrate it with power_supply.
>
> Only if we can make it generic enough, but yes, THIS is the better way.
>
> However, I'd prefer if you went all the way and actually hooked to the SBS
> subsystem and exposed all the battery information.  There is a way to do
> that through the ACPI DSDT (but you will have to do the rev. engineering
> yourself, as I said, smapi works just fine across so many models, that I
> never bothered with it -- it is far better supported than ACPI).
>
> It is not even difficult, just look at the methods used to expose the
> standard ACPI battery interface, then read the Smart Battery System (SBS)
> standard, and you will find out by fast trial-and-error how to map one to
> the other.  Or you can look at tp_smapi to speed things up (only, tp_smapi
> talks directly to the EC instead of doing it over ACPI).
>
> The SBS interface exposes more data about the battery, including
> per-cell-group voltage and pack microcontroller aging counters, alarms, and
> the "needs to get through the fuel-gaugue reset procedure" semasphore.

If I'm feeling really motivated, I'll look at that.  I'm currently
more interested in the charging thresholds, though, which I think is
independent of the choice of SBS vs ACPI to access the battery state.
(From a quick glance at the SBS spec, you can inhibit charging
entirely but you can't ask for thresholds.  I assume that the EC takes
care of that.  If I'm wrong, please tell me, but SMAPI seems like a
fine way to access the thresholds.)

--Andy

  reply	other threads:[~2011-05-09 15:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-08 12:35 [RFC] Controlling the ThinkPad battery charger Andrew Lutomirski
2011-05-09 13:56 ` Matthew Garrett
2011-05-09 14:45 ` [ibm-acpi-devel] " Henrique de Moraes Holschuh
2011-05-09 15:10   ` Andrew Lutomirski [this message]
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=BANLkTikB2TFF12vdwLqV9NRw4meEyDjvdA@mail.gmail.com \
    --to=luto@mit.edu \
    --cc=cbou@mail.ru \
    --cc=dwmw2@infradead.org \
    --cc=hmh@hmh.eng.br \
    --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).