[PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[Marek Belisko]

This patches adding support for twl4030_madc_battery to use twl4030_madc iio framework + DT support.
Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
first patch to iio consumer and in next patches is added support for devicetree
+ some small fixes for module autoloading.

Changes from V2:
- fix property names
- add MODULE_DEVICE_TABLE and MODULE_ALIAS

Changes from V1:
- use iio_read_channel_processed instead iio_read_channel_processed
- convert probe to use devm_ as part of adding error handling for iio
- free iio channels on error and on module removal

[1] - https://lkml.org/lkml/2014/2/26/482dd

Marek Belisko (6):
  power: twl4030-madc-battery: Convert to iio consumer.
  power: twl4030_madc_battery: Add device tree support
  Documentation: DT: Document twl4030-madc-battery bindings
  ARM: dts: omap3-gta04: Add battery support
  power: twl4030_madc_battery: Add of_twl4030_madc_match to
    MODULE_DEVICE_TABLE
  power: twl4030_madc_battery: Add missing MODULE_ALIAS

 .../bindings/power_supply/twl4030_madc_battery.txt |  43 +++++
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  30 ++++
 drivers/power/twl4030_madc_battery.c               | 183 +++++++++++++++++----
 3 files changed, 221 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

-- 
1.9.1

[PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[Marek Belisko]

This patches adding support for twl4030_madc_battery to use twl4030_madc iio framework + DT support.
Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
first patch to iio consumer and in next patches is added support for devicetree
+ some small fixes for module autoloading.

Changes from V2:
- fix property names
- add MODULE_DEVICE_TABLE and MODULE_ALIAS

Changes from V1:
- use iio_read_channel_processed instead iio_read_channel_processed
- convert probe to use devm_ as part of adding error handling for iio
- free iio channels on error and on module removal

[1] - https://lkml.org/lkml/2014/2/26/482dd

Marek Belisko (6):
  power: twl4030-madc-battery: Convert to iio consumer.
  power: twl4030_madc_battery: Add device tree support
  Documentation: DT: Document twl4030-madc-battery bindings
  ARM: dts: omap3-gta04: Add battery support
  power: twl4030_madc_battery: Add of_twl4030_madc_match to
    MODULE_DEVICE_TABLE
  power: twl4030_madc_battery: Add missing MODULE_ALIAS

 .../bindings/power_supply/twl4030_madc_battery.txt |  43 +++++
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  30 ++++
 drivers/power/twl4030_madc_battery.c               | 183 +++++++++++++++++----
 3 files changed, 221 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[Marek Belisko]

This patches adding support for twl4030_madc_battery to use twl4030_madc iio framework + DT support.
Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
first patch to iio consumer and in next patches is added support for devicetree
+ some small fixes for module autoloading.

Changes from V2:
- fix property names
- add MODULE_DEVICE_TABLE and MODULE_ALIAS

Changes from V1:
- use iio_read_channel_processed instead iio_read_channel_processed
- convert probe to use devm_ as part of adding error handling for iio
- free iio channels on error and on module removal

[1] - https://lkml.org/lkml/2014/2/26/482dd

Marek Belisko (6):
  power: twl4030-madc-battery: Convert to iio consumer.
  power: twl4030_madc_battery: Add device tree support
  Documentation: DT: Document twl4030-madc-battery bindings
  ARM: dts: omap3-gta04: Add battery support
  power: twl4030_madc_battery: Add of_twl4030_madc_match to
    MODULE_DEVICE_TABLE
  power: twl4030_madc_battery: Add missing MODULE_ALIAS

 .../bindings/power_supply/twl4030_madc_battery.txt |  43 +++++
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  30 ++++
 drivers/power/twl4030_madc_battery.c               | 183 +++++++++++++++++----
 3 files changed, 221 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

-- 
1.9.1

[PATCH v3 1/6] power: twl4030-madc-battery: Convert to iio consumer.

[Marek Belisko]

Because of added iio error handling private data allocation was converted
to managed to simplify code.

Signed-off-by: Marek Belisko <marek@goldelico.com>
Reviewed-By: Sebastian Reichel <sre@debian.org>
---
 drivers/power/twl4030_madc_battery.c | 99 +++++++++++++++++++++++-------------
 1 file changed, 64 insertions(+), 35 deletions(-)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 7ef445a..6af28b5 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -19,10 +19,14 @@
 #include <linux/sort.h>
 #include <linux/i2c/twl4030-madc.h>
 #include <linux/power/twl4030_madc_battery.h>
+#include <linux/iio/consumer.h>
 
 struct twl4030_madc_battery {
 	struct power_supply psy;
 	struct twl4030_madc_bat_platform_data *pdata;
+	struct iio_channel *channel_temp;
+	struct iio_channel *channel_ichg;
+	struct iio_channel *channel_vbat;
 };
 
 static enum power_supply_property twl4030_madc_bat_props[] = {
@@ -38,43 +42,34 @@ static enum power_supply_property twl4030_madc_bat_props[] = {
 	POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
 };
 
-static int madc_read(int index)
+static int madc_read(struct iio_channel *channel)
 {
-	struct twl4030_madc_request req;
-	int val;
+	int val, err;
+	err = iio_read_channel_processed(channel, &val);
+	if (err < 0)
+		return err;
 
-	req.channels = index;
-	req.method = TWL4030_MADC_SW2;
-	req.type = TWL4030_MADC_WAIT;
-	req.do_avg = 0;
-	req.raw = false;
-	req.func_cb = NULL;
-
-	val = twl4030_madc_conversion(&req);
-	if (val < 0)
-		return val;
-
-	return req.rbuf[ffs(index) - 1];
+	return val;
 }
 
-static int twl4030_madc_bat_get_charging_status(void)
+static int twl4030_madc_bat_get_charging_status(struct twl4030_madc_battery *bt)
 {
-	return (madc_read(TWL4030_MADC_ICHG) > 0) ? 1 : 0;
+	return (madc_read(bt->channel_ichg) > 0) ? 1 : 0;
 }
 
-static int twl4030_madc_bat_get_voltage(void)
+static int twl4030_madc_bat_get_voltage(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_VBAT);
+	return madc_read(bt->channel_vbat);
 }
 
-static int twl4030_madc_bat_get_current(void)
+static int twl4030_madc_bat_get_current(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_ICHG) * 1000;
+	return madc_read(bt->channel_ichg) * 1000;
 }
 
-static int twl4030_madc_bat_get_temp(void)
+static int twl4030_madc_bat_get_temp(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_BTEMP) * 10;
+	return madc_read(bt->channel_temp) * 10;
 }
 
 static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
@@ -84,7 +79,7 @@ static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
 	int i, res = 0;
 
 	/* choose charging curve */
-	if (twl4030_madc_bat_get_charging_status())
+	if (twl4030_madc_bat_get_charging_status(bat))
 		calibration = bat->pdata->charging;
 	else
 		calibration = bat->pdata->discharging;
@@ -119,23 +114,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
 	switch (psp) {
 	case POWER_SUPPLY_PROP_STATUS:
 		if (twl4030_madc_bat_voltscale(bat,
-				twl4030_madc_bat_get_voltage()) > 95)
+				twl4030_madc_bat_get_voltage(bat)) > 95)
 			val->intval = POWER_SUPPLY_STATUS_FULL;
 		else {
-			if (twl4030_madc_bat_get_charging_status())
+			if (twl4030_madc_bat_get_charging_status(bat))
 				val->intval = POWER_SUPPLY_STATUS_CHARGING;
 			else
 				val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
 		}
 		break;
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-		val->intval = twl4030_madc_bat_get_voltage() * 1000;
+		val->intval = twl4030_madc_bat_get_voltage(bat) * 1000;
 		break;
 	case POWER_SUPPLY_PROP_TECHNOLOGY:
 		val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
 		break;
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
-		val->intval = twl4030_madc_bat_get_current();
+		val->intval = twl4030_madc_bat_get_current(bat);
 		break;
 	case POWER_SUPPLY_PROP_PRESENT:
 		/* assume battery is always present */
@@ -143,23 +138,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_NOW: {
 			int percent = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 			val->intval = (percent * bat->pdata->capacity) / 100;
 			break;
 		}
 	case POWER_SUPPLY_PROP_CAPACITY:
 		val->intval = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_FULL:
 		val->intval = bat->pdata->capacity;
 		break;
 	case POWER_SUPPLY_PROP_TEMP:
-		val->intval = twl4030_madc_bat_get_temp();
+		val->intval = twl4030_madc_bat_get_temp(bat);
 		break;
 	case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: {
 			int percent = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 			/* in mAh */
 			int chg = (percent * (bat->pdata->capacity/1000))/100;
 
@@ -192,8 +187,10 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 {
 	struct twl4030_madc_battery *twl4030_madc_bat;
 	struct twl4030_madc_bat_platform_data *pdata = pdev->dev.platform_data;
+	int ret;
 
-	twl4030_madc_bat = kzalloc(sizeof(*twl4030_madc_bat), GFP_KERNEL);
+	twl4030_madc_bat = devm_kzalloc(&pdev->dev, sizeof(*twl4030_madc_bat),
+				GFP_KERNEL);
 	if (!twl4030_madc_bat)
 		return -ENOMEM;
 
@@ -206,6 +203,24 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 	twl4030_madc_bat->psy.external_power_changed =
 					twl4030_madc_bat_ext_changed;
 
+	twl4030_madc_bat->channel_temp = iio_channel_get(&pdev->dev, "temp");
+	if (IS_ERR(twl4030_madc_bat->channel_temp)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_temp);
+		goto err;
+	}
+
+	twl4030_madc_bat->channel_ichg  = iio_channel_get(&pdev->dev, "ichg");
+	if (IS_ERR(twl4030_madc_bat->channel_ichg)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_ichg);
+		goto err_temp;
+	}
+
+	twl4030_madc_bat->channel_vbat = iio_channel_get(&pdev->dev, "vbat");
+	if (IS_ERR(twl4030_madc_bat->channel_vbat)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_vbat);
+		goto err_ichg;
+	}
+
 	/* sort charging and discharging calibration data */
 	sort(pdata->charging, pdata->charging_size,
 		sizeof(struct twl4030_madc_bat_calibration),
@@ -216,9 +231,20 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 
 	twl4030_madc_bat->pdata = pdata;
 	platform_set_drvdata(pdev, twl4030_madc_bat);
-	power_supply_register(&pdev->dev, &twl4030_madc_bat->psy);
+	ret = power_supply_register(&pdev->dev, &twl4030_madc_bat->psy);
+	if (ret)
+		goto err_vbat;
 
 	return 0;
+
+err_vbat:
+	iio_channel_release(twl4030_madc_bat->channel_vbat);
+err_ichg:
+	iio_channel_release(twl4030_madc_bat->channel_ichg);
+err_temp:
+	iio_channel_release(twl4030_madc_bat->channel_temp);
+err:
+	return ret;
 }
 
 static int twl4030_madc_battery_remove(struct platform_device *pdev)
@@ -226,7 +252,10 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
 	struct twl4030_madc_battery *bat = platform_get_drvdata(pdev);
 
 	power_supply_unregister(&bat->psy);
-	kfree(bat);
+
+	iio_channel_release(bat->channel_vbat);
+	iio_channel_release(bat->channel_ichg);
+	iio_channel_release(bat->channel_temp);
 
 	return 0;
 }
-- 
1.9.1

[PATCH v3 1/6] power: twl4030-madc-battery: Convert to iio consumer.

[Marek Belisko]

Because of added iio error handling private data allocation was converted
to managed to simplify code.

Signed-off-by: Marek Belisko <marek@goldelico.com>
Reviewed-By: Sebastian Reichel <sre@debian.org>
---
 drivers/power/twl4030_madc_battery.c | 99 +++++++++++++++++++++++-------------
 1 file changed, 64 insertions(+), 35 deletions(-)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 7ef445a..6af28b5 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -19,10 +19,14 @@
 #include <linux/sort.h>
 #include <linux/i2c/twl4030-madc.h>
 #include <linux/power/twl4030_madc_battery.h>
+#include <linux/iio/consumer.h>
 
 struct twl4030_madc_battery {
 	struct power_supply psy;
 	struct twl4030_madc_bat_platform_data *pdata;
+	struct iio_channel *channel_temp;
+	struct iio_channel *channel_ichg;
+	struct iio_channel *channel_vbat;
 };
 
 static enum power_supply_property twl4030_madc_bat_props[] = {
@@ -38,43 +42,34 @@ static enum power_supply_property twl4030_madc_bat_props[] = {
 	POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
 };
 
-static int madc_read(int index)
+static int madc_read(struct iio_channel *channel)
 {
-	struct twl4030_madc_request req;
-	int val;
+	int val, err;
+	err = iio_read_channel_processed(channel, &val);
+	if (err < 0)
+		return err;
 
-	req.channels = index;
-	req.method = TWL4030_MADC_SW2;
-	req.type = TWL4030_MADC_WAIT;
-	req.do_avg = 0;
-	req.raw = false;
-	req.func_cb = NULL;
-
-	val = twl4030_madc_conversion(&req);
-	if (val < 0)
-		return val;
-
-	return req.rbuf[ffs(index) - 1];
+	return val;
 }
 
-static int twl4030_madc_bat_get_charging_status(void)
+static int twl4030_madc_bat_get_charging_status(struct twl4030_madc_battery *bt)
 {
-	return (madc_read(TWL4030_MADC_ICHG) > 0) ? 1 : 0;
+	return (madc_read(bt->channel_ichg) > 0) ? 1 : 0;
 }
 
-static int twl4030_madc_bat_get_voltage(void)
+static int twl4030_madc_bat_get_voltage(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_VBAT);
+	return madc_read(bt->channel_vbat);
 }
 
-static int twl4030_madc_bat_get_current(void)
+static int twl4030_madc_bat_get_current(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_ICHG) * 1000;
+	return madc_read(bt->channel_ichg) * 1000;
 }
 
-static int twl4030_madc_bat_get_temp(void)
+static int twl4030_madc_bat_get_temp(struct twl4030_madc_battery *bt)
 {
-	return madc_read(TWL4030_MADC_BTEMP) * 10;
+	return madc_read(bt->channel_temp) * 10;
 }
 
 static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
@@ -84,7 +79,7 @@ static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
 	int i, res = 0;
 
 	/* choose charging curve */
-	if (twl4030_madc_bat_get_charging_status())
+	if (twl4030_madc_bat_get_charging_status(bat))
 		calibration = bat->pdata->charging;
 	else
 		calibration = bat->pdata->discharging;
@@ -119,23 +114,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
 	switch (psp) {
 	case POWER_SUPPLY_PROP_STATUS:
 		if (twl4030_madc_bat_voltscale(bat,
-				twl4030_madc_bat_get_voltage()) > 95)
+				twl4030_madc_bat_get_voltage(bat)) > 95)
 			val->intval = POWER_SUPPLY_STATUS_FULL;
 		else {
-			if (twl4030_madc_bat_get_charging_status())
+			if (twl4030_madc_bat_get_charging_status(bat))
 				val->intval = POWER_SUPPLY_STATUS_CHARGING;
 			else
 				val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
 		}
 		break;
 	case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-		val->intval = twl4030_madc_bat_get_voltage() * 1000;
+		val->intval = twl4030_madc_bat_get_voltage(bat) * 1000;
 		break;
 	case POWER_SUPPLY_PROP_TECHNOLOGY:
 		val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
 		break;
 	case POWER_SUPPLY_PROP_CURRENT_NOW:
-		val->intval = twl4030_madc_bat_get_current();
+		val->intval = twl4030_madc_bat_get_current(bat);
 		break;
 	case POWER_SUPPLY_PROP_PRESENT:
 		/* assume battery is always present */
@@ -143,23 +138,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_NOW: {
 			int percent = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 			val->intval = (percent * bat->pdata->capacity) / 100;
 			break;
 		}
 	case POWER_SUPPLY_PROP_CAPACITY:
 		val->intval = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 		break;
 	case POWER_SUPPLY_PROP_CHARGE_FULL:
 		val->intval = bat->pdata->capacity;
 		break;
 	case POWER_SUPPLY_PROP_TEMP:
-		val->intval = twl4030_madc_bat_get_temp();
+		val->intval = twl4030_madc_bat_get_temp(bat);
 		break;
 	case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: {
 			int percent = twl4030_madc_bat_voltscale(bat,
-					twl4030_madc_bat_get_voltage());
+					twl4030_madc_bat_get_voltage(bat));
 			/* in mAh */
 			int chg = (percent * (bat->pdata->capacity/1000))/100;
 
@@ -192,8 +187,10 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 {
 	struct twl4030_madc_battery *twl4030_madc_bat;
 	struct twl4030_madc_bat_platform_data *pdata = pdev->dev.platform_data;
+	int ret;
 
-	twl4030_madc_bat = kzalloc(sizeof(*twl4030_madc_bat), GFP_KERNEL);
+	twl4030_madc_bat = devm_kzalloc(&pdev->dev, sizeof(*twl4030_madc_bat),
+				GFP_KERNEL);
 	if (!twl4030_madc_bat)
 		return -ENOMEM;
 
@@ -206,6 +203,24 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 	twl4030_madc_bat->psy.external_power_changed =
 					twl4030_madc_bat_ext_changed;
 
+	twl4030_madc_bat->channel_temp = iio_channel_get(&pdev->dev, "temp");
+	if (IS_ERR(twl4030_madc_bat->channel_temp)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_temp);
+		goto err;
+	}
+
+	twl4030_madc_bat->channel_ichg  = iio_channel_get(&pdev->dev, "ichg");
+	if (IS_ERR(twl4030_madc_bat->channel_ichg)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_ichg);
+		goto err_temp;
+	}
+
+	twl4030_madc_bat->channel_vbat = iio_channel_get(&pdev->dev, "vbat");
+	if (IS_ERR(twl4030_madc_bat->channel_vbat)) {
+		ret = PTR_ERR(twl4030_madc_bat->channel_vbat);
+		goto err_ichg;
+	}
+
 	/* sort charging and discharging calibration data */
 	sort(pdata->charging, pdata->charging_size,
 		sizeof(struct twl4030_madc_bat_calibration),
@@ -216,9 +231,20 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 
 	twl4030_madc_bat->pdata = pdata;
 	platform_set_drvdata(pdev, twl4030_madc_bat);
-	power_supply_register(&pdev->dev, &twl4030_madc_bat->psy);
+	ret = power_supply_register(&pdev->dev, &twl4030_madc_bat->psy);
+	if (ret)
+		goto err_vbat;
 
 	return 0;
+
+err_vbat:
+	iio_channel_release(twl4030_madc_bat->channel_vbat);
+err_ichg:
+	iio_channel_release(twl4030_madc_bat->channel_ichg);
+err_temp:
+	iio_channel_release(twl4030_madc_bat->channel_temp);
+err:
+	return ret;
 }
 
 static int twl4030_madc_battery_remove(struct platform_device *pdev)
@@ -226,7 +252,10 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
 	struct twl4030_madc_battery *bat = platform_get_drvdata(pdev);
 
 	power_supply_unregister(&bat->psy);
-	kfree(bat);
+
+	iio_channel_release(bat->channel_vbat);
+	iio_channel_release(bat->channel_ichg);
+	iio_channel_release(bat->channel_temp);
 
 	return 0;
 }
-- 
1.9.1

[PATCH v3 2/6] power: twl4030_madc_battery: Add device tree support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 6af28b5..ec14bc6 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -20,6 +20,7 @@
 #include <linux/i2c/twl4030-madc.h>
 #include <linux/power/twl4030_madc_battery.h>
 #include <linux/iio/consumer.h>
+#include <linux/of.h>
 
 struct twl4030_madc_battery {
 	struct power_supply psy;
@@ -183,6 +184,82 @@ static int twl4030_cmp(const void *a, const void *b)
 		((struct twl4030_madc_bat_calibration *)a)->voltage;
 }
 
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	struct twl4030_madc_bat_platform_data *pdata;
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+	int i, proplen;
+
+	pdata = devm_kzalloc(&pdev->dev,
+			sizeof(struct twl4030_madc_bat_platform_data),
+			GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "capacity-uah", &pdata->capacity);
+	if (ret != 0)
+		return ERR_PTR(-EINVAL);
+
+	/* parse and prepare charging data */
+	proplen = of_property_count_u32_elems(np, "volt-to-capacity-charging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-charging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->charging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					   i * 2,
+					   (u32 *)&pdata->charging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					  i * 2 + 1,
+					  (u32 *)&pdata->charging[i].level);
+	}
+
+	/* parse and prepare discharging data */
+	proplen = of_property_count_u32_elems(np,
+			"volt-to-capacity-discharging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-discharging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->discharging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2,
+					   (u32 *)&pdata->discharging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2 + 1,
+					   (u32 *)&pdata->discharging[i].level);
+	}
+
+	return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+	{ .compatible = "ti,twl4030-madc-battery", },
+	{},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	return ERR_PTR(-ENODEV);
+}
+#endif
+
 static int twl4030_madc_battery_probe(struct platform_device *pdev)
 {
 	struct twl4030_madc_battery *twl4030_madc_bat;
@@ -194,6 +271,9 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 	if (!twl4030_madc_bat)
 		return -ENOMEM;
 
+	if (!pdata)
+		pdata = twl4030_madc_dt_probe(pdev);
+
 	twl4030_madc_bat->psy.name = "twl4030_battery";
 	twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
 	twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -263,6 +343,7 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
 static struct platform_driver twl4030_madc_battery_driver = {
 	.driver = {
 		.name = "twl4030_madc_battery",
+		.of_match_table = of_match_ptr(of_twl4030_madc_match),
 	},
 	.probe  = twl4030_madc_battery_probe,
 	.remove = twl4030_madc_battery_remove,
-- 
1.9.1

[PATCH v3 2/6] power: twl4030_madc_battery: Add device tree support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 6af28b5..ec14bc6 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -20,6 +20,7 @@
 #include <linux/i2c/twl4030-madc.h>
 #include <linux/power/twl4030_madc_battery.h>
 #include <linux/iio/consumer.h>
+#include <linux/of.h>
 
 struct twl4030_madc_battery {
 	struct power_supply psy;
@@ -183,6 +184,82 @@ static int twl4030_cmp(const void *a, const void *b)
 		((struct twl4030_madc_bat_calibration *)a)->voltage;
 }
 
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	struct twl4030_madc_bat_platform_data *pdata;
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+	int i, proplen;
+
+	pdata = devm_kzalloc(&pdev->dev,
+			sizeof(struct twl4030_madc_bat_platform_data),
+			GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "capacity-uah", &pdata->capacity);
+	if (ret != 0)
+		return ERR_PTR(-EINVAL);
+
+	/* parse and prepare charging data */
+	proplen = of_property_count_u32_elems(np, "volt-to-capacity-charging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-charging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->charging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					   i * 2,
+					   (u32 *)&pdata->charging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					  i * 2 + 1,
+					  (u32 *)&pdata->charging[i].level);
+	}
+
+	/* parse and prepare discharging data */
+	proplen = of_property_count_u32_elems(np,
+			"volt-to-capacity-discharging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-discharging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->discharging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2,
+					   (u32 *)&pdata->discharging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2 + 1,
+					   (u32 *)&pdata->discharging[i].level);
+	}
+
+	return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+	{ .compatible = "ti,twl4030-madc-battery", },
+	{},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	return ERR_PTR(-ENODEV);
+}
+#endif
+
 static int twl4030_madc_battery_probe(struct platform_device *pdev)
 {
 	struct twl4030_madc_battery *twl4030_madc_bat;
@@ -194,6 +271,9 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 	if (!twl4030_madc_bat)
 		return -ENOMEM;
 
+	if (!pdata)
+		pdata = twl4030_madc_dt_probe(pdev);
+
 	twl4030_madc_bat->psy.name = "twl4030_battery";
 	twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
 	twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -263,6 +343,7 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
 static struct platform_driver twl4030_madc_battery_driver = {
 	.driver = {
 		.name = "twl4030_madc_battery",
+		.of_match_table = of_match_ptr(of_twl4030_madc_match),
 	},
 	.probe  = twl4030_madc_battery_probe,
 	.remove = twl4030_madc_battery_remove,
-- 
1.9.1

[PATCH v3 2/6] power: twl4030_madc_battery: Add device tree support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 6af28b5..ec14bc6 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -20,6 +20,7 @@
 #include <linux/i2c/twl4030-madc.h>
 #include <linux/power/twl4030_madc_battery.h>
 #include <linux/iio/consumer.h>
+#include <linux/of.h>
 
 struct twl4030_madc_battery {
 	struct power_supply psy;
@@ -183,6 +184,82 @@ static int twl4030_cmp(const void *a, const void *b)
 		((struct twl4030_madc_bat_calibration *)a)->voltage;
 }
 
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	struct twl4030_madc_bat_platform_data *pdata;
+	struct device_node *np = pdev->dev.of_node;
+	int ret;
+	int i, proplen;
+
+	pdata = devm_kzalloc(&pdev->dev,
+			sizeof(struct twl4030_madc_bat_platform_data),
+			GFP_KERNEL);
+	if (!pdata)
+		return ERR_PTR(-ENOMEM);
+
+	ret = of_property_read_u32(np, "capacity-uah", &pdata->capacity);
+	if (ret != 0)
+		return ERR_PTR(-EINVAL);
+
+	/* parse and prepare charging data */
+	proplen = of_property_count_u32_elems(np, "volt-to-capacity-charging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-charging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->charging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					   i * 2,
+					   (u32 *)&pdata->charging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-charging-map",
+					  i * 2 + 1,
+					  (u32 *)&pdata->charging[i].level);
+	}
+
+	/* parse and prepare discharging data */
+	proplen = of_property_count_u32_elems(np,
+			"volt-to-capacity-discharging-map");
+	if (proplen < 0) {
+		dev_warn(&pdev->dev, "No 'volt-to-capacity-discharging-map' property found\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	pdata->discharging = devm_kzalloc(&pdev->dev,
+		sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+		GFP_KERNEL);
+
+	for (i = 0; i < proplen / 2; i++) {
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2,
+					   (u32 *)&pdata->discharging[i].voltage);
+		of_property_read_u32_index(np, "volt-to-capacity-discharging-map",
+					   i * 2 + 1,
+					   (u32 *)&pdata->discharging[i].level);
+	}
+
+	return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+	{ .compatible = "ti,twl4030-madc-battery", },
+	{},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+	twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+	return ERR_PTR(-ENODEV);
+}
+#endif
+
 static int twl4030_madc_battery_probe(struct platform_device *pdev)
 {
 	struct twl4030_madc_battery *twl4030_madc_bat;
@@ -194,6 +271,9 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
 	if (!twl4030_madc_bat)
 		return -ENOMEM;
 
+	if (!pdata)
+		pdata = twl4030_madc_dt_probe(pdev);
+
 	twl4030_madc_bat->psy.name = "twl4030_battery";
 	twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
 	twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -263,6 +343,7 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
 static struct platform_driver twl4030_madc_battery_driver = {
 	.driver = {
 		.name = "twl4030_madc_battery",
+		.of_match_table = of_match_ptr(of_twl4030_madc_match),
 	},
 	.probe  = twl4030_madc_battery_probe,
 	.remove = twl4030_madc_battery_remove,
-- 
1.9.1

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 0000000..bb3580c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : "ti,twl4030-madc-battery"
+ - capacity-uah : battery capacity in uAh
+ - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
+	for charging calibration (see example)
+ - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
+	for discharging calibration (see example)
+ - io-channels: Should contain IIO channel specifiers
+	for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * "temp" - The ADC channel for temperature reading
+ * "ichg" - The ADC channel for battery charging status
+ * "vbat" - The ADC channel to measure the battery voltage
+
+Example:
+	madc-battery {
+		compatible = "ti,twl4030-madc-battery";
+		capacity-uah = <1200000>;
+		volt-to-capacity-charging-map = <4200 100>,
+					        <4100 75>,
+					        <4000 55>,
+					        <3900 25>,
+					        <3800 5>,
+					        <3700 2>,
+					        <3600 1>,
+					        <3300 0>;
+
+		volt-to-capacity-discharging-map = <4200 100>
+						   <4100 95>,
+						   <4000 70>,
+						   <3800 50>,
+						   <3700 10>,
+						   <3600 5>,
+						   <3300 0>;
+		io-channels = <&twl_madc 1>,
+	                      <&twl_madc 10>,
+			      <&twl_madc 12>;
+		io-channel-names = "temp",
+		                   "ichg",
+		                   "vbat";
+	};
-- 
1.9.1

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt

diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 0000000..bb3580c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : "ti,twl4030-madc-battery"
+ - capacity-uah : battery capacity in uAh
+ - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
+	for charging calibration (see example)
+ - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
+	for discharging calibration (see example)
+ - io-channels: Should contain IIO channel specifiers
+	for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * "temp" - The ADC channel for temperature reading
+ * "ichg" - The ADC channel for battery charging status
+ * "vbat" - The ADC channel to measure the battery voltage
+
+Example:
+	madc-battery {
+		compatible = "ti,twl4030-madc-battery";
+		capacity-uah = <1200000>;
+		volt-to-capacity-charging-map = <4200 100>,
+					        <4100 75>,
+					        <4000 55>,
+					        <3900 25>,
+					        <3800 5>,
+					        <3700 2>,
+					        <3600 1>,
+					        <3300 0>;
+
+		volt-to-capacity-discharging-map = <4200 100>
+						   <4100 95>,
+						   <4000 70>,
+						   <3800 50>,
+						   <3700 10>,
+						   <3600 5>,
+						   <3300 0>;
+		io-channels = <&twl_madc 1>,
+	                      <&twl_madc 10>,
+			      <&twl_madc 12>;
+		io-channel-names = "temp",
+		                   "ichg",
+		                   "vbat";
+	};
-- 
1.9.1

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 655d6e9..f81ca27 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -49,6 +49,32 @@
 		ti,codec = <&twl_audio>;
 	};
 
+	battery {
+		compatible = "ti,twl4030-madc-battery";
+		capacity-uah = <1200000>;
+		volt-to-capacity-charging-map = <4200 100>,
+					     <4100 75>,
+					     <4000 55>,
+					     <3900 25>,
+					     <3800 5>,
+					     <3700 2>,
+					     <3600 1>,
+					     <3300 0>;
+		volt-to-capacity-discharging-map = <4200 100>,
+						<4100 95>,
+						<4000 70>,
+						<3800 50>,
+						<3700 10>,
+						<3600 5>,
+						<3300 0>;
+		io-channels = <&twl_madc 1>,
+	                      <&twl_madc 10>,
+			      <&twl_madc 12>;
+		io-channel-names = "temp",
+		                   "ichg",
+		                   "vbat";
+	};
+
 	spi_lcd {
 		compatible = "spi-gpio";
 		#address-cells = <0x1>;
@@ -449,3 +475,7 @@
 		};
 	};
 };
+
+&twl_madc {
+	ti,system-uses-second-madc-irq;
+};
-- 
1.9.1

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 655d6e9..f81ca27 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -49,6 +49,32 @@
 		ti,codec = <&twl_audio>;
 	};
 
+	battery {
+		compatible = "ti,twl4030-madc-battery";
+		capacity-uah = <1200000>;
+		volt-to-capacity-charging-map = <4200 100>,
+					     <4100 75>,
+					     <4000 55>,
+					     <3900 25>,
+					     <3800 5>,
+					     <3700 2>,
+					     <3600 1>,
+					     <3300 0>;
+		volt-to-capacity-discharging-map = <4200 100>,
+						<4100 95>,
+						<4000 70>,
+						<3800 50>,
+						<3700 10>,
+						<3600 5>,
+						<3300 0>;
+		io-channels = <&twl_madc 1>,
+	                      <&twl_madc 10>,
+			      <&twl_madc 12>;
+		io-channel-names = "temp",
+		                   "ichg",
+		                   "vbat";
+	};
+
 	spi_lcd {
 		compatible = "spi-gpio";
 		#address-cells = <0x1>;
@@ -449,3 +475,7 @@
 		};
 	};
 };
+
+&twl_madc {
+	ti,system-uses-second-madc-irq;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Marek Belisko]

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 655d6e9..f81ca27 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -49,6 +49,32 @@
 		ti,codec = <&twl_audio>;
 	};
 
+	battery {
+		compatible = "ti,twl4030-madc-battery";
+		capacity-uah = <1200000>;
+		volt-to-capacity-charging-map = <4200 100>,
+					     <4100 75>,
+					     <4000 55>,
+					     <3900 25>,
+					     <3800 5>,
+					     <3700 2>,
+					     <3600 1>,
+					     <3300 0>;
+		volt-to-capacity-discharging-map = <4200 100>,
+						<4100 95>,
+						<4000 70>,
+						<3800 50>,
+						<3700 10>,
+						<3600 5>,
+						<3300 0>;
+		io-channels = <&twl_madc 1>,
+	                      <&twl_madc 10>,
+			      <&twl_madc 12>;
+		io-channel-names = "temp",
+		                   "ichg",
+		                   "vbat";
+	};
+
 	spi_lcd {
 		compatible = "spi-gpio";
 		#address-cells = <0x1>;
@@ -449,3 +475,7 @@
 		};
 	};
 };
+
+&twl_madc {
+	ti,system-uses-second-madc-irq;
+};
-- 
1.9.1

[PATCH v3 5/6] power: twl4030_madc_battery: Add of_twl4030_madc_match to MODULE_DEVICE_TABLE

[Marek Belisko]

When twl_4030_madc_battery is build as module, MODULE_DEVICE_TABLE allow
the module to be auto-loaded since the module will match the devices
instantiated from device tree.

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index ec14bc6..e6075ae 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -252,6 +252,8 @@ static const struct of_device_id of_twl4030_madc_match[] = {
 	{},
 };
 
+MODULE_DEVICE_TABLE(of, of_twl4030_madc_match);
+
 #else
 static struct twl4030_madc_bat_platform_data *
 	twl4030_madc_dt_probe(struct platform_device *pdev)
-- 
1.9.1

[PATCH v3 5/6] power: twl4030_madc_battery: Add of_twl4030_madc_match to MODULE_DEVICE_TABLE

[Marek Belisko]

When twl_4030_madc_battery is build as module, MODULE_DEVICE_TABLE allow
the module to be auto-loaded since the module will match the devices
instantiated from device tree.

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index ec14bc6..e6075ae 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -252,6 +252,8 @@ static const struct of_device_id of_twl4030_madc_match[] = {
 	{},
 };
 
+MODULE_DEVICE_TABLE(of, of_twl4030_madc_match);
+
 #else
 static struct twl4030_madc_bat_platform_data *
 	twl4030_madc_dt_probe(struct platform_device *pdev)
-- 
1.9.1

[PATCH v3 6/6] power: twl4030_madc_battery: Add missing MODULE_ALIAS

[Marek Belisko]

Without MODULE_ALIAS twl4030_madc_battery won't get loaded automatically.

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index e6075ae..cea0927 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -355,3 +355,4 @@ module_platform_driver(twl4030_madc_battery_driver);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Lukas Märdian <lukas@goldelico.com>");
 MODULE_DESCRIPTION("twl4030_madc battery driver");
+MODULE_ALIAS("platform:twl4030_madc_battery");
-- 
1.9.1

[PATCH v3 6/6] power: twl4030_madc_battery: Add missing MODULE_ALIAS

[Marek Belisko]

Without MODULE_ALIAS twl4030_madc_battery won't get loaded automatically.

Signed-off-by: Marek Belisko <marek@goldelico.com>
---
 drivers/power/twl4030_madc_battery.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index e6075ae..cea0927 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -355,3 +355,4 @@ module_platform_driver(twl4030_madc_battery_driver);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Lukas M?rdian <lukas@goldelico.com>");
 MODULE_DESCRIPTION("twl4030_madc battery driver");
+MODULE_ALIAS("platform:twl4030_madc_battery");
-- 
1.9.1

Re: [PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[Belisko Marek]

Ping.

On Wed, Feb 4, 2015 at 11:14 PM, Marek Belisko <marek@goldelico.com> wrote:
> This patches adding support for twl4030_madc_battery to use twl4030_madc iio framework + DT support.
> Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
> first patch to iio consumer and in next patches is added support for devicetree
> + some small fixes for module autoloading.
>
> Changes from V2:
> - fix property names
> - add MODULE_DEVICE_TABLE and MODULE_ALIAS
>
> Changes from V1:
> - use iio_read_channel_processed instead iio_read_channel_processed
> - convert probe to use devm_ as part of adding error handling for iio
> - free iio channels on error and on module removal
>
> [1] - https://lkml.org/lkml/2014/2/26/482dd
>
> Marek Belisko (6):
>   power: twl4030-madc-battery: Convert to iio consumer.
>   power: twl4030_madc_battery: Add device tree support
>   Documentation: DT: Document twl4030-madc-battery bindings
>   ARM: dts: omap3-gta04: Add battery support
>   power: twl4030_madc_battery: Add of_twl4030_madc_match to
>     MODULE_DEVICE_TABLE
>   power: twl4030_madc_battery: Add missing MODULE_ALIAS
>
>  .../bindings/power_supply/twl4030_madc_battery.txt |  43 +++++
>  arch/arm/boot/dts/omap3-gta04.dtsi                 |  30 ++++
>  drivers/power/twl4030_madc_battery.c               | 183 +++++++++++++++++----
>  3 files changed, 221 insertions(+), 35 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>
> --
> 1.9.1
>



-- 
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

[PATCH v3 0/6] Convert twl4030_madc_battery to IIO consumer and add DT aupport

[Belisko Marek]

Ping.

On Wed, Feb 4, 2015 at 11:14 PM, Marek Belisko <marek@goldelico.com> wrote:
> This patches adding support for twl4030_madc_battery to use twl4030_madc iio framework + DT support.
> Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
> first patch to iio consumer and in next patches is added support for devicetree
> + some small fixes for module autoloading.
>
> Changes from V2:
> - fix property names
> - add MODULE_DEVICE_TABLE and MODULE_ALIAS
>
> Changes from V1:
> - use iio_read_channel_processed instead iio_read_channel_processed
> - convert probe to use devm_ as part of adding error handling for iio
> - free iio channels on error and on module removal
>
> [1] - https://lkml.org/lkml/2014/2/26/482dd
>
> Marek Belisko (6):
>   power: twl4030-madc-battery: Convert to iio consumer.
>   power: twl4030_madc_battery: Add device tree support
>   Documentation: DT: Document twl4030-madc-battery bindings
>   ARM: dts: omap3-gta04: Add battery support
>   power: twl4030_madc_battery: Add of_twl4030_madc_match to
>     MODULE_DEVICE_TABLE
>   power: twl4030_madc_battery: Add missing MODULE_ALIAS
>
>  .../bindings/power_supply/twl4030_madc_battery.txt |  43 +++++
>  arch/arm/boot/dts/omap3-gta04.dtsi                 |  30 ++++
>  drivers/power/twl4030_madc_battery.c               | 183 +++++++++++++++++----
>  3 files changed, 221 insertions(+), 35 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>
> --
> 1.9.1
>



-- 
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: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Sebastian Reichel]

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

Hi,

On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

DTS changes must go via omap-dt tree once the driver changes have been
merged.

-- Sebastian

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

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Sebastian Reichel]

Hi,

On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

DTS changes must go via omap-dt tree once the driver changes have been
merged.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150305/94038dfc/attachment.sig>

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Sebastian Reichel]

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

Hi,

On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote:
> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> +	for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> +	for discharging calibration (see example)

Please prefix these properties with "ti,"

-- Sebastian

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

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Sebastian Reichel]

Hi,

On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote:
> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> +	for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> +	for discharging calibration (see example)

Please prefix these properties with "ti,"

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150305/a03a99da/attachment.sig>

Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Sebastian Reichel <sre@kernel.org> [150304 16:41]:
> Hi,
> 
> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> > ---
> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> 
> DTS changes must go via omap-dt tree once the driver changes have been
> merged.

And looks like you wanted to add ti, prefix to the binding. I'll
mark this one as read, please repost this one separately once the
driver changes are in Linux next.

Regards,

Tony

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Sebastian Reichel <sre@kernel.org> [150304 16:41]:
> Hi,
> 
> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> > ---
> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> 
> DTS changes must go via omap-dt tree once the driver changes have been
> merged.

And looks like you wanted to add ti, prefix to the binding. I'll
mark this one as read, please repost this one separately once the
driver changes are in Linux next.

Regards,

Tony

Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Belisko Marek]

Hi Tony,

On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Sebastian Reichel <sre@kernel.org> [150304 16:41]:
>> Hi,
>>
>> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
>> > Signed-off-by: Marek Belisko <marek@goldelico.com>
>> > ---
>> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
>> >  1 file changed, 30 insertions(+)
>>
>> DTS changes must go via omap-dt tree once the driver changes have been
>> merged.
>
> And looks like you wanted to add ti, prefix to the binding. I'll
> mark this one as read, please repost this one separately once the
> driver changes are in Linux next.
ti prefix Iis done in v4 series already [1]
>
> Regards,
>
> Tony

[1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.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

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Belisko Marek]

Hi Tony,

On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Sebastian Reichel <sre@kernel.org> [150304 16:41]:
>> Hi,
>>
>> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
>> > Signed-off-by: Marek Belisko <marek@goldelico.com>
>> > ---
>> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
>> >  1 file changed, 30 insertions(+)
>>
>> DTS changes must go via omap-dt tree once the driver changes have been
>> merged.
>
> And looks like you wanted to add ti, prefix to the binding. I'll
> mark this one as read, please repost this one separately once the
> driver changes are in Linux next.
ti prefix Iis done in v4 series already [1]
>
> Regards,
>
> Tony

[1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.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: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Belisko Marek <marek.belisko@gmail.com> [150316 13:47]:
> Hi Tony,
> 
> On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Sebastian Reichel <sre@kernel.org> [150304 16:41]:
> >> Hi,
> >>
> >> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> >> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> >> > ---
> >> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
> >> >  1 file changed, 30 insertions(+)
> >>
> >> DTS changes must go via omap-dt tree once the driver changes have been
> >> merged.
> >
> > And looks like you wanted to add ti, prefix to the binding. I'll
> > mark this one as read, please repost this one separately once the
> > driver changes are in Linux next.
> ti prefix Iis done in v4 series already [1]
> >
> > Regards,
> >
> > Tony
> 
> [1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html

OK will pick it from there thanks.

Tony

[PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Belisko Marek <marek.belisko@gmail.com> [150316 13:47]:
> Hi Tony,
> 
> On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Sebastian Reichel <sre@kernel.org> [150304 16:41]:
> >> Hi,
> >>
> >> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> >> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> >> > ---
> >> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++++++++++++++++++++++++++++++
> >> >  1 file changed, 30 insertions(+)
> >>
> >> DTS changes must go via omap-dt tree once the driver changes have been
> >> merged.
> >
> > And looks like you wanted to add ti, prefix to the binding. I'll
> > mark this one as read, please repost this one separately once the
> > driver changes are in Linux next.
> ti prefix Iis done in v4 series already [1]
> >
> > Regards,
> >
> > Tony
> 
> [1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html

OK will pick it from there thanks.

Tony

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> 
> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> new file mode 100644
> index 0000000..bb3580c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> @@ -0,0 +1,43 @@
> +twl4030_madc_battery
> +
> +Required properties:
> + - compatible : "ti,twl4030-madc-battery"
> + - capacity-uah : battery capacity in uAh

Could we make it capacity-uAh ?

> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> +	for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> +	for discharging calibration (see example)

Would "mV-to-capacity..." be more accurate? Also, would it make sense
to introduce coefficients for temperature and discharge rate?

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

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> ---
>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> 
> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> new file mode 100644
> index 0000000..bb3580c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> @@ -0,0 +1,43 @@
> +twl4030_madc_battery
> +
> +Required properties:
> + - compatible : "ti,twl4030-madc-battery"
> + - capacity-uah : battery capacity in uAh

Could we make it capacity-uAh ?

> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> +	for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> +	for discharging calibration (see example)

Would "mV-to-capacity..." be more accurate? Also, would it make sense
to introduce coefficients for temperature and discharge rate?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> 
> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> new file mode 100644
> index 0000000..bb3580c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> @@ -0,0 +1,43 @@
> +twl4030_madc_battery
> +
> +Required properties:
> + - compatible : "ti,twl4030-madc-battery"
> + - capacity-uah : battery capacity in uAh

Could we make it capacity-uAh ?

> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> +	for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> +	for discharging calibration (see example)

Would "mV-to-capacity..." be more accurate? Also, would it make sense
to introduce coefficients for temperature and discharge rate?

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

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Belisko Marek]

On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> new file mode 100644
>> index 0000000..bb3580c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> @@ -0,0 +1,43 @@
>> +twl4030_madc_battery
>> +
>> +Required properties:
>> + - compatible : "ti,twl4030-madc-battery"
>> + - capacity-uah : battery capacity in uAh
>
> Could we make it capacity-uAh ?
This name was suggested by Mark Rutland [1] and naming convention
should be all lowercase. There exists already bindings
without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>
>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>> +     for charging calibration (see example)
>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>> +     for discharging calibration (see example)
>
> Would "mV-to-capacity..." be more accurate? Also, would it make sense
Again maybe mv but it can be added also later.
> to introduce coefficients for temperature and discharge rate?
What do you mean? Nothing like that is used in current driver why do
we need to add it?
>
> Thanks,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[1] - http://lists.openwall.net/linux-kernel/2014/10/09/104

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

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Belisko Marek]

On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> new file mode 100644
>> index 0000000..bb3580c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> @@ -0,0 +1,43 @@
>> +twl4030_madc_battery
>> +
>> +Required properties:
>> + - compatible : "ti,twl4030-madc-battery"
>> + - capacity-uah : battery capacity in uAh
>
> Could we make it capacity-uAh ?
This name was suggested by Mark Rutland [1] and naming convention
should be all lowercase. There exists already bindings
without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>
>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>> +     for charging calibration (see example)
>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>> +     for discharging calibration (see example)
>
> Would "mV-to-capacity..." be more accurate? Also, would it make sense
Again maybe mv but it can be added also later.
> to introduce coefficients for temperature and discharge rate?
What do you mean? Nothing like that is used in current driver why do
we need to add it?
>
> Thanks,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[1] - http://lists.openwall.net/linux-kernel/2014/10/09/104

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: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 16.03.2015 um 22:20 schrieb Belisko Marek <marek.belisko@gmail.com>:

> On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>>> ---
>>> .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>>> 1 file changed, 43 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> 
>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> new file mode 100644
>>> index 0000000..bb3580c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> @@ -0,0 +1,43 @@
>>> +twl4030_madc_battery
>>> +
>>> +Required properties:
>>> + - compatible : "ti,twl4030-madc-battery"
>>> + - capacity-uah : battery capacity in uAh
>> 
>> Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>> 
>>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>>> +     for charging calibration (see example)
>>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>>> +     for discharging calibration (see example)
>> 
>> Would "mV-to-capacity..." be more accurate? Also, would it make sense
> Again maybe mv but it can be added also later.
>> to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Temperature calibration should have already been done in the underlaying twl4030 iio driver.

Discharge rate is the real current flow reported in uA. Also reported by iio.

>> 
>> Thanks,
>>                                                                        Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
> [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104
> 
> BR,
> 
> marek
> 

BR,
Nikolaus

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 16.03.2015 um 22:20 schrieb Belisko Marek <marek.belisko@gmail.com>:

> On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>>> ---
>>> .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
>>> 1 file changed, 43 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> 
>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> new file mode 100644
>>> index 0000000..bb3580c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> @@ -0,0 +1,43 @@
>>> +twl4030_madc_battery
>>> +
>>> +Required properties:
>>> + - compatible : "ti,twl4030-madc-battery"
>>> + - capacity-uah : battery capacity in uAh
>> 
>> Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>> 
>>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>>> +     for charging calibration (see example)
>>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>>> +     for discharging calibration (see example)
>> 
>> Would "mV-to-capacity..." be more accurate? Also, would it make sense
> Again maybe mv but it can be added also later.
>> to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Temperature calibration should have already been done in the underlaying twl4030 iio driver.

Discharge rate is the real current flow reported in uA. Also reported by iio.

>> 
>> Thanks,
>>                                                                        Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
> [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104
> 
> BR,
> 
> marek
> 

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

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

Hi!

> >> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> new file mode 100644
> >> index 0000000..bb3580c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> @@ -0,0 +1,43 @@
> >> +twl4030_madc_battery
> >> +
> >> +Required properties:
> >> + - compatible : "ti,twl4030-madc-battery"
> >> + - capacity-uah : battery capacity in uAh
> >
> > Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.

Messing up SI units due to "convention" is _stupid_. Don't do it.

> > to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Well, conversion between Li-ion's voltage and state of charge at 0
current is well known:

    def percent(m, v):
    	u = 0.0387-(1.4523*(3.7835-v))
        if u < 0:
            return 0
          return (0.1966+math.sqrt(u))*100

And there's not much to calibrate there, and it should become library
helper function; there's no need to write it to every single dts.

The charge/discharge difference is due to internal battery resistance,
and Ohm's law. (Then, you should not need different values for
charging/discharging case.)

With your aproach, you'll get lower percentage when phone is under
load vs. idle. Taking internal resistance into account would give you
more precise readings. (Attached, old patch for zaurus shows the
needed computation).

And if you wanted even more precise readings... internal resistance
depends on temperature.

I guess this should go into library somewhere, because many machines
need similar code.

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

[-- Attachment #2: zbattery.10.diff --]
[-- Type: text/x-diff, Size: 15807 bytes --]

./drivers/power - ./drivers/power.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/Makefile ./drivers/power/Makefile
--- ./drivers/power.ofic/Makefile	2011-03-16 10:11:34.000000000 +0100
+++ ./drivers/power/Makefile	2011-04-29 15:12:14.000000000 +0200
@@ -19,7 +19,9 @@
 obj-$(CONFIG_BATTERY_PMU)	+= pmu_battery.o
 obj-$(CONFIG_BATTERY_OLPC)	+= olpc_battery.o
 obj-$(CONFIG_BATTERY_TOSA)	+= tosa_battery.o
+obj-m	+= spitz_battery.o
 obj-$(CONFIG_BATTERY_COLLIE)	+= collie_battery.o
+obj-m	+= spitz_battery.o
 obj-$(CONFIG_BATTERY_WM97XX)	+= wm97xx_battery.o
 obj-$(CONFIG_BATTERY_BQ20Z75)	+= bq20z75.o
 obj-$(CONFIG_BATTERY_BQ27x00)	+= bq27x00_battery.o
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/power_supply_sysfs.c ./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c	2011-02-02 10:54:32.000000000 +0100
+++ ./drivers/power/power_supply_sysfs.c	2011-04-29 15:02:07.000000000 +0200
@@ -40,7 +40,8 @@
 
 static ssize_t power_supply_show_property(struct device *dev,
 					  struct device_attribute *attr,
-					  char *buf) {
+					  char *buf)
+{
 	static char *type_text[] = {
 		"Battery", "UPS", "Mains", "USB",
 		"USB_DCP", "USB_CDP", "USB_ACA"
@@ -102,7 +103,8 @@
 
 static ssize_t power_supply_store_property(struct device *dev,
 					   struct device_attribute *attr,
-					   const char *buf, size_t count) {
+					   const char *buf, size_t count)
+{
 	ssize_t ret;
 	struct power_supply *psy = dev_get_drvdata(dev);
 	const ptrdiff_t off = attr - power_supply_attrs;
Only in ./drivers/power: spitz_battery.c
./drivers/video - ./drivers/video.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/video.ofic/pxafb.c ./drivers/video/pxafb.c
--- ./drivers/video.ofic/pxafb.c	2011-02-02 09:44:53.000000000 +0100
+++ ./drivers/video/pxafb.c	2011-04-29 14:50:27.000000000 +0200
@@ -1648,6 +1648,9 @@
 #endif
 
 #ifdef CONFIG_PM
+
+static struct pxafb_info *my_fbi;
+
 /*
  * Power management hooks.  Note that we won't be called from IRQ context,
  * unlike the blank functions above, so we may sleep.
@@ -1656,6 +1659,8 @@
 {
 	struct pxafb_info *fbi = dev_get_drvdata(dev);
 
+	my_fbi = fbi;
+
 	set_ctrlr_state(fbi, C_DISABLE_PM);
 	return 0;
 }
./arch/arm - ./arch/arm.ofic
Binary files ./arch/arm.ofic/boot/Image and ./arch/arm/boot/Image differ
Binary files ./arch/arm.ofic/boot/compressed/piggy.gzip and ./arch/arm/boot/compressed/piggy.gzip differ
Binary files ./arch/arm.ofic/boot/compressed/vmlinux and ./arch/arm/boot/compressed/vmlinux differ
Binary files ./arch/arm.ofic/boot/zImage and ./arch/arm/boot/zImage differ
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/corgi_pm.c ./arch/arm/mach-pxa/corgi_pm.c
--- ./arch/arm.ofic/mach-pxa/corgi_pm.c	2011-02-02 10:30:38.000000000 +0100
+++ ./arch/arm/mach-pxa/corgi_pm.c	2011-04-29 15:12:15.000000000 +0200
@@ -43,6 +43,92 @@
 	{ CORGI_GPIO_KEY_INT,	  GPIOF_IN, "Key Interrupt" },
 };
 
+static const struct battery_thresh corgi_battery_levels_acin[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 192,  45},
+	{ 191,  43},
+	{ 191,  40},
+	{ 190,  38},
+	{ 190,  35},
+	{ 189,  33},
+	{ 188,  30},
+	{ 187,  28},
+	{ 186,  25},
+	{ 185,  23},
+	{ 184,  20},
+	{ 183,  18},
+	{ 182,  15},
+	{ 181,  13},
+	{ 180,  10},
+	{ 179,   8},
+	{ 178,   5},
+	{   0,   0},
+};
+
+static const struct battery_thresh  corgi_battery_levels_noac[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 191,  45},
+	{ 190,  43},
+	{ 189,  40},
+	{ 188,  38},
+	{ 187,  35},
+	{ 186,  33},
+	{ 185,  30},
+	{ 184,  28},
+	{ 183,  25},
+	{ 182,  23},
+	{ 181,  20},
+	{ 180,  18},
+	{ 179,  15},
+	{ 178,  13},
+	{ 177,  10},
+	{ 176,   8},
+	{ 175,   5},
+	{   0,   0},
+};
+
 static void corgi_charger_init(void)
 {
 	gpio_request_array(ARRAY_AND_SIZE(charger_gpios));
@@ -173,7 +259,6 @@
 	.fatal_noacin_volt= SHARPSL_FATAL_NOACIN_VOLT,
 	.bat_levels       = 40,
 	.bat_levels_noac  = sharpsl_battery_levels_noac,
-	.bat_levels_acin  = sharpsl_battery_levels_acin,
 	.status_high_acin = 188,
 	.status_low_acin  = 178,
 	.status_high_noac = 185,
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/include/mach/sharpsl_pm.h ./arch/arm/mach-pxa/include/mach/sharpsl_pm.h
--- ./arch/arm.ofic/mach-pxa/include/mach/sharpsl_pm.h	2011-02-02 10:30:38.000000000 +0100
+++ ./arch/arm/mach-pxa/include/mach/sharpsl_pm.h	2011-04-29 15:18:19.000000000 +0200
@@ -110,4 +110,22 @@
 int sharpsl_pm_pxa_read_max1111(int channel);
 
 void corgi_lcd_limit_intensity(int limit);
+
+/*
+ * Constants
+ */
+#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
+#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
+#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
+#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
+
+#define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
+#define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_TEMP   10  /* 10 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT   10  /* 10 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_ACIN   10  /* 10 msec */
+#define SHARPSL_CHARGE_WAIT_TIME               15  /* 15 msec */
+#define SHARPSL_CHARGE_CO_CHECK_TIME           5   /* 5 msec */
+#define SHARPSL_CHARGE_RETRY_CNT               1   /* eqv. 10 min */
+
 #endif
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/sharpsl_pm.c ./arch/arm/mach-pxa/sharpsl_pm.c
--- ./arch/arm.ofic/mach-pxa/sharpsl_pm.c	2011-03-16 10:07:44.000000000 +0100
+++ ./arch/arm/mach-pxa/sharpsl_pm.c	2011-04-29 15:27:09.000000000 +0200
@@ -32,23 +32,6 @@
 #include <mach/sharpsl_pm.h>
 
 /*
- * Constants
- */
-#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
-#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
-#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
-#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
-
-#define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
-#define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_TEMP   10  /* 10 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT   10  /* 10 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_ACIN   10  /* 10 msec */
-#define SHARPSL_CHARGE_WAIT_TIME               15  /* 15 msec */
-#define SHARPSL_CHARGE_CO_CHECK_TIME           5   /* 5 msec */
-#define SHARPSL_CHARGE_RETRY_CNT               1   /* eqv. 10 min */
-
-/*
  * Prototypes
  */
 #ifdef CONFIG_PM
@@ -68,96 +51,32 @@
  * Variables
  */
 struct sharpsl_pm_status sharpsl_pm;
+EXPORT_SYMBOL(sharpsl_pm);
 static DECLARE_DELAYED_WORK(toggle_charger, sharpsl_charge_toggle);
 static DECLARE_DELAYED_WORK(sharpsl_bat, sharpsl_battery_thread);
 DEFINE_LED_TRIGGER(sharpsl_charge_led_trigger);
 
 
 
-struct battery_thresh sharpsl_battery_levels_acin[] = {
-	{ 213, 100},
-	{ 212,  98},
-	{ 211,  95},
-	{ 210,  93},
-	{ 209,  90},
-	{ 208,  88},
-	{ 207,  85},
-	{ 206,  83},
-	{ 205,  80},
-	{ 204,  78},
-	{ 203,  75},
-	{ 202,  73},
-	{ 201,  70},
-	{ 200,  68},
-	{ 199,  65},
-	{ 198,  63},
-	{ 197,  60},
-	{ 196,  58},
-	{ 195,  55},
-	{ 194,  53},
-	{ 193,  50},
-	{ 192,  48},
-	{ 192,  45},
-	{ 191,  43},
-	{ 191,  40},
-	{ 190,  38},
-	{ 190,  35},
-	{ 189,  33},
-	{ 188,  30},
-	{ 187,  28},
-	{ 186,  25},
-	{ 185,  23},
-	{ 184,  20},
-	{ 183,  18},
-	{ 182,  15},
-	{ 181,  13},
-	{ 180,  10},
-	{ 179,   8},
-	{ 178,   5},
-	{   0,   0},
-};
-
 struct battery_thresh sharpsl_battery_levels_noac[] = {
-	{ 213, 100},
-	{ 212,  98},
-	{ 211,  95},
-	{ 210,  93},
-	{ 209,  90},
-	{ 208,  88},
-	{ 207,  85},
-	{ 206,  83},
-	{ 205,  80},
-	{ 204,  78},
-	{ 203,  75},
-	{ 202,  73},
-	{ 201,  70},
-	{ 200,  68},
-	{ 199,  65},
-	{ 198,  63},
-	{ 197,  60},
-	{ 196,  58},
-	{ 195,  55},
-	{ 194,  53},
-	{ 193,  50},
-	{ 192,  48},
-	{ 191,  45},
-	{ 190,  43},
-	{ 189,  40},
-	{ 188,  38},
-	{ 187,  35},
-	{ 186,  33},
-	{ 185,  30},
-	{ 184,  28},
-	{ 183,  25},
-	{ 182,  23},
-	{ 181,  20},
-	{ 180,  18},
-	{ 179,  15},
-	{ 178,  13},
-	{ 177,  10},
-	{ 176,   8},
-	{ 175,   5},
-	{   0,   0},
+	{ 3980, 100 },
+	{ 3900, 95 },
+	{ 3860, 90 },
+	{ 3800, 85 },
+	{ 3760, 80 },
+	{ 3720, 74 },
+	{ 3680, 69 },
+	{ 3620, 65 },
+	{ 3570, 59 },
+	{ 3560, 55 },
+	{ 3550, 48 },
+	{ 3530, 45 },
+	{ 3510, 39 },
+	{ 3490, 33 },
+	{ 3470, 29 },
+	{ 3450, 23 },
+	{ 3410, 16 },
+	{    0, 0 },
 };
 
 /* MAX1111 Commands */
@@ -185,22 +104,71 @@
 	return max1111_read_channel(channel >> 1);
 }
 
-static int get_percentage(int voltage)
+
+typedef int milliamp_t;
+typedef int milliohm_t;
+typedef int millivolt_t;
+
+milliamp_t basic_current = 125;
+milliohm_t battery_resistance = 100;
+
+/* 422 seems to be suitable for very old, 1Ah battery.
+   2Ah battery probably has better resistance */
+
+/* Unfortunately, resistance depends on state of charge, current
+ * direction and temperature.
+ *
+ * Ouch, and dependency is actually _not_ too simple. It is lowest
+ * at 3.55V, very slowly rises at 4V (approximately linear dependency),
+ * and quickly rises towards 3.2V (in something exponential-looking).
+ *
+ * It is about same at 25Celsius and 40Celsius, and about 2.5x the value
+ * on 0Celsius, rising _very_ sharply.
+ *
+ * Li-ion should only be charged between 0 and 45 Celsius, and discharged
+ * between -20 and 60 celsius.
+ */
+
+extern int backlight_current;
+
+/* Positive values: current drawn from battery */
+milliamp_t battery_current(void)
+{
+	if (sharpsl_pm.charge_mode == CHRG_ON)
+		return 0;
+
+	return basic_current;
+}
+
+millivolt_t liion_internal_voltage(millivolt_t voltage, milliamp_t current_ma)
+{
+	return voltage + (battery_resistance * current_ma / 1000);
+}
+
+/* returns mV */
+millivolt_t liion_voltage(int adc)
+{
+	/* Thanks to Stanislav B. ADC has 3.3V as reference,
+	   is connected to battery over 47kOhm,
+	   and to ground over 100kOhm. */
+	return (adc * 147 * 33)/256;
+}
+
+static int get_percentage(int voltage_adc)
 {
 	int i = sharpsl_pm.machinfo->bat_levels - 1;
 	int bl_status = sharpsl_pm.machinfo->backlight_get_status ? sharpsl_pm.machinfo->backlight_get_status() : 0;
 	struct battery_thresh *thresh;
+	millivolt_t voltage = liion_voltage(voltage_adc);
 
-	if (sharpsl_pm.charge_mode == CHRG_ON)
-		thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_acin_bl : sharpsl_pm.machinfo->bat_levels_acin;
-	else
-		thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_noac_bl : sharpsl_pm.machinfo->bat_levels_noac;
+	thresh = sharpsl_pm.machinfo->bat_levels_noac;
 
 	while (i > 0 && (voltage > thresh[i].voltage))
 		i--;
 
 	return thresh[i].percentage;
 }
+EXPORT_SYMBOL(get_percentage);
 
 static int get_apm_status(int voltage)
 {
@@ -317,6 +285,8 @@
 
 static void sharpsl_charge_error(void)
 {
+	dev_warn(sharpsl_pm.dev, "Charger Error\n");
+
 	sharpsl_pm_led(SHARPSL_LED_ERROR);
 	sharpsl_pm.machinfo->charge(0);
 	sharpsl_pm.charge_mode = CHRG_ERROR;
@@ -513,8 +483,10 @@
 	val = get_select_val(buff);
 
 	dev_dbg(sharpsl_pm.dev, "Temperature: %d\n", val);
-	if (val > sharpsl_pm.machinfo->charge_on_temp) {
-		printk(KERN_WARNING "Not charging: temperature out of limits.\n");
+	/* FIXME: this should catch battery read errors, but we should
+	   probably avoid charging in <0C temperatures, too. */
+	if ((val < 0) || (val > sharpsl_pm.machinfo->charge_on_temp)) {
+		dev_warn(sharpsl_pm.dev, "Not charging: temperature %d out of limits.\n", val);
 		return -1;
 	}
 
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/spitz.c ./arch/arm/mach-pxa/spitz.c
--- ./arch/arm.ofic/mach-pxa/spitz.c	2011-03-16 10:07:44.000000000 +0100
+++ ./arch/arm/mach-pxa/spitz.c	2011-04-29 15:25:47.000000000 +0200
@@ -922,6 +922,15 @@
 #endif
 
 /******************************************************************************
+ * Battery
+ ******************************************************************************/
+
+static struct platform_device spitz_battery_device = {
+	.name	= "spitz-battery",
+	.id	= -1,
+};
+
+/******************************************************************************
  * Machine init
  ******************************************************************************/
 static void spitz_poweroff(void)
@@ -969,6 +978,7 @@
 	spitz_nor_init();
 	spitz_nand_init();
 	spitz_i2c_init();
+	platform_device_register(&spitz_battery_device);
 }
 
 static void __init spitz_fixup(struct machine_desc *desc,
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/spitz_pm.c ./arch/arm/mach-pxa/spitz_pm.c
--- ./arch/arm.ofic/mach-pxa/spitz_pm.c	2011-02-02 10:30:39.000000000 +0100
+++ ./arch/arm/mach-pxa/spitz_pm.c	2011-04-29 15:15:16.000000000 +0200
@@ -45,6 +45,93 @@
 	{ SPITZ_GPIO_CHRG_ON,	  GPIOF_OUT_INIT_LOW, "Charger On" },
 };
 
+static const struct battery_thresh spitz_battery_levels_acin[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 192,  45},
+	{ 191,  43},
+	{ 191,  40},
+	{ 190,  38},
+	{ 190,  35},
+	{ 189,  33},
+	{ 188,  30},
+	{ 187,  28},
+	{ 186,  25},
+	{ 185,  23},
+	{ 184,  20},
+	{ 183,  18},
+	{ 182,  15},
+	{ 181,  13},
+	{ 180,  10},
+	{ 179,   8},
+	{ 178,   5},
+	{   0,   0},
+};
+
+static const struct battery_thresh  spitz_battery_levels_noac[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 191,  45},
+	{ 190,  43},
+	{ 189,  40},
+	{ 188,  38},
+	{ 187,  35},
+	{ 186,  33},
+	{ 185,  30},
+	{ 184,  28},
+	{ 183,  25},
+	{ 182,  23},
+	{ 181,  20},
+	{ 180,  18},
+	{ 179,  15},
+	{ 178,  13},
+	{ 177,  10},
+	{ 176,   8},
+	{ 175,   5},
+	{   0,   0},
+};
+
+
 static void spitz_charger_init(void)
 {
 	gpio_request_array(ARRAY_AND_SIZE(spitz_charger_gpios));
@@ -192,6 +279,11 @@
 	}
 }
 
+int backlight_get_status(void)
+{
+	return 0;
+}
+
 struct sharpsl_charger_machinfo spitz_pm_machinfo = {
 	.init             = spitz_charger_init,
 	.exit             = NULL,
@@ -210,7 +302,7 @@
 	.charger_wakeup   = spitz_charger_wakeup,
 	.should_wakeup    = spitz_should_wakeup,
 #if defined(CONFIG_LCD_CORGI)
-	.backlight_limit = corgi_lcd_limit_intensity,
+	.backlight_limit  = corgi_lcd_limit_intensity,
 #endif
 	.charge_on_volt	  = SHARPSL_CHARGE_ON_VOLT,
 	.charge_on_temp	  = SHARPSL_CHARGE_ON_TEMP,
@@ -220,7 +312,6 @@
 	.fatal_noacin_volt= SHARPSL_FATAL_NOACIN_VOLT,
 	.bat_levels       = 40,
 	.bat_levels_noac  = sharpsl_battery_levels_noac,
-	.bat_levels_acin  = sharpsl_battery_levels_acin,
 	.status_high_acin = 188,
 	.status_low_acin  = 178,
 	.status_high_noac = 185,

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

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

Hi!

> >> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> new file mode 100644
> >> index 0000000..bb3580c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> @@ -0,0 +1,43 @@
> >> +twl4030_madc_battery
> >> +
> >> +Required properties:
> >> + - compatible : "ti,twl4030-madc-battery"
> >> + - capacity-uah : battery capacity in uAh
> >
> > Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.

Messing up SI units due to "convention" is _stupid_. Don't do it.

> > to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Well, conversion between Li-ion's voltage and state of charge at 0
current is well known:

    def percent(m, v):
    	u = 0.0387-(1.4523*(3.7835-v))
        if u < 0:
            return 0
          return (0.1966+math.sqrt(u))*100

And there's not much to calibrate there, and it should become library
helper function; there's no need to write it to every single dts.

The charge/discharge difference is due to internal battery resistance,
and Ohm's law. (Then, you should not need different values for
charging/discharging case.)

With your aproach, you'll get lower percentage when phone is under
load vs. idle. Taking internal resistance into account would give you
more precise readings. (Attached, old patch for zaurus shows the
needed computation).

And if you wanted even more precise readings... internal resistance
depends on temperature.

I guess this should go into library somewhere, because many machines
need similar code.

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

[-- Attachment #2: zbattery.10.diff --]
[-- Type: text/x-diff, Size: 15807 bytes --]

./drivers/power - ./drivers/power.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/Makefile ./drivers/power/Makefile
--- ./drivers/power.ofic/Makefile	2011-03-16 10:11:34.000000000 +0100
+++ ./drivers/power/Makefile	2011-04-29 15:12:14.000000000 +0200
@@ -19,7 +19,9 @@
 obj-$(CONFIG_BATTERY_PMU)	+= pmu_battery.o
 obj-$(CONFIG_BATTERY_OLPC)	+= olpc_battery.o
 obj-$(CONFIG_BATTERY_TOSA)	+= tosa_battery.o
+obj-m	+= spitz_battery.o
 obj-$(CONFIG_BATTERY_COLLIE)	+= collie_battery.o
+obj-m	+= spitz_battery.o
 obj-$(CONFIG_BATTERY_WM97XX)	+= wm97xx_battery.o
 obj-$(CONFIG_BATTERY_BQ20Z75)	+= bq20z75.o
 obj-$(CONFIG_BATTERY_BQ27x00)	+= bq27x00_battery.o
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/power_supply_sysfs.c ./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c	2011-02-02 10:54:32.000000000 +0100
+++ ./drivers/power/power_supply_sysfs.c	2011-04-29 15:02:07.000000000 +0200
@@ -40,7 +40,8 @@
 
 static ssize_t power_supply_show_property(struct device *dev,
 					  struct device_attribute *attr,
-					  char *buf) {
+					  char *buf)
+{
 	static char *type_text[] = {
 		"Battery", "UPS", "Mains", "USB",
 		"USB_DCP", "USB_CDP", "USB_ACA"
@@ -102,7 +103,8 @@
 
 static ssize_t power_supply_store_property(struct device *dev,
 					   struct device_attribute *attr,
-					   const char *buf, size_t count) {
+					   const char *buf, size_t count)
+{
 	ssize_t ret;
 	struct power_supply *psy = dev_get_drvdata(dev);
 	const ptrdiff_t off = attr - power_supply_attrs;
Only in ./drivers/power: spitz_battery.c
./drivers/video - ./drivers/video.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/video.ofic/pxafb.c ./drivers/video/pxafb.c
--- ./drivers/video.ofic/pxafb.c	2011-02-02 09:44:53.000000000 +0100
+++ ./drivers/video/pxafb.c	2011-04-29 14:50:27.000000000 +0200
@@ -1648,6 +1648,9 @@
 #endif
 
 #ifdef CONFIG_PM
+
+static struct pxafb_info *my_fbi;
+
 /*
  * Power management hooks.  Note that we won't be called from IRQ context,
  * unlike the blank functions above, so we may sleep.
@@ -1656,6 +1659,8 @@
 {
 	struct pxafb_info *fbi = dev_get_drvdata(dev);
 
+	my_fbi = fbi;
+
 	set_ctrlr_state(fbi, C_DISABLE_PM);
 	return 0;
 }
./arch/arm - ./arch/arm.ofic
Binary files ./arch/arm.ofic/boot/Image and ./arch/arm/boot/Image differ
Binary files ./arch/arm.ofic/boot/compressed/piggy.gzip and ./arch/arm/boot/compressed/piggy.gzip differ
Binary files ./arch/arm.ofic/boot/compressed/vmlinux and ./arch/arm/boot/compressed/vmlinux differ
Binary files ./arch/arm.ofic/boot/zImage and ./arch/arm/boot/zImage differ
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/corgi_pm.c ./arch/arm/mach-pxa/corgi_pm.c
--- ./arch/arm.ofic/mach-pxa/corgi_pm.c	2011-02-02 10:30:38.000000000 +0100
+++ ./arch/arm/mach-pxa/corgi_pm.c	2011-04-29 15:12:15.000000000 +0200
@@ -43,6 +43,92 @@
 	{ CORGI_GPIO_KEY_INT,	  GPIOF_IN, "Key Interrupt" },
 };
 
+static const struct battery_thresh corgi_battery_levels_acin[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 192,  45},
+	{ 191,  43},
+	{ 191,  40},
+	{ 190,  38},
+	{ 190,  35},
+	{ 189,  33},
+	{ 188,  30},
+	{ 187,  28},
+	{ 186,  25},
+	{ 185,  23},
+	{ 184,  20},
+	{ 183,  18},
+	{ 182,  15},
+	{ 181,  13},
+	{ 180,  10},
+	{ 179,   8},
+	{ 178,   5},
+	{   0,   0},
+};
+
+static const struct battery_thresh  corgi_battery_levels_noac[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 191,  45},
+	{ 190,  43},
+	{ 189,  40},
+	{ 188,  38},
+	{ 187,  35},
+	{ 186,  33},
+	{ 185,  30},
+	{ 184,  28},
+	{ 183,  25},
+	{ 182,  23},
+	{ 181,  20},
+	{ 180,  18},
+	{ 179,  15},
+	{ 178,  13},
+	{ 177,  10},
+	{ 176,   8},
+	{ 175,   5},
+	{   0,   0},
+};
+
 static void corgi_charger_init(void)
 {
 	gpio_request_array(ARRAY_AND_SIZE(charger_gpios));
@@ -173,7 +259,6 @@
 	.fatal_noacin_volt= SHARPSL_FATAL_NOACIN_VOLT,
 	.bat_levels       = 40,
 	.bat_levels_noac  = sharpsl_battery_levels_noac,
-	.bat_levels_acin  = sharpsl_battery_levels_acin,
 	.status_high_acin = 188,
 	.status_low_acin  = 178,
 	.status_high_noac = 185,
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/include/mach/sharpsl_pm.h ./arch/arm/mach-pxa/include/mach/sharpsl_pm.h
--- ./arch/arm.ofic/mach-pxa/include/mach/sharpsl_pm.h	2011-02-02 10:30:38.000000000 +0100
+++ ./arch/arm/mach-pxa/include/mach/sharpsl_pm.h	2011-04-29 15:18:19.000000000 +0200
@@ -110,4 +110,22 @@
 int sharpsl_pm_pxa_read_max1111(int channel);
 
 void corgi_lcd_limit_intensity(int limit);
+
+/*
+ * Constants
+ */
+#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
+#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
+#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
+#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
+
+#define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
+#define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_TEMP   10  /* 10 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT   10  /* 10 msec */
+#define SHARPSL_CHECK_BATTERY_WAIT_TIME_ACIN   10  /* 10 msec */
+#define SHARPSL_CHARGE_WAIT_TIME               15  /* 15 msec */
+#define SHARPSL_CHARGE_CO_CHECK_TIME           5   /* 5 msec */
+#define SHARPSL_CHARGE_RETRY_CNT               1   /* eqv. 10 min */
+
 #endif
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/sharpsl_pm.c ./arch/arm/mach-pxa/sharpsl_pm.c
--- ./arch/arm.ofic/mach-pxa/sharpsl_pm.c	2011-03-16 10:07:44.000000000 +0100
+++ ./arch/arm/mach-pxa/sharpsl_pm.c	2011-04-29 15:27:09.000000000 +0200
@@ -32,23 +32,6 @@
 #include <mach/sharpsl_pm.h>
 
 /*
- * Constants
- */
-#define SHARPSL_CHARGE_ON_TIME_INTERVAL        (msecs_to_jiffies(1*60*1000))  /* 1 min */
-#define SHARPSL_CHARGE_FINISH_TIME             (msecs_to_jiffies(10*60*1000)) /* 10 min */
-#define SHARPSL_BATCHK_TIME                    (msecs_to_jiffies(15*1000))    /* 15 sec */
-#define SHARPSL_BATCHK_TIME_SUSPEND            (60*10)                        /* 10 min */
-
-#define SHARPSL_WAIT_CO_TIME                   15  /* 15 sec */
-#define SHARPSL_WAIT_DISCHARGE_ON              100 /* 100 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_TEMP   10  /* 10 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_VOLT   10  /* 10 msec */
-#define SHARPSL_CHECK_BATTERY_WAIT_TIME_ACIN   10  /* 10 msec */
-#define SHARPSL_CHARGE_WAIT_TIME               15  /* 15 msec */
-#define SHARPSL_CHARGE_CO_CHECK_TIME           5   /* 5 msec */
-#define SHARPSL_CHARGE_RETRY_CNT               1   /* eqv. 10 min */
-
-/*
  * Prototypes
  */
 #ifdef CONFIG_PM
@@ -68,96 +51,32 @@
  * Variables
  */
 struct sharpsl_pm_status sharpsl_pm;
+EXPORT_SYMBOL(sharpsl_pm);
 static DECLARE_DELAYED_WORK(toggle_charger, sharpsl_charge_toggle);
 static DECLARE_DELAYED_WORK(sharpsl_bat, sharpsl_battery_thread);
 DEFINE_LED_TRIGGER(sharpsl_charge_led_trigger);
 
 
 
-struct battery_thresh sharpsl_battery_levels_acin[] = {
-	{ 213, 100},
-	{ 212,  98},
-	{ 211,  95},
-	{ 210,  93},
-	{ 209,  90},
-	{ 208,  88},
-	{ 207,  85},
-	{ 206,  83},
-	{ 205,  80},
-	{ 204,  78},
-	{ 203,  75},
-	{ 202,  73},
-	{ 201,  70},
-	{ 200,  68},
-	{ 199,  65},
-	{ 198,  63},
-	{ 197,  60},
-	{ 196,  58},
-	{ 195,  55},
-	{ 194,  53},
-	{ 193,  50},
-	{ 192,  48},
-	{ 192,  45},
-	{ 191,  43},
-	{ 191,  40},
-	{ 190,  38},
-	{ 190,  35},
-	{ 189,  33},
-	{ 188,  30},
-	{ 187,  28},
-	{ 186,  25},
-	{ 185,  23},
-	{ 184,  20},
-	{ 183,  18},
-	{ 182,  15},
-	{ 181,  13},
-	{ 180,  10},
-	{ 179,   8},
-	{ 178,   5},
-	{   0,   0},
-};
-
 struct battery_thresh sharpsl_battery_levels_noac[] = {
-	{ 213, 100},
-	{ 212,  98},
-	{ 211,  95},
-	{ 210,  93},
-	{ 209,  90},
-	{ 208,  88},
-	{ 207,  85},
-	{ 206,  83},
-	{ 205,  80},
-	{ 204,  78},
-	{ 203,  75},
-	{ 202,  73},
-	{ 201,  70},
-	{ 200,  68},
-	{ 199,  65},
-	{ 198,  63},
-	{ 197,  60},
-	{ 196,  58},
-	{ 195,  55},
-	{ 194,  53},
-	{ 193,  50},
-	{ 192,  48},
-	{ 191,  45},
-	{ 190,  43},
-	{ 189,  40},
-	{ 188,  38},
-	{ 187,  35},
-	{ 186,  33},
-	{ 185,  30},
-	{ 184,  28},
-	{ 183,  25},
-	{ 182,  23},
-	{ 181,  20},
-	{ 180,  18},
-	{ 179,  15},
-	{ 178,  13},
-	{ 177,  10},
-	{ 176,   8},
-	{ 175,   5},
-	{   0,   0},
+	{ 3980, 100 },
+	{ 3900, 95 },
+	{ 3860, 90 },
+	{ 3800, 85 },
+	{ 3760, 80 },
+	{ 3720, 74 },
+	{ 3680, 69 },
+	{ 3620, 65 },
+	{ 3570, 59 },
+	{ 3560, 55 },
+	{ 3550, 48 },
+	{ 3530, 45 },
+	{ 3510, 39 },
+	{ 3490, 33 },
+	{ 3470, 29 },
+	{ 3450, 23 },
+	{ 3410, 16 },
+	{    0, 0 },
 };
 
 /* MAX1111 Commands */
@@ -185,22 +104,71 @@
 	return max1111_read_channel(channel >> 1);
 }
 
-static int get_percentage(int voltage)
+
+typedef int milliamp_t;
+typedef int milliohm_t;
+typedef int millivolt_t;
+
+milliamp_t basic_current = 125;
+milliohm_t battery_resistance = 100;
+
+/* 422 seems to be suitable for very old, 1Ah battery.
+   2Ah battery probably has better resistance */
+
+/* Unfortunately, resistance depends on state of charge, current
+ * direction and temperature.
+ *
+ * Ouch, and dependency is actually _not_ too simple. It is lowest
+ * at 3.55V, very slowly rises at 4V (approximately linear dependency),
+ * and quickly rises towards 3.2V (in something exponential-looking).
+ *
+ * It is about same at 25Celsius and 40Celsius, and about 2.5x the value
+ * on 0Celsius, rising _very_ sharply.
+ *
+ * Li-ion should only be charged between 0 and 45 Celsius, and discharged
+ * between -20 and 60 celsius.
+ */
+
+extern int backlight_current;
+
+/* Positive values: current drawn from battery */
+milliamp_t battery_current(void)
+{
+	if (sharpsl_pm.charge_mode == CHRG_ON)
+		return 0;
+
+	return basic_current;
+}
+
+millivolt_t liion_internal_voltage(millivolt_t voltage, milliamp_t current_ma)
+{
+	return voltage + (battery_resistance * current_ma / 1000);
+}
+
+/* returns mV */
+millivolt_t liion_voltage(int adc)
+{
+	/* Thanks to Stanislav B. ADC has 3.3V as reference,
+	   is connected to battery over 47kOhm,
+	   and to ground over 100kOhm. */
+	return (adc * 147 * 33)/256;
+}
+
+static int get_percentage(int voltage_adc)
 {
 	int i = sharpsl_pm.machinfo->bat_levels - 1;
 	int bl_status = sharpsl_pm.machinfo->backlight_get_status ? sharpsl_pm.machinfo->backlight_get_status() : 0;
 	struct battery_thresh *thresh;
+	millivolt_t voltage = liion_voltage(voltage_adc);
 
-	if (sharpsl_pm.charge_mode == CHRG_ON)
-		thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_acin_bl : sharpsl_pm.machinfo->bat_levels_acin;
-	else
-		thresh = bl_status ? sharpsl_pm.machinfo->bat_levels_noac_bl : sharpsl_pm.machinfo->bat_levels_noac;
+	thresh = sharpsl_pm.machinfo->bat_levels_noac;
 
 	while (i > 0 && (voltage > thresh[i].voltage))
 		i--;
 
 	return thresh[i].percentage;
 }
+EXPORT_SYMBOL(get_percentage);
 
 static int get_apm_status(int voltage)
 {
@@ -317,6 +285,8 @@
 
 static void sharpsl_charge_error(void)
 {
+	dev_warn(sharpsl_pm.dev, "Charger Error\n");
+
 	sharpsl_pm_led(SHARPSL_LED_ERROR);
 	sharpsl_pm.machinfo->charge(0);
 	sharpsl_pm.charge_mode = CHRG_ERROR;
@@ -513,8 +483,10 @@
 	val = get_select_val(buff);
 
 	dev_dbg(sharpsl_pm.dev, "Temperature: %d\n", val);
-	if (val > sharpsl_pm.machinfo->charge_on_temp) {
-		printk(KERN_WARNING "Not charging: temperature out of limits.\n");
+	/* FIXME: this should catch battery read errors, but we should
+	   probably avoid charging in <0C temperatures, too. */
+	if ((val < 0) || (val > sharpsl_pm.machinfo->charge_on_temp)) {
+		dev_warn(sharpsl_pm.dev, "Not charging: temperature %d out of limits.\n", val);
 		return -1;
 	}
 
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/spitz.c ./arch/arm/mach-pxa/spitz.c
--- ./arch/arm.ofic/mach-pxa/spitz.c	2011-03-16 10:07:44.000000000 +0100
+++ ./arch/arm/mach-pxa/spitz.c	2011-04-29 15:25:47.000000000 +0200
@@ -922,6 +922,15 @@
 #endif
 
 /******************************************************************************
+ * Battery
+ ******************************************************************************/
+
+static struct platform_device spitz_battery_device = {
+	.name	= "spitz-battery",
+	.id	= -1,
+};
+
+/******************************************************************************
  * Machine init
  ******************************************************************************/
 static void spitz_poweroff(void)
@@ -969,6 +978,7 @@
 	spitz_nor_init();
 	spitz_nand_init();
 	spitz_i2c_init();
+	platform_device_register(&spitz_battery_device);
 }
 
 static void __init spitz_fixup(struct machine_desc *desc,
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/spitz_pm.c ./arch/arm/mach-pxa/spitz_pm.c
--- ./arch/arm.ofic/mach-pxa/spitz_pm.c	2011-02-02 10:30:39.000000000 +0100
+++ ./arch/arm/mach-pxa/spitz_pm.c	2011-04-29 15:15:16.000000000 +0200
@@ -45,6 +45,93 @@
 	{ SPITZ_GPIO_CHRG_ON,	  GPIOF_OUT_INIT_LOW, "Charger On" },
 };
 
+static const struct battery_thresh spitz_battery_levels_acin[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 192,  45},
+	{ 191,  43},
+	{ 191,  40},
+	{ 190,  38},
+	{ 190,  35},
+	{ 189,  33},
+	{ 188,  30},
+	{ 187,  28},
+	{ 186,  25},
+	{ 185,  23},
+	{ 184,  20},
+	{ 183,  18},
+	{ 182,  15},
+	{ 181,  13},
+	{ 180,  10},
+	{ 179,   8},
+	{ 178,   5},
+	{   0,   0},
+};
+
+static const struct battery_thresh  spitz_battery_levels_noac[] = {
+	{ 213, 100},
+	{ 212,  98},
+	{ 211,  95},
+	{ 210,  93},
+	{ 209,  90},
+	{ 208,  88},
+	{ 207,  85},
+	{ 206,  83},
+	{ 205,  80},
+	{ 204,  78},
+	{ 203,  75},
+	{ 202,  73},
+	{ 201,  70},
+	{ 200,  68},
+	{ 199,  65},
+	{ 198,  63},
+	{ 197,  60},
+	{ 196,  58},
+	{ 195,  55},
+	{ 194,  53},
+	{ 193,  50},
+	{ 192,  48},
+	{ 191,  45},
+	{ 190,  43},
+	{ 189,  40},
+	{ 188,  38},
+	{ 187,  35},
+	{ 186,  33},
+	{ 185,  30},
+	{ 184,  28},
+	{ 183,  25},
+	{ 182,  23},
+	{ 181,  20},
+	{ 180,  18},
+	{ 179,  15},
+	{ 178,  13},
+	{ 177,  10},
+	{ 176,   8},
+	{ 175,   5},
+	{   0,   0},
+};
+
+
 static void spitz_charger_init(void)
 {
 	gpio_request_array(ARRAY_AND_SIZE(spitz_charger_gpios));
@@ -192,6 +279,11 @@
 	}
 }
 
+int backlight_get_status(void)
+{
+	return 0;
+}
+
 struct sharpsl_charger_machinfo spitz_pm_machinfo = {
 	.init             = spitz_charger_init,
 	.exit             = NULL,
@@ -210,7 +302,7 @@
 	.charger_wakeup   = spitz_charger_wakeup,
 	.should_wakeup    = spitz_should_wakeup,
 #if defined(CONFIG_LCD_CORGI)
-	.backlight_limit = corgi_lcd_limit_intensity,
+	.backlight_limit  = corgi_lcd_limit_intensity,
 #endif
 	.charge_on_volt	  = SHARPSL_CHARGE_ON_VOLT,
 	.charge_on_temp	  = SHARPSL_CHARGE_ON_TEMP,
@@ -220,7 +312,6 @@
 	.fatal_noacin_volt= SHARPSL_FATAL_NOACIN_VOLT,
 	.bat_levels       = 40,
 	.bat_levels_noac  = sharpsl_battery_levels_noac,
-	.bat_levels_acin  = sharpsl_battery_levels_acin,
 	.status_high_acin = 188,
 	.status_low_acin  = 178,
 	.status_high_noac = 185,

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> new file mode 100644
> >> index 0000000..bb3580c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >> @@ -0,0 +1,43 @@
> >> +twl4030_madc_battery
> >> +
> >> +Required properties:
> >> + - compatible : "ti,twl4030-madc-battery"
> >> + - capacity-uah : battery capacity in uAh
> >
> > Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.

Messing up SI units due to "convention" is _stupid_. Don't do it.

> > to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Well, conversion between Li-ion's voltage and state of charge at 0
current is well known:

    def percent(m, v):
    	u = 0.0387-(1.4523*(3.7835-v))
        if u < 0:
            return 0
          return (0.1966+math.sqrt(u))*100

And there's not much to calibrate there, and it should become library
helper function; there's no need to write it to every single dts.

The charge/discharge difference is due to internal battery resistance,
and Ohm's law. (Then, you should not need different values for
charging/discharging case.)

With your aproach, you'll get lower percentage when phone is under
load vs. idle. Taking internal resistance into account would give you
more precise readings. (Attached, old patch for zaurus shows the
needed computation).

And if you wanted even more precise readings... internal resistance
depends on temperature.

I guess this should go into library somewhere, because many machines
need similar code.

								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: zbattery.10.diff
Type: text/x-diff
Size: 15807 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150317/debefd99/attachment.bin>

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

> 
> Temperature calibration should have already been done in the underlaying twl4030 iio driver.
> 
> Discharge rate is the real current flow reported in uA. Also
> reported by iio.

Ack, but there's rather severe temperature dependency of the lithium
battery, which you should take into account if you want to compute
"percentage charged".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

> 
> Temperature calibration should have already been done in the underlaying twl4030 iio driver.
> 
> Discharge rate is the real current flow reported in uA. Also
> reported by iio.

Ack, but there's rather severe temperature dependency of the lithium
battery, which you should take into account if you want to compute
"percentage charged".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> new file mode 100644
>>>> index 0000000..bb3580c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> @@ -0,0 +1,43 @@
>>>> +twl4030_madc_battery
>>>> +
>>>> +Required properties:
>>>> + - compatible : "ti,twl4030-madc-battery"
>>>> + - capacity-uah : battery capacity in uAh
>>> 
>>> Could we make it capacity-uAh ?
>> This name was suggested by Mark Rutland [1] and naming convention
>> should be all lowercase. There exists already bindings
>> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> 
> Messing up SI units due to "convention" is _stupid_. Don't do it.
> 
>>> to introduce coefficients for temperature and discharge rate?
>> What do you mean? Nothing like that is used in current driver why do
>> we need to add it?
> 
> Well, conversion between Li-ion's voltage and state of charge at 0
> current is well known:

We can’t measure at 0 current since the OMAP is driven from battery
and charger and may also draw some mA…

> 
>    def percent(m, v):
>    	u = 0.0387-(1.4523*(3.7835-v))
>        if u < 0:
>            return 0
>          return (0.1966+math.sqrt(u))*100
> 
> And there's not much to calibrate there, and it should become library
> helper function; there's no need to write it to every single dts.
> 
> The charge/discharge difference is due to internal battery resistance,
> and Ohm's law. (Then, you should not need different values for
> charging/discharging case.)

Yes, and that also depends on the board and battery type. So you always
need to specify some battery specific coefficient for that in the DT.

We simply did choose a table, because calculating the right coefficients
is more complex and getting the table values can easily be done from
running one full charge-discharge-charge cycle.

> 
> With your aproach, you'll get lower percentage when phone is under
> load vs. idle. Taking internal resistance into account would give you
> more precise readings. (Attached, old patch for zaurus shows the
> needed computation).

This is why we have a charging and a discharging table to compensate
for this effect.

> 
> And if you wanted even more precise readings... internal resistance
> depends on temperature.

We don’t necessarily know the real battery temperature.

> 
> I guess this should go into library somewhere, because many machines
> need similar code.

Is a library easier to maintain and handle than just a set of table values?

Anyways it ends up in a representation of a mapping function with two
input parameters (voltage and charge/discharge indication).

My proposal: keep it simple for everybody. And I can’t imagine something
easier than a mapping table.

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> new file mode 100644
>>>> index 0000000..bb3580c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> @@ -0,0 +1,43 @@
>>>> +twl4030_madc_battery
>>>> +
>>>> +Required properties:
>>>> + - compatible : "ti,twl4030-madc-battery"
>>>> + - capacity-uah : battery capacity in uAh
>>> 
>>> Could we make it capacity-uAh ?
>> This name was suggested by Mark Rutland [1] and naming convention
>> should be all lowercase. There exists already bindings
>> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> 
> Messing up SI units due to "convention" is _stupid_. Don't do it.
> 
>>> to introduce coefficients for temperature and discharge rate?
>> What do you mean? Nothing like that is used in current driver why do
>> we need to add it?
> 
> Well, conversion between Li-ion's voltage and state of charge at 0
> current is well known:

We can’t measure at 0 current since the OMAP is driven from battery
and charger and may also draw some mA…

> 
>    def percent(m, v):
>    	u = 0.0387-(1.4523*(3.7835-v))
>        if u < 0:
>            return 0
>          return (0.1966+math.sqrt(u))*100
> 
> And there's not much to calibrate there, and it should become library
> helper function; there's no need to write it to every single dts.
> 
> The charge/discharge difference is due to internal battery resistance,
> and Ohm's law. (Then, you should not need different values for
> charging/discharging case.)

Yes, and that also depends on the board and battery type. So you always
need to specify some battery specific coefficient for that in the DT.

We simply did choose a table, because calculating the right coefficients
is more complex and getting the table values can easily be done from
running one full charge-discharge-charge cycle.

> 
> With your aproach, you'll get lower percentage when phone is under
> load vs. idle. Taking internal resistance into account would give you
> more precise readings. (Attached, old patch for zaurus shows the
> needed computation).

This is why we have a charging and a discharging table to compensate
for this effect.

> 
> And if you wanted even more precise readings... internal resistance
> depends on temperature.

We don’t necessarily know the real battery temperature.

> 
> I guess this should go into library somewhere, because many machines
> need similar code.

Is a library easier to maintain and handle than just a set of table values?

Anyways it ends up in a representation of a mapping function with two
input parameters (voltage and charge/discharge indication).

My proposal: keep it simple for everybody. And I can’t imagine something
easier than a mapping table.

BR,
Nikolaus

--
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

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi,

Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> new file mode 100644
>>>> index 0000000..bb3580c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> @@ -0,0 +1,43 @@
>>>> +twl4030_madc_battery
>>>> +
>>>> +Required properties:
>>>> + - compatible : "ti,twl4030-madc-battery"
>>>> + - capacity-uah : battery capacity in uAh
>>> 
>>> Could we make it capacity-uAh ?
>> This name was suggested by Mark Rutland [1] and naming convention
>> should be all lowercase. There exists already bindings
>> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> 
> Messing up SI units due to "convention" is _stupid_. Don't do it.
> 
>>> to introduce coefficients for temperature and discharge rate?
>> What do you mean? Nothing like that is used in current driver why do
>> we need to add it?
> 
> Well, conversion between Li-ion's voltage and state of charge at 0
> current is well known:

We can?t measure at 0 current since the OMAP is driven from battery
and charger and may also draw some mA?

> 
>    def percent(m, v):
>    	u = 0.0387-(1.4523*(3.7835-v))
>        if u < 0:
>            return 0
>          return (0.1966+math.sqrt(u))*100
> 
> And there's not much to calibrate there, and it should become library
> helper function; there's no need to write it to every single dts.
> 
> The charge/discharge difference is due to internal battery resistance,
> and Ohm's law. (Then, you should not need different values for
> charging/discharging case.)

Yes, and that also depends on the board and battery type. So you always
need to specify some battery specific coefficient for that in the DT.

We simply did choose a table, because calculating the right coefficients
is more complex and getting the table values can easily be done from
running one full charge-discharge-charge cycle.

> 
> With your aproach, you'll get lower percentage when phone is under
> load vs. idle. Taking internal resistance into account would give you
> more precise readings. (Attached, old patch for zaurus shows the
> needed computation).

This is why we have a charging and a discharging table to compensate
for this effect.

> 
> And if you wanted even more precise readings... internal resistance
> depends on temperature.

We don?t necessarily know the real battery temperature.

> 
> I guess this should go into library somewhere, because many machines
> need similar code.

Is a library easier to maintain and handle than just a set of table values?

Anyways it ends up in a representation of a mapping function with two
input parameters (voltage and charge/discharge indication).

My proposal: keep it simple for everybody. And I can?t imagine something
easier than a mapping table.

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:48 schrieb Pavel Machek <pavel@ucw.cz>:

>> 
>> Temperature calibration should have already been done in the underlaying twl4030 iio driver.
>> 
>> Discharge rate is the real current flow reported in uA. Also
>> reported by iio.
> 
> Ack, but there's rather severe temperature dependency of the lithium
> battery, which you should take into account if you want to compute
> “percentage charged".

We just want to estimate it as good as possible. 5-10% is sufficient
and better than no value at all (which is what you get without this
driver).

And, we just convert the (existing) driver from non-DT to DT and to use
iio, so we do not want to change the inner logic what it does and how it
works.

BR,
Nikolaus

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:48 schrieb Pavel Machek <pavel@ucw.cz>:

>> 
>> Temperature calibration should have already been done in the underlaying twl4030 iio driver.
>> 
>> Discharge rate is the real current flow reported in uA. Also
>> reported by iio.
> 
> Ack, but there's rather severe temperature dependency of the lithium
> battery, which you should take into account if you want to compute
> ?percentage charged".

We just want to estimate it as good as possible. 5-10% is sufficient
and better than no value at all (which is what you get without this
driver).

And, we just convert the (existing) driver from non-DT to DT and to use
iio, so we do not want to change the inner logic what it does and how it
works.

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> new file mode 100644
>>>> index 0000000..bb3580c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> @@ -0,0 +1,43 @@
>>>> +twl4030_madc_battery
>>>> +
>>>> +Required properties:
>>>> + - compatible : "ti,twl4030-madc-battery"
>>>> + - capacity-uah : battery capacity in uAh
>>> 
>>> Could we make it capacity-uAh ?
>> This name was suggested by Mark Rutland [1] and naming convention
>> should be all lowercase. There exists already bindings
>> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> 
> Messing up SI units due to "convention" is _stupid_. Don't do it.
> 
>>> to introduce coefficients for temperature and discharge rate?
>> What do you mean? Nothing like that is used in current driver why do
>> we need to add it?
> 
> Well, conversion between Li-ion's voltage and state of charge at 0
> current is well known:
> 
>    def percent(m, v):
>    	u = 0.0387-(1.4523*(3.7835-v))
>        if u < 0:
>            return 0
>          return (0.1966+math.sqrt(u))*100

I forgot to ask: does the kernel have a sqrt() function?
> 
> And there's not much to calibrate there, and it should become library
> helper function; there's no need to write it to every single dts.
> 
> The charge/discharge difference is due to internal battery resistance,
> and Ohm's law. (Then, you should not need different values for
> charging/discharging case.)
> 
> With your aproach, you'll get lower percentage when phone is under
> load vs. idle. Taking internal resistance into account would give you
> more precise readings. (Attached, old patch for zaurus shows the
> needed computation).
> 
> And if you wanted even more precise readings... internal resistance
> depends on temperature.
> 
> I guess this should go into library somewhere, because many machines
> need similar code.
> 
> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> <zbattery.10.diff>

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> new file mode 100644
>>>> index 0000000..bb3580c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>>> @@ -0,0 +1,43 @@
>>>> +twl4030_madc_battery
>>>> +
>>>> +Required properties:
>>>> + - compatible : "ti,twl4030-madc-battery"
>>>> + - capacity-uah : battery capacity in uAh
>>> 
>>> Could we make it capacity-uAh ?
>> This name was suggested by Mark Rutland [1] and naming convention
>> should be all lowercase. There exists already bindings
>> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> 
> Messing up SI units due to "convention" is _stupid_. Don't do it.
> 
>>> to introduce coefficients for temperature and discharge rate?
>> What do you mean? Nothing like that is used in current driver why do
>> we need to add it?
> 
> Well, conversion between Li-ion's voltage and state of charge at 0
> current is well known:
> 
>    def percent(m, v):
>    	u = 0.0387-(1.4523*(3.7835-v))
>        if u < 0:
>            return 0
>          return (0.1966+math.sqrt(u))*100

I forgot to ask: does the kernel have a sqrt() function?
> 
> And there's not much to calibrate there, and it should become library
> helper function; there's no need to write it to every single dts.
> 
> The charge/discharge difference is due to internal battery resistance,
> and Ohm's law. (Then, you should not need different values for
> charging/discharging case.)
> 
> With your aproach, you'll get lower percentage when phone is under
> load vs. idle. Taking internal resistance into account would give you
> more precise readings. (Attached, old patch for zaurus shows the
> needed computation).
> 
> And if you wanted even more precise readings... internal resistance
> depends on temperature.
> 
> I guess this should go into library somewhere, because many machines
> need similar code.
> 
> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> <zbattery.10.diff>

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Tue 2015-03-17 10:07:12, Dr. H. Nikolaus Schaller wrote:
> 
> Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> > Hi!
> > 
> >>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >>>> new file mode 100644
> >>>> index 0000000..bb3580c
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >>>> @@ -0,0 +1,43 @@
> >>>> +twl4030_madc_battery
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible : "ti,twl4030-madc-battery"
> >>>> + - capacity-uah : battery capacity in uAh
> >>> 
> >>> Could we make it capacity-uAh ?
> >> This name was suggested by Mark Rutland [1] and naming convention
> >> should be all lowercase. There exists already bindings
> >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> > 
> > Messing up SI units due to "convention" is _stupid_. Don't do it.
> > 
> >>> to introduce coefficients for temperature and discharge rate?
> >> What do you mean? Nothing like that is used in current driver why do
> >> we need to add it?
> > 
> > Well, conversion between Li-ion's voltage and state of charge at 0
> > current is well known:
> > 
> >    def percent(m, v):
> >    	u = 0.0387-(1.4523*(3.7835-v))
> >        if u < 0:
> >            return 0
> >          return (0.1966+math.sqrt(u))*100
> 
> I forgot to ask: does the kernel have a sqrt() function?

This could be good enough.

https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/fix-sqrt.patch

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

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Tue 2015-03-17 10:07:12, Dr. H. Nikolaus Schaller wrote:
> 
> Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> > Hi!
> > 
> >>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >>>> new file mode 100644
> >>>> index 0000000..bb3580c
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> >>>> @@ -0,0 +1,43 @@
> >>>> +twl4030_madc_battery
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible : "ti,twl4030-madc-battery"
> >>>> + - capacity-uah : battery capacity in uAh
> >>> 
> >>> Could we make it capacity-uAh ?
> >> This name was suggested by Mark Rutland [1] and naming convention
> >> should be all lowercase. There exists already bindings
> >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
> > 
> > Messing up SI units due to "convention" is _stupid_. Don't do it.
> > 
> >>> to introduce coefficients for temperature and discharge rate?
> >> What do you mean? Nothing like that is used in current driver why do
> >> we need to add it?
> > 
> > Well, conversion between Li-ion's voltage and state of charge at 0
> > current is well known:
> > 
> >    def percent(m, v):
> >    	u = 0.0387-(1.4523*(3.7835-v))
> >        if u < 0:
> >            return 0
> >          return (0.1966+math.sqrt(u))*100
> 
> I forgot to ask: does the kernel have a sqrt() function?

This could be good enough.

https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/fix-sqrt.patch

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

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >>> to introduce coefficients for temperature and discharge rate?
> >> What do you mean? Nothing like that is used in current driver why do
> >> we need to add it?
> > 
> > Well, conversion between Li-ion's voltage and state of charge at 0
> > current is well known:
> 
> We can’t measure at 0 current since the OMAP is driven from battery
> and charger and may also draw some mA…

Yes, but you know how many mA you are taking just now. So if you knew
the internal resistance, you could compute the voltage at 0
current. (And it should also work during charging, as long as you know
how much current is going in.)

> >    def percent(m, v):
> >    	u = 0.0387-(1.4523*(3.7835-v))
> >        if u < 0:
> >            return 0
> >          return (0.1966+math.sqrt(u))*100
> > 
> > And there's not much to calibrate there, and it should become library
> > helper function; there's no need to write it to every single dts.
> > 
> > The charge/discharge difference is due to internal battery resistance,
> > and Ohm's law. (Then, you should not need different values for
> > charging/discharging case.)
> 
> Yes, and that also depends on the board and battery type. So you always
> need to specify some battery specific coefficient for that in the DT.

Yes, and that coefficient should be internal battery resistance ;-).

> We simply did choose a table, because calculating the right coefficients
> is more complex and getting the table values can easily be done from
> running one full charge-discharge-charge cycle.

Well.. One set of coefficients would be kind of ok. But you are doing
two, because it really depends on current, not charge/discharge. So
why not do it right, for all currents...?

> > With your aproach, you'll get lower percentage when phone is under
> > load vs. idle. Taking internal resistance into account would give you
> > more precise readings. (Attached, old patch for zaurus shows the
> > needed computation).
> 
> This is why we have a charging and a discharging table to compensate
> for this effect.

Yes, but there's very different current during "idle" phone and during
call (for example). So yes, you are compensating for different current
during charge and discharge, but it is possible to do better.

> > I guess this should go into library somewhere, because many machines
> > need similar code.
> 
> Is a library easier to maintain and handle than just a set of table
> values?

I think so, yes, because otherwise you need a set of tables for each
machine.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >>> to introduce coefficients for temperature and discharge rate?
> >> What do you mean? Nothing like that is used in current driver why do
> >> we need to add it?
> > 
> > Well, conversion between Li-ion's voltage and state of charge at 0
> > current is well known:
> 
> We can’t measure at 0 current since the OMAP is driven from battery
> and charger and may also draw some mA…

Yes, but you know how many mA you are taking just now. So if you knew
the internal resistance, you could compute the voltage at 0
current. (And it should also work during charging, as long as you know
how much current is going in.)

> >    def percent(m, v):
> >    	u = 0.0387-(1.4523*(3.7835-v))
> >        if u < 0:
> >            return 0
> >          return (0.1966+math.sqrt(u))*100
> > 
> > And there's not much to calibrate there, and it should become library
> > helper function; there's no need to write it to every single dts.
> > 
> > The charge/discharge difference is due to internal battery resistance,
> > and Ohm's law. (Then, you should not need different values for
> > charging/discharging case.)
> 
> Yes, and that also depends on the board and battery type. So you always
> need to specify some battery specific coefficient for that in the DT.

Yes, and that coefficient should be internal battery resistance ;-).

> We simply did choose a table, because calculating the right coefficients
> is more complex and getting the table values can easily be done from
> running one full charge-discharge-charge cycle.

Well.. One set of coefficients would be kind of ok. But you are doing
two, because it really depends on current, not charge/discharge. So
why not do it right, for all currents...?

> > With your aproach, you'll get lower percentage when phone is under
> > load vs. idle. Taking internal resistance into account would give you
> > more precise readings. (Attached, old patch for zaurus shows the
> > needed computation).
> 
> This is why we have a charging and a discharging table to compensate
> for this effect.

Yes, but there's very different current during "idle" phone and during
call (for example). So yes, you are compensating for different current
during charge and discharge, but it is possible to do better.

> > I guess this should go into library somewhere, because many machines
> > need similar code.
> 
> Is a library easier to maintain and handle than just a set of table
> values?

I think so, yes, because otherwise you need a set of tables for each
machine.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >>> to introduce coefficients for temperature and discharge rate?
> >> What do you mean? Nothing like that is used in current driver why do
> >> we need to add it?
> > 
> > Well, conversion between Li-ion's voltage and state of charge at 0
> > current is well known:
> 
> We can?t measure at 0 current since the OMAP is driven from battery
> and charger and may also draw some mA?

Yes, but you know how many mA you are taking just now. So if you knew
the internal resistance, you could compute the voltage at 0
current. (And it should also work during charging, as long as you know
how much current is going in.)

> >    def percent(m, v):
> >    	u = 0.0387-(1.4523*(3.7835-v))
> >        if u < 0:
> >            return 0
> >          return (0.1966+math.sqrt(u))*100
> > 
> > And there's not much to calibrate there, and it should become library
> > helper function; there's no need to write it to every single dts.
> > 
> > The charge/discharge difference is due to internal battery resistance,
> > and Ohm's law. (Then, you should not need different values for
> > charging/discharging case.)
> 
> Yes, and that also depends on the board and battery type. So you always
> need to specify some battery specific coefficient for that in the DT.

Yes, and that coefficient should be internal battery resistance ;-).

> We simply did choose a table, because calculating the right coefficients
> is more complex and getting the table values can easily be done from
> running one full charge-discharge-charge cycle.

Well.. One set of coefficients would be kind of ok. But you are doing
two, because it really depends on current, not charge/discharge. So
why not do it right, for all currents...?

> > With your aproach, you'll get lower percentage when phone is under
> > load vs. idle. Taking internal resistance into account would give you
> > more precise readings. (Attached, old patch for zaurus shows the
> > needed computation).
> 
> This is why we have a charging and a discharging table to compensate
> for this effect.

