From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Starikovskiy Subject: Re: [PATCH] battery: Fix charge_now returned by broken batteries Date: Mon, 05 Oct 2009 02:38:44 +0400 Message-ID: <4AC923F4.9050100@suse.de> References: <1254669853.26496.0.camel@carter> <4AC8F02B.6080209@suse.de> <200910042246.23712.rjw@sisk.pl> <4AC91578.2020807@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from charybdis-ext.suse.de ([195.135.221.2]:43556 "EHLO emea5-mh.id5.novell.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754568AbZJDWjX (ORCPT ); Sun, 4 Oct 2009 18:39:23 -0400 In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Miguel Ojeda Cc: "Rafael J. Wysocki" , Henrique de Moraes Holschuh , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Miguel Ojeda =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Oct 4, 2009 at 11:36 PM, Alexey Starikovskiy > wrote: >> Hi Rafael, >> >> This is not my rule, it was/is the rule of power device class. If yo= u do not >> agree to it, please change >> appropriate documentation. >=20 > Oh, I did not know that. Thank you for pointing it out. I think you > are refering to: >=20 > 158Q: Suppose, my battery monitoring chip/firmware does not provides= capacity > 159 in percents, but provides charge_{now,full,empty}. Should I ca= lculate > 160 percentage capacity manually, inside the driver, and register = CAPACITY > 161 attribute? The same question about time_to_empty/time_to_full. > 162A: Most likely, no. This class is designed to export properties w= hich are > 163 directly measurable by the specific hardware available. > 164 > 165 Inferring not available properties using some heuristics or ma= thematical > 166 model is not subject of work for a battery driver. Such functi= onality > 167 should be factored out, and in fact, apm_power, the driver to = serve > 168 legacy APM API on top of power supply class, uses a simple heu= ristic of > 169 approximating remaining battery capacity based on its charge, = current, > 170 voltage and so on. But full-fledged battery model is likely no= t subject > 171 for kernel at all, as it would require floating point calculat= ion to deal > 172 with things like differential equations and Kalman filters. Th= is is > 173 better be handled by batteryd/libbattery, yet to be written. >=20 > We are not calculating anything new just by the pleasure of doing it, > we are correcting a wrong value provided by the hardware. You are guessing that normal battery can not jump charge value, and on = this assumption you cap charge_now with last full_charge. Immediate problem is that full_ch= arge is not fixed value, this is why it is separated from design_full_charge. During battery life full_charge may go down and up, depending on outsid= e temperature, battery discharge (full or partial). I've seen batteries on some new machines reporting full charge of more = than design charge. Obviously, your patch will fail in some of the above situations. Currently, reading from the driver is "last resort" to get un-interpret= ed value, if you have any doubts on it. With your patch, this is gone, and user space will have to interpret results= of kernel interpreter. Return to the "bug still exists". We are referring to the value, which = can not be measured directly with any known device. Thus, it may be completely sane that battery manufacturer provides you = with some charge curve, but knows only two values on it which he may trust -- point where he can not get any power out of it (c= omplete discharge) and point where he can not put any additional charge= into the battery (due to various stop conditions (battery temperature = being one)). In such a case manufacturer may choose to adjust charge cu= rve to end up always at design_full_charge point, no matter how much of= adjustment this requires. Do you have the same jump from >100% to 99% on discharge? Regards, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html