Re: Re: first shoot for smartbattery

[Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>]

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.


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt