[ltp] Re: tp_smapi resume behavior

[Shem Multinymous]

On Sat, Dec 13, 2008 at 10:07 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> Would it be possible to differentiate resume from STR from resume from
> STD on tp_smapi, and drop the SMAPI calls to restore battery charge
> thresholds when resuming from STR?
>
> The reason I ask for this is that, at least on the T4x, SMAPI battery
> calls disturb the EC, and it pauses an ongoing charge for ~2s only to
> immediately resume it.  That is not very optimal for the battery.
>
> Besides, we *KNOW* the EC will retain all relevant data over STR
> anyway, and the less SMAPI calls we do in the resume path, the better
> (as they cause SMIs, and SMIs are ALWAYS a bad idea when clocks are
> being recalibrated, devices are being reset, etc).
>
> The current behaviour of restoring all thresholds when resuming would
> have to be reatained when resuming from STD, though.

Good idea. This amounts to restoring the thresholds in the resume()
handler only if the most recent suspend() handler was called with
PM_EVENT_HIBERNATE or PM_EVENT_FREEZE, right?


> BTW, maybe it would be a good idea to schedule work and reapply the
> SMAPI thresholds a few seconds after the resume hook is called,
> instead of when the resume hook is called?  Just in case there is
> indeed a dangerous window for SMIs during device setup for something
> else in the resume path...

If the SMI is dangerous, I'd rather hear about it than unreliably paper over it.


> Also, any plans to add sysfs power_supply class support to tp_smapi?

Patches are welcome... :-)


  Shem