Yes, but there's very different current during "idle" phone and during
call (for example). So yes, you are compensating for different current
during charge and discharge, but it is possible to do better.

> > I guess this should go into library somewhere, because many machines
> > need similar code.
> 
> Is a library easier to maintain and handle than just a set of table
> values?

I think so, yes, because otherwise you need a set of tables for each
machine.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 11:37 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>> to introduce coefficients for temperature and discharge rate?
>>>> What do you mean? Nothing like that is used in current driver why do
>>>> we need to add it?
>>> 
>>> Well, conversion between Li-ion's voltage and state of charge at 0
>>> current is well known:
>> 
>> We can’t measure at 0 current since the OMAP is driven from battery
>> and charger and may also draw some mA…
> 
> Yes, but you know how many mA you are taking just now. So if you knew
> the internal resistance, you could compute the voltage at 0
> current. (And it should also work during charging, as long as you know
> how much current is going in.)

As far as I understand the twl4030 charger and MADC it is not possible to
separate these values. It is only reporting the inflow from charger to
battery + system. So you don’t know how many mA are supplying the system
and how many mA are left over for charging.

You can only assume how much the system is drawing while running (something
between 50 and 600 mA but this depends on system activities, power state
of peripherald and e.g. backlight being switched on).

I think your basic assumption that we know any time how many mA the system
is taking is not given.

> 
>>>   def percent(m, v):
>>>   	u = 0.0387-(1.4523*(3.7835-v))
>>>       if u < 0:
>>>           return 0
>>>         return (0.1966+math.sqrt(u))*100
>>> 
>>> And there's not much to calibrate there, and it should become library
>>> helper function; there's no need to write it to every single dts.
>>> 
>>> The charge/discharge difference is due to internal battery resistance,
>>> and Ohm's law. (Then, you should not need different values for
>>> charging/discharging case.)
>> 
>> Yes, and that also depends on the board and battery type. So you always
>> need to specify some battery specific coefficient for that in the DT.
> 
> Yes, and that coefficient should be internal battery resistance ;-).

But where do you know this value from to write it into a DT file?
Usually you can’t measure it easily and for some batteries you don’t have
a data sheet.

Contrary, the calibration curves can easily be measured on the device
(assuming that the charge level decreases/increases linearly over time
between Full and Empty).

I tend to make software easy to use for the user (developer of a board support
package) of a driver, not theoretically correct or mathematically elegant.

> 
>> We simply did choose a table, because calculating the right coefficients
>> is more complex and getting the table values can easily be done from
>> running one full charge-discharge-charge cycle.
> 
> Well.. One set of coefficients would be kind of ok. But you are doing
> two, because it really depends on current, not charge/discharge. So
> why not do it right, for all currents…?

