[RFC PATCH 0/5] Add formula for LiIon batteries to compute capacity

[RFC PATCH 0/5] Add formula for LiIon batteries to compute capacity

[Marek Belisko]

This patches sitting in my repo for long time and would like to get feedback first before
submitting final series. This patches adding devicetree to generic-adc-battery driver
(we reuse it for gta04 board then and drop twl4030_madc_battery). Also add formula
for computing capacity of LiIon battery. This patches was tested on gta04 and
works fine. Thanks for comments.

Marek Belisko (5):
  dt-bindings: power: Add battery types
  power: generic-adc-battery: Parse more properties from DT
  power/generic-adc-battery: Add support for temperature and add check
    for charge from iio current channel
  power: Add formula for computing LiIon State of Charge from Voltage
  power: generic-adc-battery: Add capacity handling

 drivers/power/supply/generic-adc-battery.c | 100 ++++++++++++++++++++++++++++-
 include/dt-bindings/power/power.h          |  11 ++++
 include/linux/power/generic-fuel-gauge.h   |  38 +++++++++++
 3 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/power/power.h
 create mode 100644 include/linux/power/generic-fuel-gauge.h

-- 
2.7.4

[RFC PATCH 1/5] dt-bindings: power: Add battery types

[Marek Belisko]

From: Marek Belisko <marek.belisko@gmail.com>

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
 include/dt-bindings/power/power.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 include/dt-bindings/power/power.h

diff --git a/include/dt-bindings/power/power.h b/include/dt-bindings/power/power.h
new file mode 100644
index 0000000..ea36d7f
--- /dev/null
+++ b/include/dt-bindings/power/power.h
@@ -0,0 +1,11 @@
+#ifndef _DT_BINDINGS_POWER_H
+#define _DT_BINDINGS_POWER_H
+
+#define POWER_SUPPLY_TECHNOLOGY_NiMH 1
+#define POWER_SUPPLY_TECHNOLOGY_LION 2
+#define POWER_SUPPLY_TECHNOLOGY_LIPO 3
+#define POWER_SUPPLY_TECHNOLOGY_LiFe 4
+#define POWER_SUPPLY_TECHNOLOGY_NiCd 5
+#define POWER_SUPPLY_TECHNOLOGY_LiMn 6
+
+#endif /* _DT_BINDINGS_POWER_H */
-- 
2.7.4

Re: [RFC PATCH 1/5] dt-bindings: power: Add battery types

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Tue 2017-08-01 22:55:22, Marek Belisko wrote:
> From: Marek Belisko <marek.belisko@gmail.com>
> 
> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
> ---
>  include/dt-bindings/power/power.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 include/dt-bindings/power/power.h
> 
> diff --git a/include/dt-bindings/power/power.h b/include/dt-bindings/power/power.h
> new file mode 100644
> index 0000000..ea36d7f
> --- /dev/null
> +++ b/include/dt-bindings/power/power.h
> @@ -0,0 +1,11 @@
> +#ifndef _DT_BINDINGS_POWER_H
> +#define _DT_BINDINGS_POWER_H
> +
> +#define POWER_SUPPLY_TECHNOLOGY_NiMH 1
> +#define POWER_SUPPLY_TECHNOLOGY_LION 2

Nice animal :-), but I guess this should be "LiION" or something.

> +#define POWER_SUPPLY_TECHNOLOGY_LIPO 3

Make it "LiPo" for consistency.

There's no differnce between Li-ion and Li-Po from the software side,
AFAICT, but I guess we can keep both..

> +#define POWER_SUPPLY_TECHNOLOGY_LiFe 4
> +#define POWER_SUPPLY_TECHNOLOGY_NiCd 5
> +#define POWER_SUPPLY_TECHNOLOGY_LiMn 6
> +
> +#endif /* _DT_BINDINGS_POWER_H */

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [RFC PATCH 1/5] dt-bindings: power: Add battery types

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Hi!

> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
> ---
>  include/dt-bindings/power/power.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 include/dt-bindings/power/power.h
> 
> diff --git a/include/dt-bindings/power/power.h b/include/dt-bindings/power/power.h
> new file mode 100644
> index 0000000..ea36d7f
> --- /dev/null
> +++ b/include/dt-bindings/power/power.h
> @@ -0,0 +1,11 @@
> +#ifndef _DT_BINDINGS_POWER_H
> +#define _DT_BINDINGS_POWER_H
> +
> +#define POWER_SUPPLY_TECHNOLOGY_NiMH 1
> +#define POWER_SUPPLY_TECHNOLOGY_LION 2
> +#define POWER_SUPPLY_TECHNOLOGY_LIPO 3
> +#define POWER_SUPPLY_TECHNOLOGY_LiFe 4

Actually I'd add comments here, such as "/* LiFePO4 */, because
otherwise it is a bit ambiguous.

> +#define POWER_SUPPLY_TECHNOLOGY_NiCd 5
> +#define POWER_SUPPLY_TECHNOLOGY_LiMn 6
> +
> +#endif /* _DT_BINDINGS_POWER_H */

The rest of series is ok, you can add

Acked-by: Pavel Machek <pavel@ucw.cz>

, but I guess someone would want a little more verbose changelogs.

BTW what hardware are you working with?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [RFC PATCH 1/5] dt-bindings: power: Add battery types

[Belisko Marek]

Hi Pavel,

On Wed, Aug 2, 2017 at 1:43 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
>> ---
>>  include/dt-bindings/power/power.h | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 include/dt-bindings/power/power.h
>>
>> diff --git a/include/dt-bindings/power/power.h b/include/dt-bindings/power/power.h
>> new file mode 100644
>> index 0000000..ea36d7f
>> --- /dev/null
>> +++ b/include/dt-bindings/power/power.h
>> @@ -0,0 +1,11 @@
>> +#ifndef _DT_BINDINGS_POWER_H
>> +#define _DT_BINDINGS_POWER_H
>> +
>> +#define POWER_SUPPLY_TECHNOLOGY_NiMH 1
>> +#define POWER_SUPPLY_TECHNOLOGY_LION 2
>> +#define POWER_SUPPLY_TECHNOLOGY_LIPO 3
>> +#define POWER_SUPPLY_TECHNOLOGY_LiFe 4
>
> Actually I'd add comments here, such as "/* LiFePO4 */, because
> otherwise it is a bit ambiguous.

OK.
>
>> +#define POWER_SUPPLY_TECHNOLOGY_NiCd 5
>> +#define POWER_SUPPLY_TECHNOLOGY_LiMn 6
>> +
>> +#endif /* _DT_BINDINGS_POWER_H */
>
> The rest of series is ok, you can add
>
> Acked-by: Pavel Machek <pavel@ucw.cz>
>
> , but I guess someone would want a little more verbose changelogs.
Yes I'll post final series with updated commit messages. Thanks.
>
> BTW what hardware are you working with?
We have working it on gta04 board. Also after this will be merged we
can drop custom battery driver
for gta04 and use this generic (maybe also other drivers can reuse this one).
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

BR,

marek


-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[RFC PATCH 2/5] power: generic-adc-battery: Parse more properties from DT

[Marek Belisko]

From: Marek Belisko <marek.belisko@gmail.com>

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
 drivers/power/supply/generic-adc-battery.c | 68 ++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
index b5e9208..d4daa6a 100644
--- a/drivers/power/supply/generic-adc-battery.c
+++ b/drivers/power/supply/generic-adc-battery.c
@@ -23,6 +23,7 @@
 #include <linux/iio/consumer.h>
 #include <linux/iio/types.h>
 #include <linux/power/generic-adc-battery.h>
+#include <linux/of_gpio.h>
 
 #define JITTER_DEFAULT 10 /* hope 10ms is enough */
 
