Re: [PATCH 3/4] power: bq20z75: add support for POWER_NOW

[Anton Vorontsov]

On Mon, Feb 28, 2011 at 04:55:30PM -0800, rklein@xxxxxxxxxx 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@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/