Because the right solution for all these issues is to use a fuel gauge chip
(bq27xxx).

This driver is just for systems where the hardware designer did forget
(or did not want to spend money) for such a chip, but user space
expects some /sys/class/power_supply indication (e.g. Android/Replicant).

The missing optimal precision is something we can live with.

> 
>>> With your aproach, you'll get lower percentage when phone is under
>>> load vs. idle. Taking internal resistance into account would give you
>>> more precise readings. (Attached, old patch for zaurus shows the
>>> needed computation).
>> 
>> This is why we have a charging and a discharging table to compensate
>> for this effect.
> 
> Yes, but there's very different current during "idle" phone and during
> call (for example). So yes, you are compensating for different current
> during charge and discharge, but it is possible to do better.

I am not convinced that it can be really done better, considering the
limitations of the twl4030 circuits, and I doubt that it is worth the efforts
of doing it better.

> 
>>> I guess this should go into library somewhere, because many machines
>>> need similar code.
>> 
>> Is a library easier to maintain and handle than just a set of table
>> values?
> 
> I think so, yes, because otherwise you need a set of tables for each
> machine.

Yes, but what is the problem? We have different device trees for each
machine anyways. And as soon as they differ in battery characteristics
the coefficients for your calculation have to be defined for each machine.

So someone has to write in some DT values (difficult to understand
and derive coefficients or two simple mapping tables).

To me it looks as if you want to make it a 100% solution while I am happy
with the 80% solution, which already exists as a platform data driver and
just want to get it back into DT based boards.

So I would suggest that Mareks patches to make the platform data
driver DT compatible are applied first, and you are invited to submit a
technically better solution for testing on real hardware.

BR,
Nikolaus

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 11:37 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>> to introduce coefficients for temperature and discharge rate?
>>>> What do you mean? Nothing like that is used in current driver why do
>>>> we need to add it?
>>> 
>>> Well, conversion between Li-ion's voltage and state of charge at 0
>>> current is well known:
>> 
>> We can?t measure at 0 current since the OMAP is driven from battery
>> and charger and may also draw some mA?
> 
> Yes, but you know how many mA you are taking just now. So if you knew
> the internal resistance, you could compute the voltage at 0
> current. (And it should also work during charging, as long as you know
> how much current is going in.)

As far as I understand the twl4030 charger and MADC it is not possible to
separate these values. It is only reporting the inflow from charger to
battery + system. So you don?t know how many mA are supplying the system
and how many mA are left over for charging.

You can only assume how much the system is drawing while running (something
between 50 and 600 mA but this depends on system activities, power state
of peripherald and e.g. backlight being switched on).

I think your basic assumption that we know any time how many mA the system
is taking is not given.

> 
>>>   def percent(m, v):
>>>   	u = 0.0387-(1.4523*(3.7835-v))
>>>       if u < 0:
>>>           return 0
>>>         return (0.1966+math.sqrt(u))*100
>>> 
>>> And there's not much to calibrate there, and it should become library
>>> helper function; there's no need to write it to every single dts.
>>> 
>>> The charge/discharge difference is due to internal battery resistance,
>>> and Ohm's law. (Then, you should not need different values for
>>> charging/discharging case.)
>> 
>> Yes, and that also depends on the board and battery type. So you always
>> need to specify some battery specific coefficient for that in the DT.
> 
> Yes, and that coefficient should be internal battery resistance ;-).

But where do you know this value from to write it into a DT file?
Usually you can?t measure it easily and for some batteries you don?t have
a data sheet.

Contrary, the calibration curves can easily be measured on the device
(assuming that the charge level decreases/increases linearly over time
between Full and Empty).

I tend to make software easy to use for the user (developer of a board support
package) of a driver, not theoretically correct or mathematically elegant.

> 
>> We simply did choose a table, because calculating the right coefficients
>> is more complex and getting the table values can easily be done from
>> running one full charge-discharge-charge cycle.
> 
> Well.. One set of coefficients would be kind of ok. But you are doing
> two, because it really depends on current, not charge/discharge. So
> why not do it right, for all currents??

Because the right solution for all these issues is to use a fuel gauge chip
(bq27xxx).

This driver is just for systems where the hardware designer did forget
(or did not want to spend money) for such a chip, but user space
expects some /sys/class/power_supply indication (e.g. Android/Replicant).

The missing optimal precision is something we can live with.

> 
>>> With your aproach, you'll get lower percentage when phone is under
>>> load vs. idle. Taking internal resistance into account would give you
>>> more precise readings. (Attached, old patch for zaurus shows the
>>> needed computation).
>> 
>> This is why we have a charging and a discharging table to compensate
>> for this effect.
> 
> Yes, but there's very different current during "idle" phone and during
> call (for example). So yes, you are compensating for different current
> during charge and discharge, but it is possible to do better.

I am not convinced that it can be really done better, considering the
limitations of the twl4030 circuits, and I doubt that it is worth the efforts
of doing it better.

> 
>>> I guess this should go into library somewhere, because many machines
>>> need similar code.
>> 
>> Is a library easier to maintain and handle than just a set of table
>> values?
> 
> I think so, yes, because otherwise you need a set of tables for each
> machine.

Yes, but what is the problem? We have different device trees for each
machine anyways. And as soon as they differ in battery characteristics
the coefficients for your calculation have to be defined for each machine.

So someone has to write in some DT values (difficult to understand
and derive coefficients or two simple mapping tables).

To me it looks as if you want to make it a 100% solution while I am happy
with the 80% solution, which already exists as a platform data driver and
just want to get it back into DT based boards.

So I would suggest that Mareks patches to make the platform data
driver DT compatible are applied first, and you are invited to submit a
technically better solution for testing on real hardware.

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >>>>> to introduce coefficients for temperature and discharge rate?
> >>>> What do you mean? Nothing like that is used in current driver why do
> >>>> we need to add it?
> >>> 
> >>> Well, conversion between Li-ion's voltage and state of charge at 0
> >>> current is well known:
> >> 
> >> We can’t measure at 0 current since the OMAP is driven from battery
> >> and charger and may also draw some mA…
> > 
> > Yes, but you know how many mA you are taking just now. So if you knew
> > the internal resistance, you could compute the voltage at 0
> > current. (And it should also work during charging, as long as you know
> > how much current is going in.)
> 
> As far as I understand the twl4030 charger and MADC it is not possible to
> separate these values. It is only reporting the inflow from charger to
> battery + system. So you don’t know how many mA are supplying the system
> and how many mA are left over for charging.
> 
> You can only assume how much the system is drawing while running (something
> between 50 and 600 mA but this depends on system activities, power state
> of peripherald and e.g. backlight being switched on).
> 
> I think your basic assumption that we know any time how many mA the system
> is taking is not given.

So.. you won't be able to get exact value while charging, but you
get one while discharging, which is what really matters...?

> > Yes, and that coefficient should be internal battery resistance ;-).
> 
> But where do you know this value from to write it into a DT file?
> Usually you can’t measure it easily and for some batteries you don’t have
> a data sheet.
> 
> Contrary, the calibration curves can easily be measured on the device
> (assuming that the charge level decreases/increases linearly over time
> between Full and Empty).

If you can copy it from the data sheet, that's the easiest option. If
not, you should be able to easily compute it from the charge/discharge
curves or from measured voltage at different loads.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

Hi!

> >>>>> to introduce coefficients for temperature and discharge rate?
> >>>> What do you mean? Nothing like that is used in current driver why do
> >>>> we need to add it?
> >>> 
> >>> Well, conversion between Li-ion's voltage and state of charge at 0
> >>> current is well known:
> >> 
> >> We can?t measure at 0 current since the OMAP is driven from battery
> >> and charger and may also draw some mA?
> > 
> > Yes, but you know how many mA you are taking just now. So if you knew
> > the internal resistance, you could compute the voltage at 0
> > current. (And it should also work during charging, as long as you know
> > how much current is going in.)
> 
> As far as I understand the twl4030 charger and MADC it is not possible to
> separate these values. It is only reporting the inflow from charger to
> battery + system. So you don?t know how many mA are supplying the system
> and how many mA are left over for charging.
> 
> You can only assume how much the system is drawing while running (something
> between 50 and 600 mA but this depends on system activities, power state
> of peripherald and e.g. backlight being switched on).
> 
> I think your basic assumption that we know any time how many mA the system
> is taking is not given.

So.. you won't be able to get exact value while charging, but you
get one while discharging, which is what really matters...?

> > Yes, and that coefficient should be internal battery resistance ;-).
> 
> But where do you know this value from to write it into a DT file?
> Usually you can?t measure it easily and for some batteries you don?t have
> a data sheet.
> 
> Contrary, the calibration curves can easily be measured on the device
> (assuming that the charge level decreases/increases linearly over time
> between Full and Empty).

If you can copy it from the data sheet, that's the easiest option. If
not, you should be able to easily compute it from the charge/discharge
curves or from measured voltage at different loads.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 14:59 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>>>> to introduce coefficients for temperature and discharge rate?
>>>>>> What do you mean? Nothing like that is used in current driver why do
>>>>>> we need to add it?
>>>>> 
>>>>> Well, conversion between Li-ion's voltage and state of charge at 0
>>>>> current is well known:
>>>> 
>>>> We can’t measure at 0 current since the OMAP is driven from battery
>>>> and charger and may also draw some mA…
>>> 
>>> Yes, but you know how many mA you are taking just now. So if you knew
>>> the internal resistance, you could compute the voltage at 0
>>> current. (And it should also work during charging, as long as you know
>>> how much current is going in.)
>> 
>> As far as I understand the twl4030 charger and MADC it is not possible to
>> separate these values. It is only reporting the inflow from charger to
>> battery + system. So you don’t know how many mA are supplying the system
>> and how many mA are left over for charging.
>> 
>> You can only assume how much the system is drawing while running (something
>> between 50 and 600 mA but this depends on system activities, power state
>> of peripherald and e.g. backlight being switched on).
>> 
>> I think your basic assumption that we know any time how many mA the system
>> is taking is not given.
> 
> So.. you won't be able to get exact value while charging, but you
> get one while discharging, which is what really matters…?

Is it the same during charging?

And, as we already discussed it depends on the situation.

In addition, GSM power consumption runs in bursts and I don’t know if the sample
rate of the MADC is good enough to track that correctly.

> 
>>> Yes, and that coefficient should be internal battery resistance ;-).
>> 
>> But where do you know this value from to write it into a DT file?
>> Usually you can’t measure it easily and for some batteries you don’t have
>> a data sheet.
>> 
>> Contrary, the calibration curves can easily be measured on the device
>> (assuming that the charge level decreases/increases linearly over time
>> between Full and Empty).
> 
> If you can copy it from the data sheet, that's the easiest option. If
> not, you should be able to easily compute it from the charge/discharge
> curves or from measured voltage at different loads.

Well, this again assumes that you can generate/control different loads
easily (e.g. turn on/off this and that peripheral) to check the voltage
drop. Sounds good in theory, but I don’t want to do it in practice to
derive this parameter.

And, don’t forget that the MADC signals are nosiy and don’t have the
best precision. So it is likely that you get wrong values.

As said, I think it is not worth the effort around the imperfect twl4030/MADC
charging system.

If someone wants precise data, that is what fuel gauge chips are good for.
And we already have drivers for them.

BR,
Nikolaus

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 14:59 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>>>> to introduce coefficients for temperature and discharge rate?
>>>>>> What do you mean? Nothing like that is used in current driver why do
>>>>>> we need to add it?
>>>>> 
>>>>> Well, conversion between Li-ion's voltage and state of charge at 0
>>>>> current is well known:
>>>> 
>>>> We can’t measure at 0 current since the OMAP is driven from battery
>>>> and charger and may also draw some mA…
>>> 
>>> Yes, but you know how many mA you are taking just now. So if you knew
>>> the internal resistance, you could compute the voltage at 0
>>> current. (And it should also work during charging, as long as you know
>>> how much current is going in.)
>> 
>> As far as I understand the twl4030 charger and MADC it is not possible to
>> separate these values. It is only reporting the inflow from charger to
>> battery + system. So you don’t know how many mA are supplying the system
>> and how many mA are left over for charging.
>> 
>> You can only assume how much the system is drawing while running (something
>> between 50 and 600 mA but this depends on system activities, power state
>> of peripherald and e.g. backlight being switched on).
>> 
>> I think your basic assumption that we know any time how many mA the system
>> is taking is not given.
> 
> So.. you won't be able to get exact value while charging, but you
> get one while discharging, which is what really matters…?

Is it the same during charging?

And, as we already discussed it depends on the situation.

In addition, GSM power consumption runs in bursts and I don’t know if the sample
rate of the MADC is good enough to track that correctly.

> 
>>> Yes, and that coefficient should be internal battery resistance ;-).
>> 
>> But where do you know this value from to write it into a DT file?
>> Usually you can’t measure it easily and for some batteries you don’t have
>> a data sheet.
>> 
>> Contrary, the calibration curves can easily be measured on the device
>> (assuming that the charge level decreases/increases linearly over time
>> between Full and Empty).
> 
> If you can copy it from the data sheet, that's the easiest option. If
> not, you should be able to easily compute it from the charge/discharge
> curves or from measured voltage at different loads.

Well, this again assumes that you can generate/control different loads
easily (e.g. turn on/off this and that peripheral) to check the voltage
drop. Sounds good in theory, but I don’t want to do it in practice to
derive this parameter.

And, don’t forget that the MADC signals are nosiy and don’t have the
best precision. So it is likely that you get wrong values.

As said, I think it is not worth the effort around the imperfect twl4030/MADC
charging system.

If someone wants precise data, that is what fuel gauge chips are good for.
And we already have drivers for them.

BR,
Nikolaus

--
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

[PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 17.03.2015 um 14:59 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>>>> to introduce coefficients for temperature and discharge rate?
>>>>>> What do you mean? Nothing like that is used in current driver why do
>>>>>> we need to add it?
>>>>> 
>>>>> Well, conversion between Li-ion's voltage and state of charge at 0
>>>>> current is well known:
>>>> 
>>>> We can?t measure at 0 current since the OMAP is driven from battery
>>>> and charger and may also draw some mA?
>>> 
>>> Yes, but you know how many mA you are taking just now. So if you knew
>>> the internal resistance, you could compute the voltage at 0
>>> current. (And it should also work during charging, as long as you know
>>> how much current is going in.)
>> 
>> As far as I understand the twl4030 charger and MADC it is not possible to
>> separate these values. It is only reporting the inflow from charger to
>> battery + system. So you don?t know how many mA are supplying the system
>> and how many mA are left over for charging.
>> 
>> You can only assume how much the system is drawing while running (something
>> between 50 and 600 mA but this depends on system activities, power state
>> of peripherald and e.g. backlight being switched on).
>> 
>> I think your basic assumption that we know any time how many mA the system
>> is taking is not given.
> 
> So.. you won't be able to get exact value while charging, but you
> get one while discharging, which is what really matters??

Is it the same during charging?

And, as we already discussed it depends on the situation.

In addition, GSM power consumption runs in bursts and I don?t know if the sample
rate of the MADC is good enough to track that correctly.

> 
>>> Yes, and that coefficient should be internal battery resistance ;-).
>> 
>> But where do you know this value from to write it into a DT file?
>> Usually you can?t measure it easily and for some batteries you don?t have
>> a data sheet.
>> 
>> Contrary, the calibration curves can easily be measured on the device
>> (assuming that the charge level decreases/increases linearly over time
>> between Full and Empty).
> 
> If you can copy it from the data sheet, that's the easiest option. If
> not, you should be able to easily compute it from the charge/discharge
> curves or from measured voltage at different loads.

Well, this again assumes that you can generate/control different loads
easily (e.g. turn on/off this and that peripheral) to check the voltage
drop. Sounds good in theory, but I don?t want to do it in practice to
derive this parameter.

And, don?t forget that the MADC signals are nosiy and don?t have the
best precision. So it is likely that you get wrong values.

As said, I think it is not worth the effort around the imperfect twl4030/MADC
charging system.

If someone wants precise data, that is what fuel gauge chips are good for.
And we already have drivers for them.

BR,
Nikolaus