[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110301193909.GB5649@oksana.dev.rtsoft.ru>
Date: Tue, 1 Mar 2011 22:39:09 +0300
From: Anton Vorontsov <cbouatmailru@...il.com>
To: rklein@...dia.com
Cc: olof@...om.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] power: bq20z75: add support for POWER_NOW
On Mon, Feb 28, 2011 at 04:55:30PM -0800, rklein@...dia.com wrote:
[...]
> +static int bq20z75_get_power_now(struct i2c_client *client,
> + union power_supply_propval *val)
> +{
> + int voltage_now = 0;
> + int current_now = 0;
> +
> + voltage_now = bq20z75_read_word_data(client,
> + bq20z75_data[REG_VOLTAGE].addr);
> + if (voltage_now < 0)
> + return voltage_now;
> +
> + current_now = bq20z75_read_word_data(client,
> + bq20z75_data[REG_CURRENT].addr);
> + if (current_now < 0)
> + return current_now;
> +
> + /* returned values are 16 bit */
> + current_now = (s16)current_now;
> + /* need to ensure it is positive */
> + current_now = abs(current_now);
> +
> + val->intval = voltage_now * current_now;
Nope, we don't do this in the drivers. It's a derived property, and
driver should not bother with these.
Documentation/power/power_supply_class.txt says:
- - - -
Q: Suppose, my battery monitoring chip/firmware does not provides capacity
in percents, but provides charge_{now,full,empty}. Should I calculate
percentage capacity manually, inside the driver, and register CAPACITY
attribute? The same question about time_to_empty/time_to_full.
A: Most likely, no. This class is designed to export properties which are
directly measurable by the specific hardware available.
Inferring not available properties using some heuristics or mathematical
model is not subject of work for a battery driver. Such functionality
should be factored out, and in fact, apm_power, the driver to serve
legacy APM API on top of power supply class, uses a simple heuristic of
approximating remaining battery capacity based on its charge, current,
voltage and so on. But full-fledged battery model is likely not subject
for kernel at all, as it would require floating point calculation to deal
with things like differential equations and Kalman filters. This is
better be handled by batteryd/libbattery, yet to be written.
- - - -
There were some ideas to write a kernel module that would provide
such "derived" properties for all the drivers. But drivers themselves
should not duplicate the generic logic.
Thanks,
--
Anton Vorontsov
Email: cbouatmailru@...il.com
--
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