@@ -241,6 +242,69 @@ static irqreturn_t gab_charged(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+#ifdef CONFIG_OF
+static struct gab_platform_data *gab_dt_probe(struct platform_device *pdev)
+{
+	struct gab_platform_data *pdata;
+	struct device_node *np = pdev->dev.of_node;
+	const char *name;
+	u32 val;
+	int err;
+
+	pdata = devm_kzalloc(&pdev->dev,
+			sizeof(struct gab_platform_data),
+			GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	pdata->gpio_charge_finished  = of_get_gpio(np, 0);
+
+	/* parse and fill power_supply_info struct */
+	err = of_property_read_u32(np, "technology", &val);
+	if (err) {
+		dev_info(&pdev->dev, "Battery technology unknown\n");
+		val = 0;
+	}
+	pdata->battery_info.technology = val;
+
+	err = of_property_read_string(np, "battery-name", &name);
+	if (err) {
+		dev_info(&pdev->dev, "Battery name empty, setting default\n");
+	}
+	pdata->battery_info.name = name;
+
+	val = 0;
+	err = of_property_read_u32(np, "charge_empty_design", &val);
+	pdata->battery_info.charge_empty_design = val;
+
+	val = 0;
+	err = of_property_read_u32(np, "charge_full_design", &val);
+	pdata->battery_info.charge_full_design = val;
+
+	val = 0;
+	err = of_property_read_u32(np, "voltage_min_design", &val);
+	pdata->battery_info.voltage_min_design = val;
+
+	val = 0;
+	err = of_property_read_u32(np, "voltage_max-design", &val);
+	pdata->battery_info.voltage_max_design = val;
+
+	return pdata;
+}
+
+static const struct of_device_id of_gab_match[] = {
+	{ .compatible = "linux,generic-adc-battery", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_gab_match);
+
+#else
+static struct gab_platform_data gab_dt_probe(struct platform_device *pdev)
+{
+	ERR_PTR(-ENODEV);
+}
+#endif
+
 static int gab_probe(struct platform_device *pdev)
 {
 	struct gab *adc_bat;
@@ -258,6 +322,9 @@ static int gab_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	if (pdata == NULL)
+		pdata = gab_dt_probe(pdev);
+
 	psy_cfg.drv_data = adc_bat;
 	psy_desc = &adc_bat->psy_desc;
 	psy_desc->name = "generic-adc-batt";//pdata->battery_info.name;
@@ -418,6 +485,7 @@ static struct platform_driver gab_driver = {
 	.driver		= {
 		.name	= "generic-adc-battery",
 		.pm	= &gab_pm_ops,
+		.of_match_table = of_gab_match,
 	},
 	.probe		= gab_probe,
 	.remove		= gab_remove,
-- 
2.7.4

Re: [RFC PATCH 2/5] power: generic-adc-battery: Parse more properties from DT

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Hi!

> +#ifdef CONFIG_OF
> +static struct gab_platform_data *gab_dt_probe(struct platform_device *pdev)
> +{
> +	struct gab_platform_data *pdata;
> +	struct device_node *np = pdev->dev.of_node;
> +	const char *name;
> +	u32 val;
> +	int err;
> +
> +	pdata = devm_kzalloc(&pdev->dev,
> +			sizeof(struct gab_platform_data),
> +			GFP_KERNEL);
> +	if (!pdata)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pdata->gpio_charge_finished  = of_get_gpio(np, 0);
> +
> +	/* parse and fill power_supply_info struct */
> +	err = of_property_read_u32(np, "technology", &val);
> +	if (err) {
> +		dev_info(&pdev->dev, "Battery technology unknown\n");
> +		val = 0;
> +	}
> +	pdata->battery_info.technology = val;
> +
> +	err = of_property_read_string(np, "battery-name", &name);
> +	if (err) {
> +		dev_info(&pdev->dev, "Battery name empty, setting default\n");
> +	}
> +	pdata->battery_info.name = name;

Actually ... looking at this once more. These are new properties,
right?

They'll need to be documented:

pavel@duo:/data/l/linux$ grep -ri battery-name Documentation/devicetree/

shows empty.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [RFC PATCH 2/5] power: generic-adc-battery: Parse more properties from DT

[Belisko Marek]

Hi Pavel,

On Wed, Aug 2, 2017 at 1:56 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> +#ifdef CONFIG_OF
>> +static struct gab_platform_data *gab_dt_probe(struct platform_device *pdev)
>> +{
>> +     struct gab_platform_data *pdata;
>> +     struct device_node *np = pdev->dev.of_node;
>> +     const char *name;
>> +     u32 val;
>> +     int err;
>> +
>> +     pdata = devm_kzalloc(&pdev->dev,
>> +                     sizeof(struct gab_platform_data),
>> +                     GFP_KERNEL);
>> +     if (!pdata)
>> +             return ERR_PTR(-ENOMEM);
>> +
>> +     pdata->gpio_charge_finished  = of_get_gpio(np, 0);
>> +
>> +     /* parse and fill power_supply_info struct */
>> +     err = of_property_read_u32(np, "technology", &val);
>> +     if (err) {
>> +             dev_info(&pdev->dev, "Battery technology unknown\n");
>> +             val = 0;
>> +     }
>> +     pdata->battery_info.technology = val;
>> +
>> +     err = of_property_read_string(np, "battery-name", &name);
>> +     if (err) {
>> +             dev_info(&pdev->dev, "Battery name empty, setting default\n");
>> +     }
>> +     pdata->battery_info.name = name;
>
> Actually ... looking at this once more. These are new properties,
> right?
>
> They'll need to be documented:
>
> pavel@duo:/data/l/linux$ grep -ri battery-name Documentation/devicetree/
>
> shows empty.
You're right. I'll add bindings documentation. Thanks.
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [RFC PATCH 2/5] power: generic-adc-battery: Parse more properties from DT

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3502 bytes --]

Hi,

On Tue, Aug 01, 2017 at 10:55:23PM +0200, Marek Belisko wrote:
> From: Marek Belisko <marek.belisko@gmail.com>
> 
> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>

This should use the infrastructure described here:

Documentation/devicetree/bindings/power/supply/battery.txt

-- Sebastian

> ---
>  drivers/power/supply/generic-adc-battery.c | 68 ++++++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
> index b5e9208..d4daa6a 100644
> --- a/drivers/power/supply/generic-adc-battery.c
> +++ b/drivers/power/supply/generic-adc-battery.c
> @@ -23,6 +23,7 @@
>  #include <linux/iio/consumer.h>
>  #include <linux/iio/types.h>
>  #include <linux/power/generic-adc-battery.h>
> +#include <linux/of_gpio.h>
>  
>  #define JITTER_DEFAULT 10 /* hope 10ms is enough */
>  
> @@ -241,6 +242,69 @@ static irqreturn_t gab_charged(int irq, void *dev_id)
>  	return IRQ_HANDLED;
>  }
>  
> +#ifdef CONFIG_OF
> +static struct gab_platform_data *gab_dt_probe(struct platform_device *pdev)
> +{
> +	struct gab_platform_data *pdata;
> +	struct device_node *np = pdev->dev.of_node;
> +	const char *name;
> +	u32 val;
> +	int err;
> +
> +	pdata = devm_kzalloc(&pdev->dev,
> +			sizeof(struct gab_platform_data),
> +			GFP_KERNEL);
> +	if (!pdata)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pdata->gpio_charge_finished  = of_get_gpio(np, 0);
> +
> +	/* parse and fill power_supply_info struct */
> +	err = of_property_read_u32(np, "technology", &val);
> +	if (err) {
> +		dev_info(&pdev->dev, "Battery technology unknown\n");
> +		val = 0;
> +	}
> +	pdata->battery_info.technology = val;
> +
> +	err = of_property_read_string(np, "battery-name", &name);
> +	if (err) {
> +		dev_info(&pdev->dev, "Battery name empty, setting default\n");
> +	}
> +	pdata->battery_info.name = name;
> +
> +	val = 0;
> +	err = of_property_read_u32(np, "charge_empty_design", &val);
> +	pdata->battery_info.charge_empty_design = val;
> +
> +	val = 0;
> +	err = of_property_read_u32(np, "charge_full_design", &val);
> +	pdata->battery_info.charge_full_design = val;
> +
> +	val = 0;
> +	err = of_property_read_u32(np, "voltage_min_design", &val);
> +	pdata->battery_info.voltage_min_design = val;
> +
> +	val = 0;
> +	err = of_property_read_u32(np, "voltage_max-design", &val);
> +	pdata->battery_info.voltage_max_design = val;
> +
> +	return pdata;
> +}
> +
> +static const struct of_device_id of_gab_match[] = {
> +	{ .compatible = "linux,generic-adc-battery", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, of_gab_match);
> +
> +#else
> +static struct gab_platform_data gab_dt_probe(struct platform_device *pdev)
> +{
> +	ERR_PTR(-ENODEV);
> +}
> +#endif
> +
>  static int gab_probe(struct platform_device *pdev)
>  {
>  	struct gab *adc_bat;
> @@ -258,6 +322,9 @@ static int gab_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> +	if (pdata == NULL)
> +		pdata = gab_dt_probe(pdev);
> +
>  	psy_cfg.drv_data = adc_bat;
>  	psy_desc = &adc_bat->psy_desc;
>  	psy_desc->name = "generic-adc-batt";//pdata->battery_info.name;
> @@ -418,6 +485,7 @@ static struct platform_driver gab_driver = {
>  	.driver		= {
>  		.name	= "generic-adc-battery",
>  		.pm	= &gab_pm_ops,
> +		.of_match_table = of_gab_match,
>  	},
>  	.probe		= gab_probe,
>  	.remove		= gab_remove,
> -- 
> 2.7.4
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC PATCH 3/5] power/generic-adc-battery: Add support for temperature and add check for charge from iio current channel

[Marek Belisko]

From: Marek Belisko <marek.belisko@gmail.com>

Status reporting not working yet. During boot when workqueue is called status
is updated (by reading iio current channel but value is -705 (reason unknown as later
report correct value).

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
 drivers/power/supply/generic-adc-battery.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
index d4daa6a..0d27b59 100644
--- a/drivers/power/supply/generic-adc-battery.c
+++ b/drivers/power/supply/generic-adc-battery.c
@@ -31,6 +31,7 @@ enum gab_chan_type {
 	GAB_VOLTAGE = 0,
 	GAB_CURRENT,
 	GAB_POWER,
+	GAB_TEMPERATURE,
 	GAB_MAX_CHAN_TYPE
 };
 
@@ -41,7 +42,8 @@ enum gab_chan_type {
 static const char *const gab_chan_name[] = {
 	[GAB_VOLTAGE]	= "voltage",
 	[GAB_CURRENT]	= "current",
-	[GAB_POWER]		= "power",
+	[GAB_POWER]	= "power",
+	[GAB_TEMPERATURE] = "temperature",
 };
 
 struct gab {
@@ -78,6 +80,7 @@ static const enum power_supply_property gab_props[] = {
 	POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
 	POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
 	POWER_SUPPLY_PROP_MODEL_NAME,
+	POWER_SUPPLY_PROP_TEMP,
 };
 
 /*
@@ -123,6 +126,8 @@ static enum gab_chan_type gab_prop_to_chan(enum power_supply_property psp)
 		return GAB_VOLTAGE;
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
 		return GAB_CURRENT;
+	case POWER_SUPPLY_PROP_TEMP:
+		return GAB_TEMPERATURE;
 	default:
 		WARN_ON(1);
 		break;
@@ -176,6 +181,7 @@ static int gab_get_property(struct power_supply *psy,
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
 	case POWER_SUPPLY_PROP_POWER_NOW:
+	case POWER_SUPPLY_PROP_TEMP:
 		ret = read_channel(adc_bat, psp, &result);
 		if (ret < 0)
 			goto err;
@@ -210,13 +216,19 @@ static void gab_work(struct work_struct *work)
 	struct delayed_work *delayed_work;
 	bool is_plugged;
 	int status;
+	int ret, iio_charge;
 
 	delayed_work = to_delayed_work(work);
 	adc_bat = container_of(delayed_work, struct gab, bat_work);
 	pdata = adc_bat->pdata;
 	status = adc_bat->status;
-
-	is_plugged = power_supply_am_i_supplied(adc_bat->psy);
+	ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &iio_charge);
+	if (ret < 0) {
+		pr_info("Cannot read current channel, ret:%d\n", ret);
+		iio_charge = 0;
+	} else
+		pr_info("iio_charge:%d\n", iio_charge);
+	is_plugged = power_supply_am_i_supplied(adc_bat->psy) || (iio_charge > 0);
 	adc_bat->cable_plugged = is_plugged;
 
 	if (!is_plugged)
-- 
2.7.4

Re: [RFC PATCH 3/5] power/generic-adc-battery: Add support for temperature and add check for charge from iio current channel

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3181 bytes --]

Hi,

On Tue, Aug 01, 2017 at 10:55:24PM +0200, Marek Belisko wrote:
> From: Marek Belisko <marek.belisko@gmail.com>
> 
> Status reporting not working yet. During boot when workqueue is called status
> is updated (by reading iio current channel but value is -705 (reason unknown as later
> report correct value).
> 
> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
> ---
>  drivers/power/supply/generic-adc-battery.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
> index d4daa6a..0d27b59 100644
> --- a/drivers/power/supply/generic-adc-battery.c
> +++ b/drivers/power/supply/generic-adc-battery.c
> @@ -31,6 +31,7 @@ enum gab_chan_type {
>  	GAB_VOLTAGE = 0,
>  	GAB_CURRENT,
>  	GAB_POWER,
> +	GAB_TEMPERATURE,
>  	GAB_MAX_CHAN_TYPE
>  };
>  
> @@ -41,7 +42,8 @@ enum gab_chan_type {
>  static const char *const gab_chan_name[] = {
>  	[GAB_VOLTAGE]	= "voltage",
>  	[GAB_CURRENT]	= "current",
> -	[GAB_POWER]		= "power",
> +	[GAB_POWER]	= "power",
> +	[GAB_TEMPERATURE] = "temperature",
>  };
>  
>  struct gab {
> @@ -78,6 +80,7 @@ static const enum power_supply_property gab_props[] = {
>  	POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
>  	POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
>  	POWER_SUPPLY_PROP_MODEL_NAME,
> +	POWER_SUPPLY_PROP_TEMP,
>  };
>  
>  /*
> @@ -123,6 +126,8 @@ static enum gab_chan_type gab_prop_to_chan(enum power_supply_property psp)
>  		return GAB_VOLTAGE;
>  	case POWER_SUPPLY_PROP_CURRENT_NOW:
>  		return GAB_CURRENT;
> +	case POWER_SUPPLY_PROP_TEMP:
> +		return GAB_TEMPERATURE;
>  	default:
>  		WARN_ON(1);
>  		break;
> @@ -176,6 +181,7 @@ static int gab_get_property(struct power_supply *psy,
>  	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
>  	case POWER_SUPPLY_PROP_CURRENT_NOW:
>  	case POWER_SUPPLY_PROP_POWER_NOW:
> +	case POWER_SUPPLY_PROP_TEMP:
>  		ret = read_channel(adc_bat, psp, &result);
>  		if (ret < 0)
>  			goto err;
> @@ -210,13 +216,19 @@ static void gab_work(struct work_struct *work)
>  	struct delayed_work *delayed_work;
>  	bool is_plugged;
>  	int status;
> +	int ret, iio_charge;
>  
>  	delayed_work = to_delayed_work(work);
>  	adc_bat = container_of(delayed_work, struct gab, bat_work);
>  	pdata = adc_bat->pdata;
>  	status = adc_bat->status;
> -
> -	is_plugged = power_supply_am_i_supplied(adc_bat->psy);
> +	ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &iio_charge);
> +	if (ret < 0) {
> +		pr_info("Cannot read current channel, ret:%d\n", ret);
> +		iio_charge = 0;
> +	} else
> +		pr_info("iio_charge:%d\n", iio_charge);
> +	is_plugged = power_supply_am_i_supplied(adc_bat->psy) || (iio_charge > 0);

This has nothing to do with adding temperature support and
I suspect, that you are missing proper supplied_by configuration,
so that power_supply_am_i_supplied does not work. Have a look at
the following file:

Documentation/devicetree/bindings/power/supply/power_supply.txt

-- Sebastian

>  	adc_bat->cable_plugged = is_plugged;
>  
>  	if (!is_plugged)
> -- 
> 2.7.4
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[RFC PATCH 4/5] power: Add formula for computing LiIon State of Charge from Voltage

[Marek Belisko]

From: Marek Belisko <marek.belisko@gmail.com>

The formula appears to be known in RC model communities.
We did find the first reference on the web in a a forum post
by "SilverFox" from 04-16-2008:

http://www.candlepowerforums.com/vb/showthread.php?115871-Li-Ion-State-of-Charge-and-Voltage-Measurements#post2440539

Some other posts attribute it to Sanyo.

The linear interpplation below 19.66% was suggested by Pavel Machek.

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
 include/linux/power/generic-fuel-gauge.h | 38 ++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 include/linux/power/generic-fuel-gauge.h

diff --git a/include/linux/power/generic-fuel-gauge.h b/include/linux/power/generic-fuel-gauge.h
new file mode 100644
index 0000000..2da7825
--- /dev/null
+++ b/include/linux/power/generic-fuel-gauge.h
@@ -0,0 +1,38 @@
+#ifndef PWR_GENERIC_FUEL_GAUSE_H
+#define PWR_GENERIC_FUEL_GAUSE_H
+
+/* calculate remaining fuel level (in %) of a LiIon battery assuming
+ * a standard chemistry model
+ *    The first reference found on the web seems to be a forum post
+ *    by "SilverFox" from 04-16-2008. It appears to be attributed to Sanyo.
+ *    http://www.candlepowerforums.com/vb/showthread.php?115871-Li-Ion-State-of-Charge-and-Voltage-Measurements#post2440539
+ *    The linear interpplation below 19.66% was suggested by Pavel Machek.
+ *
+ * @mV: voltage measured outside the battery
+ * @mA: current flowing out of the battery
+ * @mOhm: assumed series resitance of the battery
+ *
+ * returns value between 0 and 100
+ */
+static inline int fuel_level_LiIon(int mV, int mA, int mOhm) {
+	int u;
+
+	/* internal battery voltage is higher than measured when discharging */
+	mV += (mOhm * mA) /1000;
+
+	if (mV == 0)
+		return 0;
+
+	/* apply first part of formula */
+	u = 3870000 - (14523 * (37835 - 10 * mV));
+
+	/* use linear approx. below 3.756V => 19.66% assuming 3.3V => 0% */
+	if (u < 0) {
+		return  max(((mV - 3300) * ((3756 - 3300) * 1966)) / 100000000, 0);
+	}
+
+	/* apply second part of formula */
+	return min((int)(1966 + int_sqrt(u))/100, 100);	
+}
+
+#endif /* PWR_GENERIC_FUEL_GAUSE_H */
-- 
2.7.4

[RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Marek Belisko]

From: Marek Belisko <marek.belisko@gmail.com>

Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
---
 drivers/power/supply/generic-adc-battery.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
index 0d27b59..9ce51d2 100644
--- a/drivers/power/supply/generic-adc-battery.c
+++ b/drivers/power/supply/generic-adc-battery.c
@@ -24,6 +24,7 @@
 #include <linux/iio/types.h>
 #include <linux/power/generic-adc-battery.h>
 #include <linux/of_gpio.h>
+#include <linux/power/generic-fuel-gauge.h>
 
 #define JITTER_DEFAULT 10 /* hope 10ms is enough */
 
@@ -81,6 +82,7 @@ static const enum power_supply_property gab_props[] = {
 	POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
 	POWER_SUPPLY_PROP_MODEL_NAME,
 	POWER_SUPPLY_PROP_TEMP,
+	POWER_SUPPLY_PROP_CAPACITY,
 };
 
 /*
@@ -202,6 +204,18 @@ static int gab_get_property(struct power_supply *psy,
 	case POWER_SUPPLY_PROP_MODEL_NAME:
 		val->strval = bat_info->name;
 		break;
+	case POWER_SUPPLY_PROP_CAPACITY:
+		{
+		int ret, curr, voltage;
+
+		ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &curr);
+		ret |= read_channel(adc_bat, POWER_SUPPLY_PROP_VOLTAGE_NOW, &voltage);
+		if (ret < 0)
+			goto err;
+
+		val->intval = fuel_level_LiIon(voltage, curr, 10);
+		}
+		break;
 	default:
 		return -EINVAL;
 	}
-- 
2.7.4

Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Hi,

On Tue, Aug 01, 2017 at 10:55:26PM +0200, Marek Belisko wrote:
> From: Marek Belisko <marek.belisko@gmail.com>
> 
> Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
> ---
>  drivers/power/supply/generic-adc-battery.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
> index 0d27b59..9ce51d2 100644
> --- a/drivers/power/supply/generic-adc-battery.c
> +++ b/drivers/power/supply/generic-adc-battery.c
> @@ -24,6 +24,7 @@
>  #include <linux/iio/types.h>
>  #include <linux/power/generic-adc-battery.h>
>  #include <linux/of_gpio.h>
> +#include <linux/power/generic-fuel-gauge.h>
>  
>  #define JITTER_DEFAULT 10 /* hope 10ms is enough */
>  
> @@ -81,6 +82,7 @@ static const enum power_supply_property gab_props[] = {
>  	POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
>  	POWER_SUPPLY_PROP_MODEL_NAME,
>  	POWER_SUPPLY_PROP_TEMP,
> +	POWER_SUPPLY_PROP_CAPACITY,
>  };
>  
>  /*
> @@ -202,6 +204,18 @@ static int gab_get_property(struct power_supply *psy,
>  	case POWER_SUPPLY_PROP_MODEL_NAME:
>  		val->strval = bat_info->name;
>  		break;
> +	case POWER_SUPPLY_PROP_CAPACITY:
> +		{
> +		int ret, curr, voltage;
> +
> +		ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &curr);
> +		ret |= read_channel(adc_bat, POWER_SUPPLY_PROP_VOLTAGE_NOW, &voltage);
> +		if (ret < 0)
> +			goto err;
> +
> +		val->intval = fuel_level_LiIon(voltage, curr, 10);
> +		}
> +		break;
>  	default:
>  		return -EINVAL;
>  	}

Without patch description: See Last Question in

Documentation/power/power_supply_class.txt

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Hi!

> > +	case POWER_SUPPLY_PROP_CAPACITY:
> > +		{
> > +		int ret, curr, voltage;
> > +
> > +		ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &curr);
> > +		ret |= read_channel(adc_bat, POWER_SUPPLY_PROP_VOLTAGE_NOW, &voltage);
> > +		if (ret < 0)
> > +			goto err;
> > +
> > +		val->intval = fuel_level_LiIon(voltage, curr, 10);
> > +		}
> > +		break;
> >  	default:
> >  		return -EINVAL;
> >  	}
> 
> Without patch description: See Last Question in
> 
> Documentation/power/power_supply_class.txt

...should be done in libbattery, yet to be written. :-).

Do you have specific guidance what you'd like to see in libbattery?

I was thinking about creating lib_pocket_hardware -- that would hide
battery details, plus other phone-related stuff such as LEDs,
backlights, temperatures, ...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Hi,

> Am 08.09.2017 um 13:32 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> +	case POWER_SUPPLY_PROP_CAPACITY:
>>> +		{
>>> +		int ret, curr, voltage;
>>> +
>>> +		ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &curr);
>>> +		ret |= read_channel(adc_bat, POWER_SUPPLY_PROP_VOLTAGE_NOW, &voltage);
>>> +		if (ret < 0)
>>> +			goto err;
>>> +
>>> +		val->intval = fuel_level_LiIon(voltage, curr, 10);
>>> +		}
>>> +		break;
>>> 	default:
>>> 		return -EINVAL;
>>> 	}
>> 
>> Without patch description: See Last Question in
>> 
>> Documentation/power/power_supply_class.txt

The main argument to answer with "Most likely, no" seems to be:

"  as it would require floating point calculation to deal
   with things like differential equations and Kalman filters."

The code shown above uses none of such things, hence the answer
could as well be "Yes, if it is simple enough to be handled by
the kernel with some lines of code and integer arithmetic".

> 
> ...should be done in libbattery, yet to be written. :-).

For 10 years... Doesn't seem like anyone is waiting for it.

> 
> Do you have specific guidance what you'd like to see in libbattery?

As a poor user I'd expect it to be available and widely accepted by
major distributions and battery monitoring applications in max. 3 months.

If that is not possible, I'd recommend to toss overboard a 10 years old
"maybe" rule and just fix the single problem once and for all in the
generic-adc-battery driver instead of dreaming of user space magically
solving problems where we already have a proposal for a kernel solution.

We should not forget that all this work is just to replace the pdata
based drivers/power/supply/twl4030_madc_battery.c with a proper and
more general DT based solution.

Nothing new, no rocket science (differential equations and Kalman filters)
expected.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Hi,

> Am 08.09.2017 um 13:32 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> +	case POWER_SUPPLY_PROP_CAPACITY:
>>> +		{
>>> +		int ret, curr, voltage;
>>> +
>>> +		ret = read_channel(adc_bat, POWER_SUPPLY_PROP_CURRENT_NOW, &curr);
>>> +		ret |= read_channel(adc_bat, POWER_SUPPLY_PROP_VOLTAGE_NOW, &voltage);
>>> +		if (ret < 0)
>>> +			goto err;
>>> +
>>> +		val->intval = fuel_level_LiIon(voltage, curr, 10);
>>> +		}
>>> +		break;
>>> 	default:
>>> 		return -EINVAL;
>>> 	}
>> 
>> Without patch description: See Last Question in
>> 
>> Documentation/power/power_supply_class.txt

The main argument to answer with "Most likely, no" seems to be:

"  as it would require floating point calculation to deal
   with things like differential equations and Kalman filters."

The code shown above uses none of such things, hence the answer
could as well be "Yes, if it is simple enough to be handled by
the kernel with some lines of code and integer arithmetic".

> 
> ...should be done in libbattery, yet to be written. :-).

For 10 years... Doesn't seem like anyone is waiting for it.

> 
> Do you have specific guidance what you'd like to see in libbattery?

As a poor user I'd expect it to be available and widely accepted by
major distributions and battery monitoring applications in max. 3 months.

If that is not possible, I'd recommend to toss overboard a 10 years old
"maybe" rule and just fix the single problem once and for all in the
generic-adc-battery driver instead of dreaming of user space magically
solving problems where we already have a proposal for a kernel solution.

We should not forget that all this work is just to replace the pdata
based drivers/power/supply/twl4030_madc_battery.c with a proper and
more general DT based solution.

Nothing new, no rocket science (differential equations and Kalman filters)
expected.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Hi!

> > Without patch description: See Last Question in
> > 
> > Documentation/power/power_supply_class.txt
> 
> ...should be done in libbattery, yet to be written. :-).
> 
> Do you have specific guidance what you'd like to see in libbattery?

So I started something, it is at.

https://github.com/pavelmachek/libbattery

My battery on n900 is currently uncalibrated (and charging), still it
gets some kind of estimation:

Battery -1 %
Seconds -1
State 1
Voltage 3.88 V
Battery 63 %

Of course, there's a lot more work to be done.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

Hi!

> > Without patch description: See Last Question in
> > 
> > Documentation/power/power_supply_class.txt
> 
> ...should be done in libbattery, yet to be written. :-).
> 
> Do you have specific guidance what you'd like to see in libbattery?

So I started something, it is at.

https://github.com/pavelmachek/libbattery

My battery on n900 is currently uncalibrated (and charging), still it
gets some kind of estimation:

Battery -1 %
Seconds -1
State 1
Voltage 3.88 V
Battery 63 %

Of course, there's a lot more work to be done.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/fb6dfa3d/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Hi!

> > Without patch description: See Last Question in
> > 
> > Documentation/power/power_supply_class.txt
> 
> ...should be done in libbattery, yet to be written. :-).
> 
> Do you have specific guidance what you'd like to see in libbattery?

So I started something, it is at.

https://github.com/pavelmachek/libbattery

My battery on n900 is currently uncalibrated (and charging), still it
gets some kind of estimation:

Battery -1 %
Seconds -1
State 1
Voltage 3.88 V
Battery 63 %

Of course, there's a lot more work to be done.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]


> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Without patch description: See Last Question in
>>> 
>>> Documentation/power/power_supply_class.txt
>> 
>> ...should be done in libbattery, yet to be written. :-).
>> 
>> Do you have specific guidance what you'd like to see in libbattery?

IMHO there was no answer from maintainers. Or I have not received it.

> 
> So I started something, it is at.
> 
> https://github.com/pavelmachek/libbattery
> 
> My battery on n900 is currently uncalibrated (and charging), still it
> gets some kind of estimation:
> 
> Battery -1 %
> Seconds -1
> State 1
> Voltage 3.88 V
> Battery 63 %
> 
> Of course, there's a lot more work to be done.

Nice start but not a solution to our problem.

Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
displays the battery percentage.

With using generic-adc-battery driver and Marek's patch in kernel, this can easily be provided.

With exactly 0 bits of change in user space. Please note that you can't always tell users "upgrade to the latest user space".

So I have three questions:
a) why do you use float/double instead of fixed point for such simple and imprecise calculations?
b) what does it provide as additional information over some lines of code in generic-adc-battery driver?
c) how do yo make sure that this libbattery is included in all the battery monitors that are already in use and
is backported for example to the old plugin I mentioned above?

BR and thanks,
Nikolaus



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Without patch description: See Last Question in
>>> 
>>> Documentation/power/power_supply_class.txt
>> 
>> ...should be done in libbattery, yet to be written. :-).
>> 
>> Do you have specific guidance what you'd like to see in libbattery?

IMHO there was no answer from maintainers. Or I have not received it.

> 
> So I started something, it is at.
> 
> https://github.com/pavelmachek/libbattery
> 
> My battery on n900 is currently uncalibrated (and charging), still it
> gets some kind of estimation:
> 
> Battery -1 %
> Seconds -1
> State 1
> Voltage 3.88 V
> Battery 63 %
> 
> Of course, there's a lot more work to be done.

Nice start but not a solution to our problem.

Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
displays the battery percentage.

With using generic-adc-battery driver and Marek's patch in kernel, this can easily be provided.

With exactly 0 bits of change in user space. Please note that you can't always tell users "upgrade to the latest user space".

So I have three questions:
a) why do you use float/double instead of fixed point for such simple and imprecise calculations?
b) what does it provide as additional information over some lines of code in generic-adc-battery driver?
c) how do yo make sure that this libbattery is included in all the battery monitors that are already in use and
is backported for example to the old plugin I mentioned above?

BR and thanks,
Nikolaus


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/e83b4fb5/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1.1: Type: text/plain, Size: 1615 bytes --]


> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> Hi!
> 
>>> Without patch description: See Last Question in
>>> 
>>> Documentation/power/power_supply_class.txt
>> 
>> ...should be done in libbattery, yet to be written. :-).
>> 
>> Do you have specific guidance what you'd like to see in libbattery?

IMHO there was no answer from maintainers. Or I have not received it.

> 
> So I started something, it is at.
> 
> https://github.com/pavelmachek/libbattery
> 
> My battery on n900 is currently uncalibrated (and charging), still it
> gets some kind of estimation:
> 
> Battery -1 %
> Seconds -1
> State 1
> Voltage 3.88 V
> Battery 63 %
> 
> Of course, there's a lot more work to be done.

Nice start but not a solution to our problem.

Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
displays the battery percentage.

With using generic-adc-battery driver and Marek's patch in kernel, this can easily be provided.

With exactly 0 bits of change in user space. Please note that you can't always tell users "upgrade to the latest user space".

So I have three questions:
a) why do you use float/double instead of fixed point for such simple and imprecise calculations?
b) what does it provide as additional information over some lines of code in generic-adc-battery driver?
c) how do yo make sure that this libbattery is included in all the battery monitors that are already in use and
is backported for example to the old plugin I mentioned above?

BR and thanks,
Nikolaus



[-- Attachment #1.2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]


> So I have three questions:
> a) why do you use float/double instead of fixed point for such
> simple and imprecise calculations?

Cleaner code, and probably faster, too.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

> So I have three questions:
> a) why do you use float/double instead of fixed point for such
> simple and imprecise calculations?

Cleaner code, and probably faster, too.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/691a6ed3/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > So I started something, it is at.
> > 
> > https://github.com/pavelmachek/libbattery
> > 
> > My battery on n900 is currently uncalibrated (and charging), still it
> > gets some kind of estimation:
> > 
> > Battery -1 %
> > Seconds -1
> > State 1
> > Voltage 3.88 V
> > Battery 63 %
> > 
> > Of course, there's a lot more work to be done.
> 
> Nice start but not a solution to our problem.
> 
> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> displays the battery percentage.

I think we could make things compatible with various battery apps by
having libbattery write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry. Then the kernel interface
can just display the data to whatever apps.

Regards,

Tony

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > So I started something, it is at.
> > 
> > https://github.com/pavelmachek/libbattery
> > 
> > My battery on n900 is currently uncalibrated (and charging), still it
> > gets some kind of estimation:
> > 
> > Battery -1 %
> > Seconds -1
> > State 1
> > Voltage 3.88 V
> > Battery 63 %
> > 
> > Of course, there's a lot more work to be done.
> 
> Nice start but not a solution to our problem.
> 
> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> displays the battery percentage.

I think we could make things compatible with various battery apps by
having libbattery write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry. Then the kernel interface
can just display the data to whatever apps.

Regards,

Tony

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > > 
> > > So I started something, it is at.
> > > 
> > > https://github.com/pavelmachek/libbattery
> > > 
> > > My battery on n900 is currently uncalibrated (and charging), still it
> > > gets some kind of estimation:
> > > 
> > > Battery -1 %
> > > Seconds -1
> > > State 1
> > > Voltage 3.88 V
> > > Battery 63 %
> > > 
> > > Of course, there's a lot more work to be done.
> > 
> > Nice start but not a solution to our problem.
> > 
> > Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> > displays the battery percentage.
> 
> I think we could make things compatible with various battery apps by
> having libbattery write back the capacity percentage and time remaining
> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> can just display the data to whatever apps.

Hmm. This could be as simple as providing symlink from
/sys/class/power/userland-battery to some place writable by
userspace...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > > Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > > 
> > > So I started something, it is at.
> > > 
> > > https://github.com/pavelmachek/libbattery
> > > 
> > > My battery on n900 is currently uncalibrated (and charging), still it
> > > gets some kind of estimation:
> > > 
> > > Battery -1 %
> > > Seconds -1
> > > State 1
> > > Voltage 3.88 V
> > > Battery 63 %
> > > 
> > > Of course, there's a lot more work to be done.
> > 
> > Nice start but not a solution to our problem.
> > 
> > Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> > displays the battery percentage.
> 
> I think we could make things compatible with various battery apps by
> having libbattery write back the capacity percentage and time remaining
> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> can just display the data to whatever apps.

Hmm. This could be as simple as providing symlink from
/sys/class/power/userland-battery to some place writable by
userspace...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/98eb36a1/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]


> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>> 
>>>> So I started something, it is at.
>>>> 
>>>> https://github.com/pavelmachek/libbattery
>>>> 
>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>> gets some kind of estimation:
>>>> 
>>>> Battery -1 %
>>>> Seconds -1
>>>> State 1
>>>> Voltage 3.88 V
>>>> Battery 63 %
>>>> 
>>>> Of course, there's a lot more work to be done.
>>> 
>>> Nice start but not a solution to our problem.
>>> 
>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>> displays the battery percentage.
>> 
>> I think we could make things compatible with various battery apps by
>> having libbattery write back the capacity percentage and time remaining
>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>> can just display the data to whatever apps.
> 
> Hmm. This could be as simple as providing symlink from
> /sys/class/power/userland-battery to some place writable by
> userspace...

Well, please implement arbitrary symlinks in /sysfs...

root@letux:~# ln -sf /tmp/somewhere /sys/class/power_supply/fake-battery
ln: failed to create symbolic link '/sys/class/power_supply/fake-battery': Operation not permitted
root@letux:~#

And you need to run a daemon so that the data is available
somewhere.

BR and thanks,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>> 
>>>> So I started something, it is at.
>>>> 
>>>> https://github.com/pavelmachek/libbattery
>>>> 
>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>> gets some kind of estimation:
>>>> 
>>>> Battery -1 %
>>>> Seconds -1
>>>> State 1
>>>> Voltage 3.88 V
>>>> Battery 63 %
>>>> 
>>>> Of course, there's a lot more work to be done.
>>> 
>>> Nice start but not a solution to our problem.
>>> 
>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>> displays the battery percentage.
>> 
>> I think we could make things compatible with various battery apps by
>> having libbattery write back the capacity percentage and time remaining
>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>> can just display the data to whatever apps.
> 
> Hmm. This could be as simple as providing symlink from
> /sys/class/power/userland-battery to some place writable by
> userspace...

Well, please implement arbitrary symlinks in /sysfs...

root at letux:~# ln -sf /tmp/somewhere /sys/class/power_supply/fake-battery
ln: failed to create symbolic link '/sys/class/power_supply/fake-battery': Operation not permitted
root at letux:~#

And you need to run a daemon so that the data is available
somewhere.

BR and thanks,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/ded7a77f/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
> 
> > Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> >> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>> 
> >>>> So I started something, it is at.
> >>>> 
> >>>> https://github.com/pavelmachek/libbattery
> >>>> 
> >>>> My battery on n900 is currently uncalibrated (and charging), still it
> >>>> gets some kind of estimation:
> >>>> 
> >>>> Battery -1 %
> >>>> Seconds -1
> >>>> State 1
> >>>> Voltage 3.88 V
> >>>> Battery 63 %
> >>>> 
> >>>> Of course, there's a lot more work to be done.
> >>> 
> >>> Nice start but not a solution to our problem.
> >>> 
> >>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >>> displays the battery percentage.
> >> 
> >> I think we could make things compatible with various battery apps by
> >> having libbattery write back the capacity percentage and time remaining
> >> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> >> can just display the data to whatever apps.
> > 
> > Hmm. This could be as simple as providing symlink from
> > /sys/class/power/userland-battery to some place writable by
> > userspace...
> 
> Well, please implement arbitrary symlinks in /sysfs...

Any reason why I'd like to do that?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Pavel Machek]

On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
> 
> > Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
> > 
> > On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
> >> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>> 
> >>>> So I started something, it is at.
> >>>> 
> >>>> https://github.com/pavelmachek/libbattery
> >>>> 
> >>>> My battery on n900 is currently uncalibrated (and charging), still it
> >>>> gets some kind of estimation:
> >>>> 
> >>>> Battery -1 %
> >>>> Seconds -1
> >>>> State 1
> >>>> Voltage 3.88 V
> >>>> Battery 63 %
> >>>> 
> >>>> Of course, there's a lot more work to be done.
> >>> 
> >>> Nice start but not a solution to our problem.
> >>> 
> >>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >>> displays the battery percentage.
> >> 
> >> I think we could make things compatible with various battery apps by
> >> having libbattery write back the capacity percentage and time remaining
> >> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> >> can just display the data to whatever apps.
> > 
> > Hmm. This could be as simple as providing symlink from
> > /sys/class/power/userland-battery to some place writable by
> > userspace...
> 
> Well, please implement arbitrary symlinks in /sysfs...

Any reason why I'd like to do that?
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/fb198e83/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]


> Am 18.10.2017 um 18:13 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>> 
>>>>>> So I started something, it is at.
>>>>>> 
>>>>>> https://github.com/pavelmachek/libbattery
>>>>>> 
>>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>>> gets some kind of estimation:
>>>>>> 
>>>>>> Battery -1 %
>>>>>> Seconds -1
>>>>>> State 1
>>>>>> Voltage 3.88 V
>>>>>> Battery 63 %
>>>>>> 
>>>>>> Of course, there's a lot more work to be done.
>>>>> 
>>>>> Nice start but not a solution to our problem.
>>>>> 
>>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>>> displays the battery percentage.
>>>> 
>>>> I think we could make things compatible with various battery apps by
>>>> having libbattery write back the capacity percentage and time remaining
>>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>>> can just display the data to whatever apps.
>>> 
>>> Hmm. This could be as simple as providing symlink from
>>> /sys/class/power/userland-battery to some place writable by
>>> userspace...
>> 
>> Well, please implement arbitrary symlinks in /sysfs...
> 
> Any reason why I'd like to do that?

I don't know if you like it or not.

But it appears to be a strict necessity to make your proposal of
"as simple as providing symlink from /sys/class/power/userland-battery
to some place writable by userspace" work.

So if a different solution to provide /sys/class/power/*-battery
is possible, it should probably be preferred and nobody will ask
you to do something you don't like.

BR,
Nikolaus


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 18:13 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> On Wed 2017-10-18 17:52:22, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.10.2017 um 15:56 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> On Wed 2017-10-18 06:22:04, Tony Lindgren wrote:
>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>> 
>>>>>> So I started something, it is at.
>>>>>> 
>>>>>> https://github.com/pavelmachek/libbattery
>>>>>> 
>>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>>> gets some kind of estimation:
>>>>>> 
>>>>>> Battery -1 %
>>>>>> Seconds -1
>>>>>> State 1
>>>>>> Voltage 3.88 V
>>>>>> Battery 63 %
>>>>>> 
>>>>>> Of course, there's a lot more work to be done.
>>>>> 
>>>>> Nice start but not a solution to our problem.
>>>>> 
>>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>>> displays the battery percentage.
>>>> 
>>>> I think we could make things compatible with various battery apps by
>>>> having libbattery write back the capacity percentage and time remaining
>>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>>> can just display the data to whatever apps.
>>> 
>>> Hmm. This could be as simple as providing symlink from
>>> /sys/class/power/userland-battery to some place writable by
>>> userspace...
>> 
>> Well, please implement arbitrary symlinks in /sysfs...
> 
> Any reason why I'd like to do that?

I don't know if you like it or not.

But it appears to be a strict necessity to make your proposal of
"as simple as providing symlink from /sys/class/power/userland-battery
to some place writable by userspace" work.

So if a different solution to provide /sys/class/power/*-battery
is possible, it should probably be preferred and nobody will ask
you to do something you don't like.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171018/b7bb8503/attachment.sig>

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> So I started something, it is at.
>>> 
>>> https://github.com/pavelmachek/libbattery
>>> 
>>> My battery on n900 is currently uncalibrated (and charging), still it
>>> gets some kind of estimation:
>>> 
>>> Battery -1 %
>>> Seconds -1
>>> State 1
>>> Voltage 3.88 V
>>> Battery 63 %
>>> 
>>> Of course, there's a lot more work to be done.
>> 
>> Nice start but not a solution to our problem.
>> 
>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>> displays the battery percentage.
> 
> I think we could make things compatible with various battery apps by
> having libbattery write back the capacity percentage and time remaining
> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> can just display the data to whatever apps.

Hm. That would be quite difficult to understand and maintain code.
Why not have the kernel driver do the simple calculations (they do
not need float) and provide the standard /sys/class/power attribute?

BR,
Nikolaus

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> So I started something, it is at.
>>> 
>>> https://github.com/pavelmachek/libbattery
>>> 
>>> My battery on n900 is currently uncalibrated (and charging), still it
>>> gets some kind of estimation:
>>> 
>>> Battery -1 %
>>> Seconds -1
>>> State 1
>>> Voltage 3.88 V
>>> Battery 63 %
>>> 
>>> Of course, there's a lot more work to be done.
>> 
>> Nice start but not a solution to our problem.
>> 
>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>> displays the battery percentage.
> 
> I think we could make things compatible with various battery apps by
> having libbattery write back the capacity percentage and time remaining
> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> can just display the data to whatever apps.

Hm. That would be quite difficult to understand and maintain code.
Why not have the kernel driver do the simple calculations (they do
not need float) and provide the standard /sys/class/power attribute?

BR,
Nikolaus

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>> 
>>> So I started something, it is at.
>>> 
>>> https://github.com/pavelmachek/libbattery
>>> 
>>> My battery on n900 is currently uncalibrated (and charging), still it
>>> gets some kind of estimation:
>>> 
>>> Battery -1 %
>>> Seconds -1
>>> State 1
>>> Voltage 3.88 V
>>> Battery 63 %
>>> 
>>> Of course, there's a lot more work to be done.
>> 
>> Nice start but not a solution to our problem.
>> 
>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>> displays the battery percentage.
> 
> I think we could make things compatible with various battery apps by
> having libbattery write back the capacity percentage and time remaining
> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> can just display the data to whatever apps.

Hm. That would be quite difficult to understand and maintain code.
Why not have the kernel driver do the simple calculations (they do
not need float) and provide the standard /sys/class/power attribute?

BR,
Nikolaus

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> 
> > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>> 
> >>> So I started something, it is at.
> >>> 
> >>> https://github.com/pavelmachek/libbattery
> >>> 
> >>> My battery on n900 is currently uncalibrated (and charging), still it
> >>> gets some kind of estimation:
> >>> 
> >>> Battery -1 %
> >>> Seconds -1
> >>> State 1
> >>> Voltage 3.88 V
> >>> Battery 63 %
> >>> 
> >>> Of course, there's a lot more work to be done.
> >> 
> >> Nice start but not a solution to our problem.
> >> 
> >> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >> displays the battery percentage.
> > 
> > I think we could make things compatible with various battery apps by
> > having libbattery write back the capacity percentage and time remaining
> > to the kernel driver via sysfs or a dev entry. Then the kernel interface
> > can just display the data to whatever apps.
> 
> Hm. That would be quite difficult to understand and maintain code.

How so? The libbattery can do it all, then the kernel drivers needing
that will just display the most recent values to maintain compability
with battery apps.

> Why not have the kernel driver do the simple calculations (they do
> not need float) and provide the standard /sys/class/power attribute?

Because the current remaining capacity and battery empty state depend
on maintaining a database of previous history for battery wear. This
data needs to be preserved across reboots, so most likely on a file
on a disk is the way to go.

There's a nice summary what all is involved here:

http://www.mpoweruk.com/soc.htm

Regards,

Tony

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> 
> > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>> 
> >>> So I started something, it is at.
> >>> 
> >>> https://github.com/pavelmachek/libbattery
> >>> 
> >>> My battery on n900 is currently uncalibrated (and charging), still it
> >>> gets some kind of estimation:
> >>> 
> >>> Battery -1 %
> >>> Seconds -1
> >>> State 1
> >>> Voltage 3.88 V
> >>> Battery 63 %
> >>> 
> >>> Of course, there's a lot more work to be done.
> >> 
> >> Nice start but not a solution to our problem.
> >> 
> >> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >> displays the battery percentage.
> > 
> > I think we could make things compatible with various battery apps by
> > having libbattery write back the capacity percentage and time remaining
> > to the kernel driver via sysfs or a dev entry. Then the kernel interface
> > can just display the data to whatever apps.
> 
> Hm. That would be quite difficult to understand and maintain code.

How so? The libbattery can do it all, then the kernel drivers needing
that will just display the most recent values to maintain compability
with battery apps.

> Why not have the kernel driver do the simple calculations (they do
> not need float) and provide the standard /sys/class/power attribute?

Because the current remaining capacity and battery empty state depend
on maintaining a database of previous history for battery wear. This
data needs to be preserved across reboots, so most likely on a file
on a disk is the way to go.

There's a nice summary what all is involved here:

http://www.mpoweruk.com/soc.htm

Regards,

Tony

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

Hi Tony,

> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>> 
>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>> 
>>>>> So I started something, it is at.
>>>>> 
>>>>> https://github.com/pavelmachek/libbattery
>>>>> 
>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>> gets some kind of estimation:
>>>>> 
>>>>> Battery -1 %
>>>>> Seconds -1
>>>>> State 1
>>>>> Voltage 3.88 V
>>>>> Battery 63 %
>>>>> 
>>>>> Of course, there's a lot more work to be done.
>>>> 
>>>> Nice start but not a solution to our problem.
>>>> 
>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>> displays the battery percentage.
>>> 
>>> I think we could make things compatible with various battery apps by
>>> having libbattery write back the capacity percentage and time remaining
>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>> can just display the data to whatever apps.
>> 
>> Hm. That would be quite difficult to understand and maintain code.
> 
> How so? The libbattery can do it all, then the kernel drivers needing
> that will just display the most recent values to maintain compability
> with battery apps.

Well, it looks as if you are thinking about a much more complex solution
than I am...

The proposal we are discussing as

[RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

just reads the current voltage, charging current and uses a (nonlinear)
mapping to 0% .. 100%.

For that we don't need a library, and we don't need a mechanism to

"write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry.

> 
>> Why not have the kernel driver do the simple calculations (they do
>> not need float) and provide the standard /sys/class/power attribute?
> 
> Because the current remaining capacity and battery empty state depend
> on maintaining a database of previous history for battery wear.

For remaining capacity I agree that you need that. But this RFC doesn't
even want to provide remaining capacity. To avoid such issues. Just
provide POWER_SUPPLY_PROP_CAPACITY:

https://lkml.org/lkml/2017/8/1/910

So we are discussing to replace these 10 lines with a library, a
daemon and a mechanism that the driver can read that from user space?

IMHO this can be added in a further step, but shouldn't be backpacked
onto this here.

> This
> data needs to be preserved across reboots, so most likely on a file
> on a disk is the way to go.

It could also be stored in some i2c eeprom (DT could provide a reference).

> 
> There's a nice summary what all is involved here:
> 
> http://www.mpoweruk.com/soc.htm

Oh yes, that is really nice!

Using their terms, we just want to add "Voltage Based SOC Estimation"
for typical "Lithium chemistry".

BTW: this already exists in the twl4030-madc-battery driver and we use it
for the GTA04 derivatives without fuel gauge:

http://elixir.free-electrons.com/linux/v3.17/source/drivers/power/twl4030_madc_battery.c

It uses a table driven approach which was rejected to be converted to DT
some time ago. DT maintainers asked to use an estimation formula instead
of a table and interpolation.

And this patch set does not want to solve all problems in one step :)

But it wants to:
* make it useable for any battery voltage providing iio adc and not only twl4030
  by modifying the generic-adc-battery driver
* make the driver device tree compatible (twl4030-madc-battery still isn't)
* replace table by fixed point estimation formula fuel_level_LiIon(() as requested

Not more.

Of course a libbattery can do a lot of additional calculations to predict
e.g. time to emtpy or full charge, estimate battery health etc. and provide
more precision by filters.

We would be very happy to have a simple estimation because it already
covers most use cases (some early smartphones had only 4 levels for SOC).
And we want to replace the pdata based driver with a DT driver asap.

BR and thanks,
Nikolaus

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

Hi Tony,

> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>> 
>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>> 
>>>>> So I started something, it is at.
>>>>> 
>>>>> https://github.com/pavelmachek/libbattery
>>>>> 
>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>> gets some kind of estimation:
>>>>> 
>>>>> Battery -1 %
>>>>> Seconds -1
>>>>> State 1
>>>>> Voltage 3.88 V
>>>>> Battery 63 %
>>>>> 
>>>>> Of course, there's a lot more work to be done.
>>>> 
>>>> Nice start but not a solution to our problem.
>>>> 
>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>> displays the battery percentage.
>>> 
>>> I think we could make things compatible with various battery apps by
>>> having libbattery write back the capacity percentage and time remaining
>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>> can just display the data to whatever apps.
>> 
>> Hm. That would be quite difficult to understand and maintain code.
> 
> How so? The libbattery can do it all, then the kernel drivers needing
> that will just display the most recent values to maintain compability
> with battery apps.

Well, it looks as if you are thinking about a much more complex solution
than I am...

The proposal we are discussing as

[RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

just reads the current voltage, charging current and uses a (nonlinear)
mapping to 0% .. 100%.

For that we don't need a library, and we don't need a mechanism to

"write back the capacity percentage and time remaining
to the kernel driver via sysfs or a dev entry.

> 
>> Why not have the kernel driver do the simple calculations (they do
>> not need float) and provide the standard /sys/class/power attribute?
> 
> Because the current remaining capacity and battery empty state depend
> on maintaining a database of previous history for battery wear.

For remaining capacity I agree that you need that. But this RFC doesn't
even want to provide remaining capacity. To avoid such issues. Just
provide POWER_SUPPLY_PROP_CAPACITY:

https://lkml.org/lkml/2017/8/1/910

So we are discussing to replace these 10 lines with a library, a
daemon and a mechanism that the driver can read that from user space?

IMHO this can be added in a further step, but shouldn't be backpacked
onto this here.

> This
> data needs to be preserved across reboots, so most likely on a file
> on a disk is the way to go.

It could also be stored in some i2c eeprom (DT could provide a reference).

> 
> There's a nice summary what all is involved here:
> 
> http://www.mpoweruk.com/soc.htm

Oh yes, that is really nice!

Using their terms, we just want to add "Voltage Based SOC Estimation"
for typical "Lithium chemistry".

BTW: this already exists in the twl4030-madc-battery driver and we use it
for the GTA04 derivatives without fuel gauge:

http://elixir.free-electrons.com/linux/v3.17/source/drivers/power/twl4030_madc_battery.c

It uses a table driven approach which was rejected to be converted to DT
some time ago. DT maintainers asked to use an estimation formula instead
of a table and interpolation.

And this patch set does not want to solve all problems in one step :)

But it wants to:
* make it useable for any battery voltage providing iio adc and not only twl4030
  by modifying the generic-adc-battery driver
* make the driver device tree compatible (twl4030-madc-battery still isn't)
* replace table by fixed point estimation formula fuel_level_LiIon(() as requested

Not more.

Of course a libbattery can do a lot of additional calculations to predict
e.g. time to emtpy or full charge, estimate battery health etc. and provide
more precision by filters.

We would be very happy to have a simple estimation because it already
covers most use cases (some early smartphones had only 4 levels for SOC).
And we want to replace the pdata based driver with a DT driver asap.

BR and thanks,
Nikolaus

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
> Hi Tony,
> 
> > Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> >> 
> >>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> >>> 
> >>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>>> 
> >>>>> So I started something, it is at.
> >>>>> 
> >>>>> https://github.com/pavelmachek/libbattery
> >>>>> 
> >>>>> My battery on n900 is currently uncalibrated (and charging), still it
> >>>>> gets some kind of estimation:
> >>>>> 
> >>>>> Battery -1 %
> >>>>> Seconds -1
> >>>>> State 1
> >>>>> Voltage 3.88 V
> >>>>> Battery 63 %
> >>>>> 
> >>>>> Of course, there's a lot more work to be done.
> >>>> 
> >>>> Nice start but not a solution to our problem.
> >>>> 
> >>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >>>> displays the battery percentage.
> >>> 
> >>> I think we could make things compatible with various battery apps by
> >>> having libbattery write back the capacity percentage and time remaining
> >>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> >>> can just display the data to whatever apps.
> >> 
> >> Hm. That would be quite difficult to understand and maintain code.
> > 
> > How so? The libbattery can do it all, then the kernel drivers needing
> > that will just display the most recent values to maintain compability
> > with battery apps.
> 
> Well, it looks as if you are thinking about a much more complex solution
> than I am...
> 
> The proposal we are discussing as
> 
> [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling
> 
> just reads the current voltage, charging current and uses a (nonlinear)
> mapping to 0% .. 100%.

Right, I was discussing Pavel's libbattery link posted above. No
comments on the current patch series. Let's move the libbattery stuff
to a new thread to avoid confusion.

Regards,

Tony

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
> Hi Tony,
> 
> > Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> >> 
> >>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> >>> 
> >>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> >>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> >>>>> 
> >>>>> So I started something, it is at.
> >>>>> 
> >>>>> https://github.com/pavelmachek/libbattery
> >>>>> 
> >>>>> My battery on n900 is currently uncalibrated (and charging), still it
> >>>>> gets some kind of estimation:
> >>>>> 
> >>>>> Battery -1 %
> >>>>> Seconds -1
> >>>>> State 1
> >>>>> Voltage 3.88 V
> >>>>> Battery 63 %
> >>>>> 
> >>>>> Of course, there's a lot more work to be done.
> >>>> 
> >>>> Nice start but not a solution to our problem.
> >>>> 
> >>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> >>>> displays the battery percentage.
> >>> 
> >>> I think we could make things compatible with various battery apps by
> >>> having libbattery write back the capacity percentage and time remaining
> >>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
> >>> can just display the data to whatever apps.
> >> 
> >> Hm. That would be quite difficult to understand and maintain code.
> > 
> > How so? The libbattery can do it all, then the kernel drivers needing
> > that will just display the most recent values to maintain compability
> > with battery apps.
> 
> Well, it looks as if you are thinking about a much more complex solution
> than I am...
> 
> The proposal we are discussing as
> 
> [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling
> 
> just reads the current voltage, charging current and uses a (nonlinear)
> mapping to 0% .. 100%.

Right, I was discussing Pavel's libbattery link posted above. No
comments on the current patch series. Let's move the libbattery stuff
to a new thread to avoid confusion.

Regards,

Tony

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 19.10.2017 um 19:06 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
>> Hi Tony,
>> 
>>> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>>>> 
>>>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>>>> 
>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>>> 
>>>>>>> So I started something, it is at.
>>>>>>> 
>>>>>>> https://github.com/pavelmachek/libbattery
>>>>>>> 
>>>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>>>> gets some kind of estimation:
>>>>>>> 
>>>>>>> Battery -1 %
>>>>>>> Seconds -1
>>>>>>> State 1
>>>>>>> Voltage 3.88 V
>>>>>>> Battery 63 %
>>>>>>> 
>>>>>>> Of course, there's a lot more work to be done.
>>>>>> 
>>>>>> Nice start but not a solution to our problem.
>>>>>> 
>>>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>>>> displays the battery percentage.
>>>>> 
>>>>> I think we could make things compatible with various battery apps by
>>>>> having libbattery write back the capacity percentage and time remaining
>>>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>>>> can just display the data to whatever apps.
>>>> 
>>>> Hm. That would be quite difficult to understand and maintain code.
>>> 
>>> How so? The libbattery can do it all, then the kernel drivers needing
>>> that will just display the most recent values to maintain compability
>>> with battery apps.
>> 
>> Well, it looks as if you are thinking about a much more complex solution
>> than I am...
>> 
>> The proposal we are discussing as
>> 
>> [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling
>> 
>> just reads the current voltage, charging current and uses a (nonlinear)
>> mapping to 0% .. 100%.
> 
> Right, I was discussing Pavel's libbattery link posted above. No
> comments on the current patch series.

Well, it was triggered by Sebastian's comment on this patch that 
some 10 years old Documentation recommends to write a libbattery.

And there is still some (weak) relation between the subject and libbattery.

> Let's move the libbattery stuff
> to a new thread to avoid confusion.

Agreed.

BR,
Nikolaus

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[H. Nikolaus Schaller]

> Am 19.10.2017 um 19:06 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [171019 09:57]:
>> Hi Tony,
>> 
>>> Am 19.10.2017 um 18:24 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
>>>> 
>>>>> Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
>>>>> 
>>>>> * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
>>>>>>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
>>>>>>> 
>>>>>>> So I started something, it is at.
>>>>>>> 
>>>>>>> https://github.com/pavelmachek/libbattery
>>>>>>> 
>>>>>>> My battery on n900 is currently uncalibrated (and charging), still it
>>>>>>> gets some kind of estimation:
>>>>>>> 
>>>>>>> Battery -1 %
>>>>>>> Seconds -1
>>>>>>> State 1
>>>>>>> Voltage 3.88 V
>>>>>>> Battery 63 %
>>>>>>> 
>>>>>>> Of course, there's a lot more work to be done.
>>>>>> 
>>>>>> Nice start but not a solution to our problem.
>>>>>> 
>>>>>> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
>>>>>> displays the battery percentage.
>>>>> 
>>>>> I think we could make things compatible with various battery apps by
>>>>> having libbattery write back the capacity percentage and time remaining
>>>>> to the kernel driver via sysfs or a dev entry. Then the kernel interface
>>>>> can just display the data to whatever apps.
>>>> 
>>>> Hm. That would be quite difficult to understand and maintain code.
>>> 
>>> How so? The libbattery can do it all, then the kernel drivers needing
>>> that will just display the most recent values to maintain compability
>>> with battery apps.
>> 
>> Well, it looks as if you are thinking about a much more complex solution
>> than I am...
>> 
>> The proposal we are discussing as
>> 
>> [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling
>> 
>> just reads the current voltage, charging current and uses a (nonlinear)
>> mapping to 0% .. 100%.
> 
> Right, I was discussing Pavel's libbattery link posted above. No
> comments on the current patch series.

Well, it was triggered by Sebastian's comment on this patch that 
some 10 years old Documentation recommends to write a libbattery.

And there is still some (weak) relation between the subject and libbattery.

> Let's move the libbattery stuff
> to a new thread to avoid confusion.

Agreed.

BR,
Nikolaus

Re: libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Ladislav Michl]

On Thu, Oct 19, 2017 at 09:24:16AM -0700, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> > 
> > > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > > 
> > > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > >>> 
> > >>> So I started something, it is at.
> > >>> 
> > >>> https://github.com/pavelmachek/libbattery
> > >>> 
> > >>> My battery on n900 is currently uncalibrated (and charging), still it
> > >>> gets some kind of estimation:
> > >>> 
> > >>> Battery -1 %
> > >>> Seconds -1
> > >>> State 1
> > >>> Voltage 3.88 V
> > >>> Battery 63 %
> > >>> 
> > >>> Of course, there's a lot more work to be done.
> > >> 
> > >> Nice start but not a solution to our problem.
> > >> 
> > >> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> > >> displays the battery percentage.
> > > 
> > > I think we could make things compatible with various battery apps by
> > > having libbattery write back the capacity percentage and time remaining
> > > to the kernel driver via sysfs or a dev entry. Then the kernel interface
> > > can just display the data to whatever apps.
> > 
> > Hm. That would be quite difficult to understand and maintain code.
> 
> How so? The libbattery can do it all, then the kernel drivers needing
> that will just display the most recent values to maintain compability
> with battery apps.
> 
> > Why not have the kernel driver do the simple calculations (they do
> > not need float) and provide the standard /sys/class/power attribute?
> 
> Because the current remaining capacity and battery empty state depend
> on maintaining a database of previous history for battery wear. This
> data needs to be preserved across reboots, so most likely on a file
> on a disk is the way to go.

Well, a lot of gas gauches have registers to store that kind of information.
Just noone uses them and that's another part of story.
This one I'm using for such purposes, but as I didn't figure out what is
standard way of dealing wich such kind of information, I'm lock with
this solution for now.

Subject: [PATCH] power: supply: ltc2941-battery-gauge: charge empty and full

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 drivers/power/supply/ltc2941-battery-gauge.c | 59 +++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/ltc2941-battery-gauge.c b/drivers/power/supply/ltc2941-battery-gauge.c
index 08e4fd9ee607..523373ea9cbd 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -34,6 +34,10 @@ enum ltc294x_reg {
 	LTC294X_REG_CONTROL		= 0x01,
 	LTC294X_REG_ACC_CHARGE_MSB	= 0x02,
 	LTC294X_REG_ACC_CHARGE_LSB	= 0x03,
+	LTC294X_REG_CHARGE_THR_HIGH_MSB	= 0x04,
+	LTC294X_REG_CHARGE_THR_HIGH_LSB	= 0x05,
+	LTC294X_REG_CHARGE_THR_LOW_MSB	= 0x06,
+	LTC294X_REG_CHARGE_THR_LOW_LSB	= 0x07,
 	LTC294X_REG_VOLTAGE_MSB		= 0x08,
 	LTC294X_REG_VOLTAGE_LSB		= 0x09,
 	LTC2942_REG_TEMPERATURE_MSB	= 0x0C,
@@ -178,21 +182,22 @@ static int ltc294x_reset(const struct ltc294x_info *info, int prescaler_exp)
 	return ret;
 }
 
-static int ltc294x_read_charge_register(const struct ltc294x_info *info)
-{
+static int ltc294x_read_charge_register(const struct ltc294x_info *info,
+					enum ltc294x_reg reg)
+ {
 	int ret;
 	u8 datar[2];
 
-	ret = ltc294x_read_regs(info->client,
-		LTC294X_REG_ACC_CHARGE_MSB, &datar[0], 2);
+	ret = ltc294x_read_regs(info->client, reg, &datar[0], 2);
 	if (ret < 0)
 		return ret;
 	return (datar[0] << 8) + datar[1];
 }
 
-static int ltc294x_get_charge_now(const struct ltc294x_info *info, int *val)
+static int ltc294x_get_charge(const struct ltc294x_info *info,
+				enum ltc294x_reg reg, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, reg);
 
 	if (value < 0)
 		return value;
@@ -244,10 +249,29 @@ static int ltc294x_set_charge_now(const struct ltc294x_info *info, int val)
 	return ret < 0 ? ret : 0;
 }
 
+static int ltc294x_set_charge_thr(const struct ltc294x_info *info,
+					enum ltc294x_reg reg, int val)
+{
+	u8 dataw[2];
+	s32 value;
+
+	value = convert_uAh_to_bin(info, val);
+	/* Direction depends on how sense+/- were connected */
+	if (info->Qlsb < 0)
+		value += 0xFFFF;
+	if ((value < 0) || (value > 0xFFFF)) /* input validation */
+		return -EINVAL;
+
+	/* Set new charge value */
+	dataw[0] = I16_MSB(value);
+	dataw[1] = I16_LSB(value);
+	return ltc294x_write_regs(info->client, reg, &dataw[0], 2);
+}
+
 static int ltc294x_get_charge_counter(
 	const struct ltc294x_info *info, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (value < 0)
 		return value;
@@ -335,8 +359,15 @@ static int ltc294x_get_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (prop) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_HIGH_MSB,
+						&val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_LOW_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
-		return ltc294x_get_charge_now(info, &val->intval);
+		return ltc294x_get_charge(info, LTC294X_REG_ACC_CHARGE_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_COUNTER:
 		return ltc294x_get_charge_counter(info, &val->intval);
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -357,6 +388,12 @@ static int ltc294x_set_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_HIGH_MSB, val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_LOW_MSB, val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return ltc294x_set_charge_now(info, val->intval);
 	default:
@@ -368,6 +405,8 @@ static int ltc294x_property_is_writeable(
 	struct power_supply *psy, enum power_supply_property psp)
 {
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return 1;
 	default:
@@ -377,7 +416,7 @@ static int ltc294x_property_is_writeable(
 
 static void ltc294x_update(struct ltc294x_info *info)
 {
-	int charge = ltc294x_read_charge_register(info);
+	int charge = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (charge != info->charge) {
 		info->charge = charge;
@@ -396,6 +435,8 @@ static void ltc294x_work(struct work_struct *work)
 
 static enum power_supply_property ltc294x_properties[] = {
 	POWER_SUPPLY_PROP_CHARGE_COUNTER,
+	POWER_SUPPLY_PROP_CHARGE_FULL,
+	POWER_SUPPLY_PROP_CHARGE_EMPTY,
 	POWER_SUPPLY_PROP_CHARGE_NOW,
 	POWER_SUPPLY_PROP_VOLTAGE_NOW,
 	POWER_SUPPLY_PROP_TEMP,
-- 
2.11.0

> There's a nice summary what all is involved here:
> 
> http://www.mpoweruk.com/soc.htm
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

libbattery was Re: [RFC PATCH 5/5] power: generic-adc-battery: Add capacity handling

[Ladislav Michl]

On Thu, Oct 19, 2017 at 09:24:16AM -0700, Tony Lindgren wrote:
> * H. Nikolaus Schaller <hns@goldelico.com> [171018 08:49]:
> > 
> > > Am 18.10.2017 um 15:22 schrieb Tony Lindgren <tony@atomide.com>:
> > > 
> > > * H. Nikolaus Schaller <hns@goldelico.com> [171018 05:49]:
> > >>> Am 18.10.2017 um 14:28 schrieb Pavel Machek <pavel@ucw.cz>:
> > >>> 
> > >>> So I started something, it is at.
> > >>> 
> > >>> https://github.com/pavelmachek/libbattery
> > >>> 
> > >>> My battery on n900 is currently uncalibrated (and charging), still it
> > >>> gets some kind of estimation:
> > >>> 
> > >>> Battery -1 %
> > >>> Seconds -1
> > >>> State 1
> > >>> Voltage 3.88 V
> > >>> Battery 63 %
> > >>> 
> > >>> Of course, there's a lot more work to be done.
> > >> 
> > >> Nice start but not a solution to our problem.
> > >> 
> > >> Our problem is that people simply expect that for example https://packages.debian.org/wheezy/xfce/xfce4-battery-plugin
> > >> displays the battery percentage.
> > > 
> > > I think we could make things compatible with various battery apps by
> > > having libbattery write back the capacity percentage and time remaining
> > > to the kernel driver via sysfs or a dev entry. Then the kernel interface
> > > can just display the data to whatever apps.
> > 
> > Hm. That would be quite difficult to understand and maintain code.
> 
> How so? The libbattery can do it all, then the kernel drivers needing
> that will just display the most recent values to maintain compability
> with battery apps.
> 
> > Why not have the kernel driver do the simple calculations (they do
> > not need float) and provide the standard /sys/class/power attribute?
> 
> Because the current remaining capacity and battery empty state depend
> on maintaining a database of previous history for battery wear. This
> data needs to be preserved across reboots, so most likely on a file
> on a disk is the way to go.

Well, a lot of gas gauches have registers to store that kind of information.
Just noone uses them and that's another part of story.
This one I'm using for such purposes, but as I didn't figure out what is
standard way of dealing wich such kind of information, I'm lock with
this solution for now.

Subject: [PATCH] power: supply: ltc2941-battery-gauge: charge empty and full

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 drivers/power/supply/ltc2941-battery-gauge.c | 59 +++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/ltc2941-battery-gauge.c b/drivers/power/supply/ltc2941-battery-gauge.c
index 08e4fd9ee607..523373ea9cbd 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -34,6 +34,10 @@ enum ltc294x_reg {
 	LTC294X_REG_CONTROL		= 0x01,
 	LTC294X_REG_ACC_CHARGE_MSB	= 0x02,
 	LTC294X_REG_ACC_CHARGE_LSB	= 0x03,
+	LTC294X_REG_CHARGE_THR_HIGH_MSB	= 0x04,
+	LTC294X_REG_CHARGE_THR_HIGH_LSB	= 0x05,
+	LTC294X_REG_CHARGE_THR_LOW_MSB	= 0x06,
+	LTC294X_REG_CHARGE_THR_LOW_LSB	= 0x07,
 	LTC294X_REG_VOLTAGE_MSB		= 0x08,
 	LTC294X_REG_VOLTAGE_LSB		= 0x09,
 	LTC2942_REG_TEMPERATURE_MSB	= 0x0C,
@@ -178,21 +182,22 @@ static int ltc294x_reset(const struct ltc294x_info *info, int prescaler_exp)
 	return ret;
 }
 
-static int ltc294x_read_charge_register(const struct ltc294x_info *info)
-{
+static int ltc294x_read_charge_register(const struct ltc294x_info *info,
+					enum ltc294x_reg reg)
+ {
 	int ret;
 	u8 datar[2];
 
-	ret = ltc294x_read_regs(info->client,
-		LTC294X_REG_ACC_CHARGE_MSB, &datar[0], 2);
+	ret = ltc294x_read_regs(info->client, reg, &datar[0], 2);
 	if (ret < 0)
 		return ret;
 	return (datar[0] << 8) + datar[1];
 }
 
-static int ltc294x_get_charge_now(const struct ltc294x_info *info, int *val)
+static int ltc294x_get_charge(const struct ltc294x_info *info,
+				enum ltc294x_reg reg, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, reg);
 
 	if (value < 0)
 		return value;
@@ -244,10 +249,29 @@ static int ltc294x_set_charge_now(const struct ltc294x_info *info, int val)
 	return ret < 0 ? ret : 0;
 }
 
+static int ltc294x_set_charge_thr(const struct ltc294x_info *info,
+					enum ltc294x_reg reg, int val)
+{
+	u8 dataw[2];
+	s32 value;
+
+	value = convert_uAh_to_bin(info, val);
+	/* Direction depends on how sense+/- were connected */
+	if (info->Qlsb < 0)
+		value += 0xFFFF;
+	if ((value < 0) || (value > 0xFFFF)) /* input validation */
+		return -EINVAL;
+
+	/* Set new charge value */
+	dataw[0] = I16_MSB(value);
+	dataw[1] = I16_LSB(value);
+	return ltc294x_write_regs(info->client, reg, &dataw[0], 2);
+}
+
 static int ltc294x_get_charge_counter(
 	const struct ltc294x_info *info, int *val)
 {
-	int value = ltc294x_read_charge_register(info);
+	int value = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (value < 0)
 		return value;
@@ -335,8 +359,15 @@ static int ltc294x_get_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (prop) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_HIGH_MSB,
+						&val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_get_charge(info, LTC294X_REG_CHARGE_THR_LOW_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
-		return ltc294x_get_charge_now(info, &val->intval);
+		return ltc294x_get_charge(info, LTC294X_REG_ACC_CHARGE_MSB,
+						&val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_COUNTER:
 		return ltc294x_get_charge_counter(info, &val->intval);
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
@@ -357,6 +388,12 @@ static int ltc294x_set_property(struct power_supply *psy,
 	struct ltc294x_info *info = power_supply_get_drvdata(psy);
 
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_HIGH_MSB, val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
+		return ltc294x_set_charge_thr(info,
+			LTC294X_REG_CHARGE_THR_LOW_MSB, val->intval);
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return ltc294x_set_charge_now(info, val->intval);
 	default:
@@ -368,6 +405,8 @@ static int ltc294x_property_is_writeable(
 	struct power_supply *psy, enum power_supply_property psp)
 {
 	switch (psp) {
+	case POWER_SUPPLY_PROP_CHARGE_FULL:
+	case POWER_SUPPLY_PROP_CHARGE_EMPTY:
 	case POWER_SUPPLY_PROP_CHARGE_NOW:
 		return 1;
 	default:
@@ -377,7 +416,7 @@ static int ltc294x_property_is_writeable(
 
 static void ltc294x_update(struct ltc294x_info *info)
 {
-	int charge = ltc294x_read_charge_register(info);
+	int charge = ltc294x_read_charge_register(info, LTC294X_REG_ACC_CHARGE_MSB);
 
 	if (charge != info->charge) {
 		info->charge = charge;
@@ -396,6 +435,8 @@ static void ltc294x_work(struct work_struct *work)
 
 static enum power_supply_property ltc294x_properties[] = {
 	POWER_SUPPLY_PROP_CHARGE_COUNTER,
+	POWER_SUPPLY_PROP_CHARGE_FULL,
+	POWER_SUPPLY_PROP_CHARGE_EMPTY,
 	POWER_SUPPLY_PROP_CHARGE_NOW,
 	POWER_SUPPLY_PROP_VOLTAGE_NOW,
 	POWER_SUPPLY_PROP_TEMP,
-- 
2.11.0

> There's a nice summary what all is involved here:
> 
> http://www.mpoweruk.com/soc.htm
> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html