Messages in this thread | | | Date | Wed, 25 Oct 2006 16:42:35 +0200 | From | "Shem Multinymous" <> | Subject | Re: [PATCH v2] Re: Battery class driver. |
| |
Hi,
On 10/25/06, David Woodhouse <dwmw2@infradead.org> wrote: > If you can summarise the bits I've missed in the meantime that would be > wonderfully useful
OK. Looking at the current git snapshot:
current_now is missing.
time_remainig should be split into: time_to_empty_now time_to_empty_avg time_to_full or even time_to_empty_now time_to_empty_avg time_to_full_now time_to_full_avg
s/charge_count/cycle_count/, that's the standard name and used by the SBS spec.
Why the reversed order, for example, in design_charge vs. charge_last? Following hwmon style, I think it should be s/design_charge/charge_design/ s/manufacture_date/date_manufactured/ s/first_use/date_first_used/ s/design_voltage/voltage_design/
s/charge_last/charge_last_full/ seems less ambiguous.
s/^charge$/charge_left/ follows SBS and seems better.
And, for the reasons I explained earlier, I strongly suggest not using the term "charge" except when referring to the action of charging. Hence: s/charge_rate/rate/; s/charge/capacity/
It would be nice to have power_{now,avg}, always in mW regardless of the capacity units.
I take it you don't want to deal with battery control actions for now.
> > > one of the things I plan is to remove 'charge_units' and provide both > > > 'design_charge' and 'design_energy' (also {energy,charge}_last, > > > _*_thresh etc.) to cover the mWh vs. mAh cases. > > > > You can't do this conversion, since the voltage is not constant. > > Typically the voltage drops when the charge goes down, so you'll be > > grossly overestimating the available energy it. And the effect varies > > with battery chemistry and condition. > > Absolutely. I don't want to do the conversion -- I want to present the > raw data. I was just a question of whether I provide 'capacity' and > 'units' properties, or whether I provide 'capacity_mWh' and > 'capacity_mAh' properties (only one of which, presumably, would be > available for any given battery). Likewise for the rates, thresholds, > etc.
I think using one set of files and units string makes more sense, for several reasons: Reduces the number of attributes and kernel code duplication. Can handle weird power sources that use other units. Simpler userspace code. One can do $ cd /sys/foo; echo `cat capacity_left` out of `cat capacity_last` `cat capaity_units` left. instead of checking multiple sets of files for valid values.
The great majority of apps don't care about the physical values, but just need something that they can parse as a relative quantity and something to show the user. The generic units scheme provides both. We have current_*, voltage etc. for those that do care, but there's no need to duplicate the whole set of _thresholds, _last_full, _design etc.
Shem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |