Re: Re: first shoot for smartbattery

Bruno Ducrot
2005-01-03T17:54:49Z

On Mon, Jan 03, 2005 at 06:02:59PM +0100, liste-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org wrote:
> I did not look into the source... but usually the times are calculated:
> You take the capacity (remain-value) and divide it by the current. As the
> ACPI-1.0 spec only asks for a current-value, if you use a
> rechargable-battery and if this is in discharging-mode, you see, that they
> did only, what the specs asked as a minimum. I am not sure, if the
> current-value would not need to be -1, if it is unknown however.
> So it is quite clear, that dividing something (especially if this itself
> is not zero) by zero will give you an +overflow... with MAX_UINT (65535
> for 16bit) is the nearest representable value.
>

I'm much more a lazy man than that and much prefer to get those values
from the sensor ;)
The current is an int but it should be a short and is negative
if discharging. Look at smartbattery data spec at
http://www.sbs-forum.org/specs/index.html

And the 2 times given was the same actually. It's now corrected.

But as said, it's a first shot and smartbattery.c will soon be dead.

Problem is: from the ASL, there is 2 Smart Batteries and a Smart Battery
Selector (or a Smart Battery Manager).
I can go for the easy path at least for the smartbattery, since there is
already a driver for it in lm-sensors-2.9.0. But actually there may be more
than one battery that can be reached at the same address, then I'm for
sure that the smartbattery stuff from lm-sensors can not handle multiple
batteries.

--
Bruno Ducrot

-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.