[RFC] Controlling the ThinkPad battery charger

[RFC] Controlling the ThinkPad battery charger

[Andrew Lutomirski]

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

Re: [RFC] Controlling the ThinkPad battery charger

[Matthew Garrett]

On Sun, May 08, 2011 at 08:35:32AM -0400, Andrew Lutomirski wrote:

> 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 agree that this is preferable. One option would be to just use smapi 
and provide a hook to detach the ACPI driver, but that would potentially 
mean a certain amount of code duplication.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Henrique de Moraes Holschuh]

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.

> 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 apologise, but I will not read that code until it is clear I need not be
available for any possible clean-room attempts.

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

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

This is not a complication.  You must never assume you are the one in charge
of the ThinkPad firmware (you're not, it does its own thing).  You can
respectfully ask it to do something else, but you have to keep an eye on it,
because it might change its mind as soon as an external event is detected.

If the kernel power_supply subsystem cannot work that way, you will have to
fix that limitation first.  You need to read the thresholds when you need
that information, etc.

The SBS parameters stay in effect until the EC is power-cycled.  IBMs will
shut it down when turned off if the AC feed is removed.  Lenovos will only
shut it down when there is no power at all (i.e. no AC feed, and no SBS
batteries connected to the box).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Andrew Lutomirski]

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

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Henrique de Moraes Holschuh]

On Mon, 09 May 2011, Andrew Lutomirski wrote:
> > 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.)

Yeah, SMAPI is the safest way to deal with all this.  It is an interface
layer that Lenovo is not fond of breaking (or touches very rarely.  Amounts
to the same in the end).

SBS does not take care of thresholds, indeed.  The EC does (and I know how
to program the threshold in a few models, if you do want to test it in your
X220, I can send you the information.  It is safe to test if you use it
together with SMAPI to cross-check).

The SBS ACPI interface would be useful to provide a single driver that can
replace the ACPI battery one to deliver full functionality in one place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Andrew Lutomirski]

On Mon, May 9, 2011 at 11:29 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Mon, 09 May 2011, Andrew Lutomirski wrote:
>> > 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.)
>
> Yeah, SMAPI is the safest way to deal with all this.  It is an interface
> layer that Lenovo is not fond of breaking (or touches very rarely.  Amounts
> to the same in the end).
>
> SBS does not take care of thresholds, indeed.  The EC does (and I know how
> to program the threshold in a few models, if you do want to test it in your
> X220, I can send you the information.  It is safe to test if you use it
> together with SMAPI to cross-check).

That would be great.  I think it's EC register 0x24 for the BAT0 stop
threshold and EC register 0x25 for the BAT1 stop threshold.  If you
have any hints about the start threshold I can test them, but I
suspect that, in the X220, the EC figures out the start threshold on
its own.

>
> The SBS ACPI interface would be useful to provide a single driver that can
> replace the ACPI battery one to deliver full functionality in one place.
>

I'll save that for later :)

--Andy

> --
>  "One disk to rule them all, One disk to find them. One disk to bring
>  them all and in the darkness grind them. In the Land of Redmond
>  where the shadows lie." -- The Silicon Valley Tarot
>  Henrique Holschuh
>

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Pavel Machek]

On Mon 2011-05-09 12:29:41, Henrique de Moraes Holschuh wrote:
> On Mon, 09 May 2011, Andrew Lutomirski wrote:
> > > 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.)
> 
> Yeah, SMAPI is the safest way to deal with all this.  It is an interface
> layer that Lenovo is not fond of breaking (or touches very rarely.  Amounts
> to the same in the end).
> 
> SBS does not take care of thresholds, indeed.  The EC does (and I know how
> to program the threshold in a few models, if you do want to test it in your
> X220, I can send you the information.  It is safe to test if you use it
> together with SMAPI to cross-check).

Hmm, I jave a battery pack with reasonably good cells, but firmware killed it. IOW available for testing.

(And who know, perhaps recalibrate command would bring it back to life?)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Henrique de Moraes Holschuh]

On Tue, 10 May 2011, Pavel Machek wrote:
> Hmm, I jave a battery pack with reasonably good cells, but firmware killed
> it. IOW available for testing.

That is likely a problem with the battery pack uC, we cannot override that
using any know firmware path in the ThinkPad.

Does the thinkpad recognizes the presence of the battery pack?  If it
doesn't, the pack uC is probably dead or in safe mode, and you'd need to
hardware-hack it.

> (And who know, perhaps recalibrate command would bring it back to life?)

AFAIK, the recalibrate command really just does this:

1. sets 'force discharge' flag on EC so that it starts discharging the
   battery pack.  Discharging stops when cell voltage drops close to the
   minimum safety level.

2. sets stop threshold to 0 (100%) for that battery pack.

That way, the box will fully-drain the pack, and then charge it to full. At
that point, the recalibration is complete (the battery pack uC will
auto-calibrate itself when it notices it has hit the fully-drained and
fully-charged points).

You can monitor per-cell-group voltages through tp_smapi on a original IBM
battery pack, that functionality should still be around on the Lenovos.
Since this is not standard SBS functionality, it might not work on
non-original battery packs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Pavel Machek]

Hi!

> > Hmm, I jave a battery pack with reasonably good cells, but firmware killed
> > it. IOW available for testing.
> 
> That is likely a problem with the battery pack uC, we cannot override that
> using any know firmware path in the ThinkPad.
> 
> Does the thinkpad recognizes the presence of the battery pack?  If it
> doesn't, the pack uC is probably dead or in safe mode, and you'd need to
> hardware-hack it.

Yes, it does, and it reports everything ok... (Battery 100% full
IIRC). Its just that machine dies immediately when AC is removed.

> > (And who know, perhaps recalibrate command would bring it back to life?)
> 
> AFAIK, the recalibrate command really just does this:
> 
> 1. sets 'force discharge' flag on EC so that it starts discharging the
>    battery pack.  Discharging stops when cell voltage drops close to the
>    minimum safety level.
> 
> 2. sets stop threshold to 0 (100%) for that battery pack.
> 
> That way, the box will fully-drain the pack, and then charge it to full. At
> that point, the recalibration is complete (the battery pack uC will
> auto-calibrate itself when it notices it has hit the fully-drained and
> fully-charged points).
> 
> You can monitor per-cell-group voltages through tp_smapi on a original IBM
> battery pack, that functionality should still be around on the Lenovos.
> Since this is not standard SBS functionality, it might not work on
> non-original battery packs.

IIRC I tried playing with tp_smapi and did not get anything
useful. The pack should be original, and I guess I should try again.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html