lkml.org 
[lkml]   [2006]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-10-25 16:45    [W:0.023 / U:33.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site