| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 17 Mar 2015 11:37:46 +0100 From: Pavel Machek <pavel@....cz> To: "Dr. H. Nikolaus Schaller" <hns@...delico.com> Cc: Belisko Marek <marek.belisko@...il.com>, mark.rutland@....com, Sebastian Reichel <sre@...nel.org>, Dmitry Eremin-Solenikov <dbaryshkov@...il.com>, David Woodhouse <dwmw2@...radead.org>, Tony Lindgren <tony@...mide.com>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, Linux PM mailing list <linux-pm@...r.kernel.org>, GTA04 owners <gta04-owner@...delico.com> Subject: Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings Hi! > >>> to introduce coefficients for temperature and discharge rate? > >> What do you mean? Nothing like that is used in current driver why do > >> we need to add it? > > > > Well, conversion between Li-ion's voltage and state of charge at 0 > > current is well known: > > We can’t measure at 0 current since the OMAP is driven from battery > and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) > > def percent(m, v): > > u = 0.0387-(1.4523*(3.7835-v)) > > if u < 0: > > return 0 > > return (0.1966+math.sqrt(u))*100 > > > > And there's not much to calibrate there, and it should become library > > helper function; there's no need to write it to every single dts. > > > > The charge/discharge difference is due to internal battery resistance, > > and Ohm's law. (Then, you should not need different values for > > charging/discharging case.) > > Yes, and that also depends on the board and battery type. So you always > need to specify some battery specific coefficient for that in the DT. Yes, and that coefficient should be internal battery resistance ;-). > We simply did choose a table, because calculating the right coefficients > is more complex and getting the table values can easily be done from > running one full charge-discharge-charge cycle. Well.. One set of coefficients would be kind of ok. But you are doing two, because it really depends on current, not charge/discharge. So why not do it right, for all currents...? > > With your aproach, you'll get lower percentage when phone is under > > load vs. idle. Taking internal resistance into account would give you > > more precise readings. (Attached, old patch for zaurus shows the > > needed computation). > > This is why we have a charging and a discharging table to compensate > for this effect. Yes, but there's very different current during "idle" phone and during call (for example). So yes, you are compensating for different current during charge and discharge, but it is possible to do better. > > I guess this should go into library somewhere, because many machines > > need similar code. > > Is a library easier to maintain and handle than just a set of table > values? I think so, yes, because otherwise you need a set of tables for each machine. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists