[RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Matti Vaittinen]

ROHM BD70528 PMIC includes battery charger block. Support charger
staus queries and doing few basic settings like input current limit
and charging current.

Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
 drivers/power/supply/Kconfig           |   9 +
 drivers/power/supply/Makefile          |   1 +
 drivers/power/supply/bd70528-charger.c | 670 +++++++++++++++++++++++++++++++++
 3 files changed, 680 insertions(+)
 create mode 100644 drivers/power/supply/bd70528-charger.c

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index e901b9879e7e..903c97a67bf0 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -660,4 +660,13 @@ config FUEL_GAUGE_SC27XX
 	 Say Y here to enable support for fuel gauge with SC27XX
 	 PMIC chips.
 
+config CHARGER_BD70528
+	tristate "ROHM bd70528 charger driver"
+	depends on MFD_ROHM_BD70528
+	default n
+	help
+	 Say Y here to enable support for getting battery status
+	 information and altering charger configurations from charger
+	 block of the ROHM BD70528 Power Management IC.
+
 endif # POWER_SUPPLY
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index b731c2a9b695..c60387b04bfa 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_AXP288_CHARGER)	+= axp288_charger.o
 obj-$(CONFIG_CHARGER_CROS_USBPD)	+= cros_usbpd-charger.o
 obj-$(CONFIG_CHARGER_SC2731)	+= sc2731_charger.o
 obj-$(CONFIG_FUEL_GAUGE_SC27XX)	+= sc27xx_fuel_gauge.o
+obj-$(CONFIG_CHARGER_BD70528)	+= bd70528-charger.o
diff --git a/drivers/power/supply/bd70528-charger.c b/drivers/power/supply/bd70528-charger.c
new file mode 100644
index 000000000000..ede8744bd6b1
--- /dev/null
+++ b/drivers/power/supply/bd70528-charger.c
@@ -0,0 +1,670 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2018 ROHM Semiconductors
+//
+// power-supply driver for ROHM BD70528 PMIC
+
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/mfd/rohm-bd70528.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+
+#define CHG_STAT_SUSPEND	0x0
+#define CHG_STAT_TRICKLE	0x1
+#define CHG_STAT_FAST		0x3
+#define CHG_STAT_TOPOFF		0xe
+#define CHG_STAT_DONE		0xf
+#define CHG_STAT_OTP_TRICKLE	0x10
+#define CHG_STAT_OTP_FAST	0x11
+#define CHG_STAT_OTP_DONE	0x12
+#define CHG_STAT_TSD_TRICKLE	0x20
+#define CHG_STAT_TSD_FAST	0x21
+#define CHG_STAT_TSD_TOPOFF	0x22
+#define CHG_STAT_BAT_ERR	0x7f
+
+static const char *bd70528_charger_model = "BD70528";
+static const char *bd70528_charger_manufacturer = "ROHM Semiconductors";
+
+#define BD_ERR_IRQ_HND(_name_, _wrn_)					\
+static irqreturn_t bd0528_##_name_##_interrupt(int irq, void *arg)	\
+{									\
+	struct power_supply *psy = (struct power_supply *)arg;		\
+									\
+	power_supply_changed(psy);					\
+	dev_err(&psy->dev, (_wrn_));					\
+									\
+	return IRQ_HANDLED;						\
+}
+
+#define BD_INFO_IRQ_HND(_name_, _wrn_)					\
+static irqreturn_t bd0528_##_name_##_interrupt(int irq, void *arg)	\
+{									\
+	struct power_supply *psy = (struct power_supply *)arg;		\
+									\
+	power_supply_changed(psy);					\
+	dev_dbg(&psy->dev, (_wrn_));					\
+									\
+	return IRQ_HANDLED;						\
+}
+
+#define BD_IRQ_HND(_name_) bd0528_##_name_##_interrupt
+
+BD_ERR_IRQ_HND(BAT_OV_DET, "Battery overvoltage detected\n");
+BD_ERR_IRQ_HND(DBAT_DET, "Dead battery detected\n");
+BD_ERR_IRQ_HND(COLD_DET, "Battery cold\n");
+BD_ERR_IRQ_HND(HOT_DET, "Battery hot\n");
+BD_ERR_IRQ_HND(CHG_TSD, "Charger thermal shutdown\n");
+BD_ERR_IRQ_HND(DCIN2_OV_DET, "DCIN2 overvoltage detected\n");
+
+BD_INFO_IRQ_HND(BAT_OV_RES, "Battery voltage back to normal\n");
+BD_INFO_IRQ_HND(COLD_RES, "Battery temperature back to normal\n");
+BD_INFO_IRQ_HND(HOT_RES, "Battery temperature back to normal\n");
+BD_INFO_IRQ_HND(BAT_RMV, "Battery removed\n");
+BD_INFO_IRQ_HND(BAT_DET, "Battery detected\n");
+BD_INFO_IRQ_HND(DCIN2_OV_RES, "DCIN2 voltage back to normal\n");
+BD_INFO_IRQ_HND(DCIN2_RMV, "DCIN2 removed\n");
+BD_INFO_IRQ_HND(DCIN2_DET, "DCIN2 detected\n");
+BD_INFO_IRQ_HND(DCIN1_RMV, "DCIN1 removed\n");
+BD_INFO_IRQ_HND(DCIN1_DET, "DCIN1 detected\n");
+
+struct irq_name_pair {
+	const char *n;
+	irqreturn_t (*h)(int irq, void *arg);
+};
+
+static int bd70528_get_irqs(struct platform_device *pdev,
+			    struct bd70528 *bd70528)
+{
+	int irq, i, ret;
+	unsigned int mask;
+	struct irq_name_pair bd70528_chg_irqs[] = {
+		{ .n = "bd70528-bat-ov-res", .h = BD_IRQ_HND(BAT_OV_RES) },
+		{ .n = "bd70528-bat-ov-det", .h = BD_IRQ_HND(BAT_OV_DET) },
+		{ .n = "bd70528-bat-dead", .h = BD_IRQ_HND(DBAT_DET) },
+		{ .n = "bd70528-bat-warmed", .h = BD_IRQ_HND(COLD_RES) },
+		{ .n = "bd70528-bat-cold", .h = BD_IRQ_HND(COLD_DET) },
+		{ .n = "bd70528-bat-cooled", .h = BD_IRQ_HND(HOT_RES) },
+		{ .n = "bd70528-bat-hot", .h = BD_IRQ_HND(HOT_DET) },
+		{ .n = "bd70528-chg-tshd", .h = BD_IRQ_HND(CHG_TSD) },
+		{ .n = "bd70528-bat-removed", .h = BD_IRQ_HND(BAT_RMV) },
+		{ .n = "bd70528-bat-detected", .h = BD_IRQ_HND(BAT_DET) },
+		{ .n = "bd70528-dcin2-ov-res", .h = BD_IRQ_HND(DCIN2_OV_RES) },
+		{ .n = "bd70528-dcin2-ov-det", .h = BD_IRQ_HND(DCIN2_OV_DET) },
+		{ .n = "bd70528-dcin2-removed", .h = BD_IRQ_HND(DCIN2_RMV) },
+		{ .n = "bd70528-dcin2-detected", .h = BD_IRQ_HND(DCIN2_DET) },
+		{ .n = "bd70528-dcin1-removed", .h = BD_IRQ_HND(DCIN1_RMV) },
+		{ .n = "bd70528-dcin1-detected", .h = BD_IRQ_HND(DCIN1_DET) },
+	};
+
+	for (i = 0; i < ARRAY_SIZE(bd70528_chg_irqs); i++) {
+		irq = platform_get_irq_byname(pdev, bd70528_chg_irqs[i].n);
+		if (irq < 0) {
+			dev_err(&pdev->dev, "Bad IRQ information for %s (%d)\n",
+				bd70528_chg_irqs[i].n, irq);
+			return irq;
+		}
+		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+						bd70528_chg_irqs[i].h,
+						IRQF_ONESHOT,
+						bd70528_chg_irqs[i].n, bd70528);
+
+		if (ret)
+			return ret;
+	}
+	/*
+	 * BD70528 irq controller is not touching the main mask register.
+	 * So enable the charger block interrupts at main level. We can just
+	 * leave them enabled as irq-controller should disable irqs
+	 * from sub-registers when IRQ is disabled or freed.
+	 */
+	mask = BD70528_REG_INT_BAT1_MASK | BD70528_REG_INT_BAT2_MASK;
+	ret = regmap_update_bits(bd70528->chip.regmap,
+				 BD70528_REG_INT_MAIN_MASK, mask, 0);
+	if (ret)
+		dev_err(&pdev->dev, "Failed to enable charger IRQs\n");
+
+	return ret;
+}
+
+static int bd70528_get_charger_status(struct bd70528 *bd70528, int *val)
+{
+	int ret;
+	unsigned int v;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_CURR_STAT, &v);
+	if (ret) {
+		dev_err(bd70528->chip.dev, "Charger state read failure %d\n",
+			ret);
+		return ret;
+	}
+
+	switch (v & BD70528_MASK_CHG_STAT) {
+	case CHG_STAT_SUSPEND:
+	/* Maybe we should check the CHG_TTRI_EN? */
+	case CHG_STAT_OTP_TRICKLE:
+	case CHG_STAT_OTP_FAST:
+	case CHG_STAT_OTP_DONE:
+	case CHG_STAT_TSD_TRICKLE:
+	case CHG_STAT_TSD_FAST:
+	case CHG_STAT_TSD_TOPOFF:
+	case CHG_STAT_BAT_ERR:
+		*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+		break;
+	case CHG_STAT_DONE:
+		*val = POWER_SUPPLY_STATUS_FULL;
+		break;
+	case CHG_STAT_TRICKLE:
+	case CHG_STAT_FAST:
+	case CHG_STAT_TOPOFF:
+		*val = POWER_SUPPLY_STATUS_CHARGING;
+		break;
+	default:
+		*val = POWER_SUPPLY_STATUS_UNKNOWN;
+		break;
+	}
+
+	return 0;
+}
+
+static int bd70528_get_charge_type(struct bd70528 *bd70528, int *val)
+{
+	int ret;
+	unsigned int v;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_CURR_STAT, &v);
+	if (ret) {
+		dev_err(bd70528->chip.dev, "Charger state read failure %d\n",
+			ret);
+		return ret;
+	}
+
+	switch (v & BD70528_MASK_CHG_STAT) {
+	case CHG_STAT_TRICKLE:
+		*val = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+		break;
+	case CHG_STAT_FAST:
+	case CHG_STAT_TOPOFF:
+		*val = POWER_SUPPLY_CHARGE_TYPE_FAST;
+		break;
+	case CHG_STAT_DONE:
+	case CHG_STAT_SUSPEND:
+	/* Maybe we should check the CHG_TTRI_EN? */
+	case CHG_STAT_OTP_TRICKLE:
+	case CHG_STAT_OTP_FAST:
+	case CHG_STAT_OTP_DONE:
+	case CHG_STAT_TSD_TRICKLE:
+	case CHG_STAT_TSD_FAST:
+	case CHG_STAT_TSD_TOPOFF:
+	case CHG_STAT_BAT_ERR:
+		*val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+		break;
+	default:
+		*val = POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
+		break;
+	}
+
+	return 0;
+}
+
+static int bd70528_get_battery_health(struct bd70528 *bd70528, int *val)
+{
+	int ret;
+	unsigned int v;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_BAT_STAT, &v);
+	if (ret) {
+		dev_err(bd70528->chip.dev, "Battery state read failure %d\n",
+			ret);
+		return ret;
+	}
+	/* No battery? */
+	if (!(v & BD70528_MASK_CHG_BAT_DETECT))
+		*val = POWER_SUPPLY_HEALTH_DEAD;
+	else if (v & BD70528_MASK_CHG_BAT_OVERVOLT)
+		*val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+	else if (v & BD70528_MASK_CHG_BAT_TIMER)
+		*val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+	else
+		*val = POWER_SUPPLY_HEALTH_GOOD;
+
+	return 0;
+}
+
+static int bd70528_get_online(struct bd70528 *bd70528, int *val)
+{
+	int ret;
+	unsigned int v;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_IN_STAT, &v);
+	if (ret) {
+		dev_err(bd70528->chip.dev, "DC1 IN state read failure %d\n",
+			ret);
+		return ret;
+	}
+
+	*val = (v & BD70528_MASK_CHG_DCIN1_UVLO) ? 1 : 0;
+
+	return 0;
+}
+
+static int bd70528_get_present(struct bd70528 *bd70528, int *val)
+{
+	int ret;
+	unsigned int v;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_BAT_STAT, &v);
+	if (ret) {
+		dev_err(bd70528->chip.dev, "Battery state read failure %d\n",
+			ret);
+		return ret;
+	}
+
+	*val = (v & BD70528_MASK_CHG_BAT_DETECT) ? 1 : 0;
+
+	return 0;
+}
+
+struct linear_range {
+	int min;
+	int step;
+	int vals;
+	int low_sel;
+};
+
+struct linear_range current_limit_ranges[] = {
+	{
+		.min = 5,
+		.step = 1,
+		.vals = 36,
+		.low_sel = 0,
+	},
+	{
+		.min = 40,
+		.step = 5,
+		.vals = 5,
+		.low_sel = 0x23,
+	},
+	{
+		.min = 60,
+		.step = 20,
+		.vals = 8,
+		.low_sel = 0x27,
+	},
+	{
+		.min = 200,
+		.step = 50,
+		.vals = 7,
+		.low_sel = 0x2e,
+	}
+};
+
+/*
+ * BD70528 would support setting and getting own charge current/
+ * voltage for low temperatures. The driver currently only reads
+ * the charge current at room temperature. We do set both though.
+ */
+struct linear_range warm_charge_curr[] = {
+	{
+		.min = 10,
+		.step = 10,
+		.vals = 20,
+		.low_sel = 0,
+	},
+	{
+		.min = 200,
+		.step = 25,
+		.vals = 13,
+		.low_sel = 0x13,
+	},
+};
+
+/*
+ * Cold charge current selectors are identical to warm charge current
+ * selectors. The difference is that only smaller currents are available
+ * at cold charge range.
+ */
+#define MAX_COLD_CHG_CURR_SEL 0x15
+#define MAX_WARM_CHG_CURR_SEL 0x1f
+#define MIN_CHG_CURR_SEL 0x0
+
+static int find_value_for_selector_low(struct linear_range *r, int selectors,
+				       unsigned int sel, unsigned int *val)
+{
+	int i;
+
+	for (i = 0; i < selectors; i++) {
+		if (r[i].low_sel <= sel && r[i].low_sel + r[i].vals >= sel) {
+			*val = r[i].min + (sel - r[i].low_sel) * r[i].step;
+			return 0;
+		}
+
+	}
+	return -EINVAL;
+}
+
+/*
+ * For BD70528 voltage/current limits we happily accept any value which
+ * belongs the range. We could check if value matching the selector is
+ * desired by computing the range min + (sel - sel_low) * range step - but
+ * I guess it is enough if we use voltage/current which is closest (below)
+ * the requested?
+ */
+static int find_selector_for_value_low(struct linear_range *r, int selectors,
+				       unsigned int val, unsigned int *sel,
+				       bool *found)
+{
+	int i;
+	int ret = -EINVAL;
+
+	*found = false;
+	for (i = 0; i < selectors; i++) {
+		if (r[i].min <= val) {
+			if (r[i].min + r[i].step * r[i].vals >= val) {
+				*found = true;
+				*sel = r[i].low_sel + (val - r[i].min) /
+				       r[i].step;
+				ret = 0;
+				break;
+			}
+			/*
+			 * If the range max is smaller than requested
+			 * we can set the max supported value from range
+			 */
+			*sel = r[i].low_sel + r[i].vals;
+			ret = 0;
+		}
+	}
+	return ret;
+}
+
+static int get_charge_current(struct bd70528 *bd70528, int *ma)
+{
+	unsigned int sel;
+	int ret;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_CHG_CURR_WARM,
+			  &sel);
+	if (ret) {
+		dev_err(bd70528->chip.dev,
+			"Charge current reading failed (%d)\n", ret);
+		return ret;
+	}
+
+	sel &= BD70528_MASK_CHG_CHG_CURR;
+
+	ret = find_value_for_selector_low(&warm_charge_curr[0],
+					  ARRAY_SIZE(warm_charge_curr), sel,
+					  ma);
+	if (ret) {
+		dev_err(bd70528->chip.dev,
+			"Unknown charge current value 0x%x\n",
+			sel);
+	}
+
+	return ret;
+}
+
+static int get_current_limit(struct bd70528 *bd70528, int *ma)
+{
+	unsigned int sel;
+	int ret;
+
+	ret = regmap_read(bd70528->chip.regmap, BD70528_REG_CHG_DCIN_ILIM,
+			  &sel);
+
+	if (ret) {
+		dev_err(bd70528->chip.dev,
+			"Input current limit reading failed (%d)\n", ret);
+		return ret;
+	}
+
+	sel &= BD70528_MASK_CHG_DCIN_ILIM;
+
+	ret = find_value_for_selector_low(&current_limit_ranges[0],
+					  ARRAY_SIZE(current_limit_ranges), sel,
+					  ma);
+
+	if (ret) {
+		/* Unspecified values mean 500 mA */
+		*ma = 500;
+	}
+	return 0;
+}
+
+static enum power_supply_property bd70528_charger_props[] = {
+	POWER_SUPPLY_PROP_STATUS,
+	POWER_SUPPLY_PROP_CHARGE_TYPE,
+	POWER_SUPPLY_PROP_HEALTH,
+	POWER_SUPPLY_PROP_PRESENT,
+	POWER_SUPPLY_PROP_ONLINE,
+	POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
+	POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+	POWER_SUPPLY_PROP_MODEL_NAME,
+	POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
+static int bd70528_charger_get_property(struct power_supply *psy,
+					enum power_supply_property psp,
+					union power_supply_propval *val)
+{
+	struct bd70528 *bd70528 = power_supply_get_drvdata(psy);
+	int ret = 0;
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_STATUS:
+		return bd70528_get_charger_status(bd70528, &val->intval);
+	case POWER_SUPPLY_PROP_CHARGE_TYPE:
+		return bd70528_get_charge_type(bd70528, &val->intval);
+	case POWER_SUPPLY_PROP_HEALTH:
+		return bd70528_get_battery_health(bd70528, &val->intval);
+	case POWER_SUPPLY_PROP_PRESENT:
+		return bd70528_get_present(bd70528, &val->intval);
+	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+		ret = get_current_limit(bd70528, &val->intval);
+		val->intval *= 1000;
+		return ret;
+	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+		ret = get_charge_current(bd70528, &val->intval);
+		val->intval *= 1000;
+		return ret;
+	case POWER_SUPPLY_PROP_ONLINE:
+		return bd70528_get_online(bd70528, &val->intval);
+	case POWER_SUPPLY_PROP_MODEL_NAME:
+		val->strval = bd70528_charger_model;
+		return 0;
+	case POWER_SUPPLY_PROP_MANUFACTURER:
+		val->strval = bd70528_charger_manufacturer;
+		return 0;
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int bd70528_prop_is_writable(struct power_supply *psy,
+				    enum power_supply_property psp)
+{
+	switch (psp) {
+	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+		return 1;
+	default:
+		break;
+	}
+	return 0;
+}
+
+
+
+static int set_charge_current(struct bd70528 *bd70528, int ma)
+{
+	unsigned int reg;
+	int ret = 0, tmpret;
+	bool found;
+
+	if (ma > 500) {
+		dev_warn(bd70528->chip.dev,
+			 "Requested charge current %u exceed maximum (500mA)\n",
+			 ma);
+		reg = MAX_WARM_CHG_CURR_SEL;
+		goto set;
+	}
+	if (ma < 10) {
+		dev_err(bd70528->chip.dev,
+			"Requested charge current %u smaller than min (10mA)\n",
+			 ma);
+		reg = MIN_CHG_CURR_SEL;
+		ret = -EINVAL;
+		goto set;
+	}
+
+	ret = find_selector_for_value_low(&warm_charge_curr[0],
+					  ARRAY_SIZE(warm_charge_curr), ma,
+					  &reg, &found);
+
+	if (!found) {
+		/* There was a gap in supported values and we hit it */
+		dev_warn(bd70528->chip.dev,
+			 "Unsupported charge current %u mA\n", ma);
+	}
+set:
+
+	tmpret = regmap_update_bits(bd70528->chip.regmap,
+				    BD70528_REG_CHG_CHG_CURR_WARM,
+				    BD70528_MASK_CHG_CHG_CURR, reg);
+	if (tmpret)
+		dev_err(bd70528->chip.dev,
+			"Charge current write failure (%d)\n", tmpret);
+
+	if (reg > MAX_COLD_CHG_CURR_SEL)
+		reg = MAX_COLD_CHG_CURR_SEL;
+
+	if (!tmpret)
+		tmpret = regmap_update_bits(bd70528->chip.regmap,
+					    BD70528_REG_CHG_CHG_CURR_COLD,
+					    BD70528_MASK_CHG_CHG_CURR, reg);
+
+	if (!ret)
+		ret = tmpret;
+
+	return ret;
+}
+
+#define MAX_CURR_LIMIT_SEL 0x34
+#define MIN_CURR_LIMIT_SEL 0x0
+
+static int set_current_limit(struct bd70528 *bd70528, int ma)
+{
+	unsigned int reg;
+	int ret = 0, tmpret;
+	bool found;
+
+	if (ma > 500) {
+		dev_warn(bd70528->chip.dev,
+			 "Requested current limit %u exceed maximum (500mA)\n",
+			 ma);
+		reg = MAX_CURR_LIMIT_SEL;
+		goto set;
+	}
+	if (ma < 5) {
+		dev_err(bd70528->chip.dev,
+			"Requested current limit %u smaller than min (5mA)\n",
+			ma);
+		reg = MIN_CURR_LIMIT_SEL;
+		ret = -EINVAL;
+		goto set;
+	}
+
+	ret = find_selector_for_value_low(&current_limit_ranges[0],
+					  ARRAY_SIZE(current_limit_ranges), ma,
+					  &reg, &found);
+	if (!found) {
+		/* There was a gap in supported values and we hit it ?*/
+		dev_warn(bd70528->chip.dev, "Unsupported current limit %umA\n",
+			 ma);
+	}
+
+set:
+	tmpret = regmap_update_bits(bd70528->chip.regmap,
+				    BD70528_REG_CHG_DCIN_ILIM,
+				    BD70528_MASK_CHG_DCIN_ILIM, reg);
+
+	if (!ret)
+		ret = tmpret;
+
+	return ret;
+}
+
+static int bd70528_charger_set_property(struct power_supply *psy,
+					enum power_supply_property psp,
+					const union power_supply_propval *val)
+{
+	struct bd70528 *bd70528 = power_supply_get_drvdata(psy);
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+		return set_current_limit(bd70528, val->intval / 1000);
+	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+		return set_charge_current(bd70528, val->intval / 1000);
+	default:
+		break;
+	}
+	return -EINVAL;
+}
+
+static const struct power_supply_desc bd70528_charger_desc = {
+	.name		= "bd70528-charger",
+	.type		= POWER_SUPPLY_TYPE_BATTERY,
+	.properties	= bd70528_charger_props,
+	.num_properties	= ARRAY_SIZE(bd70528_charger_props),
+	.get_property	= bd70528_charger_get_property,
+	.set_property	= bd70528_charger_set_property,
+	.property_is_writeable	= bd70528_prop_is_writable,
+};
+
+static int bd70528_power_probe(struct platform_device *pdev)
+{
+	struct bd70528 *bd70528, *tmp;
+	struct power_supply *psy;
+	struct power_supply_config cfg = {};
+
+	tmp = dev_get_drvdata(pdev->dev.parent);
+	if (!tmp) {
+		dev_err(&pdev->dev, "No MFD driver data\n");
+		return -EINVAL;
+	}
+	bd70528 = devm_kzalloc(&pdev->dev, sizeof(*bd70528), GFP_KERNEL);
+	if (!bd70528)
+		return -ENOMEM;
+	*bd70528 = *tmp;
+	bd70528->chip.dev = &pdev->dev;
+
+	platform_set_drvdata(pdev, bd70528);
+	cfg.drv_data = bd70528;
+	cfg.of_node = pdev->dev.parent->of_node;
+
+	psy = devm_power_supply_register(&pdev->dev, &bd70528_charger_desc,
+					 &cfg);
+	if (IS_ERR(psy)) {
+		dev_err(&pdev->dev, "failed: power supply register\n");
+		return PTR_ERR(psy);
+	}
+
+	return bd70528_get_irqs(pdev, bd70528);
+}
+
+static struct platform_driver bd70528_power = {
+	.driver = {
+		.name = "bd70528-power"
+	},
+	.probe = bd70528_power_probe,
+};
+
+module_platform_driver(bd70528_power);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD70528 power-supply driver");
+MODULE_LICENSE("GPL");
-- 
2.14.3


-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

Hi Matti!

Thanks for your patch.

We are going to have a problem with the power subsystem.

These charging drivers are growing wild. This is starting to get out
of hand, we need some more framework for properly handling charging
state machines the kernel. Not specifically your problem, but
when working on the driver try to keep generic support in mind.

On Fri, Jan 25, 2019 at 12:06 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> +#define CHG_STAT_SUSPEND       0x0
> +#define CHG_STAT_TRICKLE       0x1
> +#define CHG_STAT_FAST          0x3
> +#define CHG_STAT_TOPOFF                0xe
> +#define CHG_STAT_DONE          0xf
> +#define CHG_STAT_OTP_TRICKLE   0x10
> +#define CHG_STAT_OTP_FAST      0x11
> +#define CHG_STAT_OTP_DONE      0x12
> +#define CHG_STAT_TSD_TRICKLE   0x20
> +#define CHG_STAT_TSD_FAST      0x21
> +#define CHG_STAT_TSD_TOPOFF    0x22
> +#define CHG_STAT_BAT_ERR       0x7f

So what I am seeing is that these states are starting to turn up in more
and more drivers, so we really need to think about a central management
component for charging state machines. I do not think they are all
that different after all.

> +BD_ERR_IRQ_HND(BAT_OV_DET, "Battery overvoltage detected\n");
> +BD_ERR_IRQ_HND(DBAT_DET, "Dead battery detected\n");
> +BD_ERR_IRQ_HND(COLD_DET, "Battery cold\n");
> +BD_ERR_IRQ_HND(HOT_DET, "Battery hot\n");
> +BD_ERR_IRQ_HND(CHG_TSD, "Charger thermal shutdown\n");
> +BD_ERR_IRQ_HND(DCIN2_OV_DET, "DCIN2 overvoltage detected\n");
> +
> +BD_INFO_IRQ_HND(BAT_OV_RES, "Battery voltage back to normal\n");
> +BD_INFO_IRQ_HND(COLD_RES, "Battery temperature back to normal\n");
> +BD_INFO_IRQ_HND(HOT_RES, "Battery temperature back to normal\n");
> +BD_INFO_IRQ_HND(BAT_RMV, "Battery removed\n");
> +BD_INFO_IRQ_HND(BAT_DET, "Battery detected\n");
> +BD_INFO_IRQ_HND(DCIN2_OV_RES, "DCIN2 voltage back to normal\n");
> +BD_INFO_IRQ_HND(DCIN2_RMV, "DCIN2 removed\n");
> +BD_INFO_IRQ_HND(DCIN2_DET, "DCIN2 detected\n");
> +BD_INFO_IRQ_HND(DCIN1_RMV, "DCIN1 removed\n");
> +BD_INFO_IRQ_HND(DCIN1_DET, "DCIN1 detected\n");

So we have states and events, and these events form edges
between the states, right?

I am certain you must have a graphical picture of this state
machine somewhere, it seems to be how charging hardware people
do their thinking.

> +/*
> + * For BD70528 voltage/current limits we happily accept any value which
> + * belongs the range. We could check if value matching the selector is
> + * desired by computing the range min + (sel - sel_low) * range step - but
> + * I guess it is enough if we use voltage/current which is closest (below)
> + * the requested?
> + */
> +static int find_selector_for_value_low(struct linear_range *r, int selectors,
> +                                      unsigned int val, unsigned int *sel,
> +                                      bool *found)
> +{
> +       int i;
> +       int ret = -EINVAL;
> +
> +       *found = false;
> +       for (i = 0; i < selectors; i++) {
> +               if (r[i].min <= val) {
> +                       if (r[i].min + r[i].step * r[i].vals >= val) {
> +                               *found = true;
> +                               *sel = r[i].low_sel + (val - r[i].min) /
> +                                      r[i].step;
> +                               ret = 0;
> +                               break;
> +                       }
> +                       /*
> +                        * If the range max is smaller than requested
> +                        * we can set the max supported value from range
> +                        */
> +                       *sel = r[i].low_sel + r[i].vals;
> +                       ret = 0;
> +               }
> +       }
> +       return ret;
> +}

If I'm not mistaken this is yet another instance of linear interpolation
from a table?

We really need to think about abstracting this. Last time this
duplication appeared I suggested adding linear interpolation
primitives to:
include/linux/fixp-arith.h

I don't know what others say though?

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

Hi Matti!

Thanks for your patch.

We are going to have a problem with the power subsystem.

These charging drivers are growing wild. This is starting to get out
of hand, we need some more framework for properly handling charging
state machines the kernel. Not specifically your problem, but
when working on the driver try to keep generic support in mind.

On Fri, Jan 25, 2019 at 12:06 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> +#define CHG_STAT_SUSPEND       0x0
> +#define CHG_STAT_TRICKLE       0x1
> +#define CHG_STAT_FAST          0x3
> +#define CHG_STAT_TOPOFF                0xe
> +#define CHG_STAT_DONE          0xf
> +#define CHG_STAT_OTP_TRICKLE   0x10
> +#define CHG_STAT_OTP_FAST      0x11
> +#define CHG_STAT_OTP_DONE      0x12
> +#define CHG_STAT_TSD_TRICKLE   0x20
> +#define CHG_STAT_TSD_FAST      0x21
> +#define CHG_STAT_TSD_TOPOFF    0x22
> +#define CHG_STAT_BAT_ERR       0x7f

So what I am seeing is that these states are starting to turn up in more
and more drivers, so we really need to think about a central management
component for charging state machines. I do not think they are all
that different after all.

> +BD_ERR_IRQ_HND(BAT_OV_DET, "Battery overvoltage detected\n");
> +BD_ERR_IRQ_HND(DBAT_DET, "Dead battery detected\n");
> +BD_ERR_IRQ_HND(COLD_DET, "Battery cold\n");
> +BD_ERR_IRQ_HND(HOT_DET, "Battery hot\n");
> +BD_ERR_IRQ_HND(CHG_TSD, "Charger thermal shutdown\n");
> +BD_ERR_IRQ_HND(DCIN2_OV_DET, "DCIN2 overvoltage detected\n");
> +
> +BD_INFO_IRQ_HND(BAT_OV_RES, "Battery voltage back to normal\n");
> +BD_INFO_IRQ_HND(COLD_RES, "Battery temperature back to normal\n");
> +BD_INFO_IRQ_HND(HOT_RES, "Battery temperature back to normal\n");
> +BD_INFO_IRQ_HND(BAT_RMV, "Battery removed\n");
> +BD_INFO_IRQ_HND(BAT_DET, "Battery detected\n");
> +BD_INFO_IRQ_HND(DCIN2_OV_RES, "DCIN2 voltage back to normal\n");
> +BD_INFO_IRQ_HND(DCIN2_RMV, "DCIN2 removed\n");
> +BD_INFO_IRQ_HND(DCIN2_DET, "DCIN2 detected\n");
> +BD_INFO_IRQ_HND(DCIN1_RMV, "DCIN1 removed\n");
> +BD_INFO_IRQ_HND(DCIN1_DET, "DCIN1 detected\n");

So we have states and events, and these events form edges
between the states, right?

I am certain you must have a graphical picture of this state
machine somewhere, it seems to be how charging hardware people
do their thinking.

> +/*
> + * For BD70528 voltage/current limits we happily accept any value which
> + * belongs the range. We could check if value matching the selector is
> + * desired by computing the range min + (sel - sel_low) * range step - but
> + * I guess it is enough if we use voltage/current which is closest (below)
> + * the requested?
> + */
> +static int find_selector_for_value_low(struct linear_range *r, int selectors,
> +                                      unsigned int val, unsigned int *sel,
> +                                      bool *found)
> +{
> +       int i;
> +       int ret = -EINVAL;
> +
> +       *found = false;
> +       for (i = 0; i < selectors; i++) {
> +               if (r[i].min <= val) {
> +                       if (r[i].min + r[i].step * r[i].vals >= val) {
> +                               *found = true;
> +                               *sel = r[i].low_sel + (val - r[i].min) /
> +                                      r[i].step;
> +                               ret = 0;
> +                               break;
> +                       }
> +                       /*
> +                        * If the range max is smaller than requested
> +                        * we can set the max supported value from range
> +                        */
> +                       *sel = r[i].low_sel + r[i].vals;
> +                       ret = 0;
> +               }
> +       }
> +       return ret;
> +}

If I'm not mistaken this is yet another instance of linear interpolation
from a table?

We really need to think about abstracting this. Last time this
duplication appeared I suggested adding linear interpolation
primitives to:
include/linux/fixp-arith.h

I don't know what others say though?

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Matti Vaittinen]

Hello Linus,

Big Thanks for the proper review at this early satge!

On Mon, Jan 28, 2019 at 01:49:04PM +0100, Linus Walleij wrote:
> Hi Matti!
> 
> Thanks for your patch.
> 
> We are going to have a problem with the power subsystem.
> 
> These charging drivers are growing wild. This is starting to get out
> of hand, we need some more framework for properly handling charging
> state machines the kernel. Not specifically your problem, but
> when working on the driver try to keep generic support in mind.

I for sure can try - but as the power subsystem is quite new to me - any
specific items you would like me to really pay attention?

> On Fri, Jan 25, 2019 at 12:06 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
> > +#define CHG_STAT_SUSPEND       0x0
> > +#define CHG_STAT_TRICKLE       0x1
> > +#define CHG_STAT_FAST          0x3
> > +#define CHG_STAT_TOPOFF                0xe
> > +#define CHG_STAT_DONE          0xf
> > +#define CHG_STAT_OTP_TRICKLE   0x10
> > +#define CHG_STAT_OTP_FAST      0x11
> > +#define CHG_STAT_OTP_DONE      0x12
> > +#define CHG_STAT_TSD_TRICKLE   0x20
> > +#define CHG_STAT_TSD_FAST      0x21
> > +#define CHG_STAT_TSD_TOPOFF    0x22
> > +#define CHG_STAT_BAT_ERR       0x7f
> 
> So what I am seeing is that these states are starting to turn up in more
> and more drivers, so we really need to think about a central management
> component for charging state machines. I do not think they are all
> that different after all.

Any suggestions how I should take this into account with bd70528?

> > +BD_ERR_IRQ_HND(BAT_OV_DET, "Battery overvoltage detected\n");
> > +BD_ERR_IRQ_HND(DBAT_DET, "Dead battery detected\n");
> > +BD_ERR_IRQ_HND(COLD_DET, "Battery cold\n");
> > +BD_ERR_IRQ_HND(HOT_DET, "Battery hot\n");
> > +BD_ERR_IRQ_HND(CHG_TSD, "Charger thermal shutdown\n");
> > +BD_ERR_IRQ_HND(DCIN2_OV_DET, "DCIN2 overvoltage detected\n");
> > +
> > +BD_INFO_IRQ_HND(BAT_OV_RES, "Battery voltage back to normal\n");
> > +BD_INFO_IRQ_HND(COLD_RES, "Battery temperature back to normal\n");
> > +BD_INFO_IRQ_HND(HOT_RES, "Battery temperature back to normal\n");
> > +BD_INFO_IRQ_HND(BAT_RMV, "Battery removed\n");
> > +BD_INFO_IRQ_HND(BAT_DET, "Battery detected\n");
> > +BD_INFO_IRQ_HND(DCIN2_OV_RES, "DCIN2 voltage back to normal\n");
> > +BD_INFO_IRQ_HND(DCIN2_RMV, "DCIN2 removed\n");
> > +BD_INFO_IRQ_HND(DCIN2_DET, "DCIN2 detected\n");
> > +BD_INFO_IRQ_HND(DCIN1_RMV, "DCIN1 removed\n");
> > +BD_INFO_IRQ_HND(DCIN1_DET, "DCIN1 detected\n");
> 
> So we have states and events, and these events form edges
> between the states, right?

Right. State change causes an irq.

> I am certain you must have a graphical picture of this state
> machine somewhere, it seems to be how charging hardware people
> do their thinking.

I don't have any document I could link to yet. I can ask around if we
can have some public doc for this :/ And as a last resort I can do some
ASCII art in commenets - if this is seen helpfull.

> > +/*
> > + * For BD70528 voltage/current limits we happily accept any value which
> > + * belongs the range. We could check if value matching the selector is
> > + * desired by computing the range min + (sel - sel_low) * range step - but
> > + * I guess it is enough if we use voltage/current which is closest (below)
> > + * the requested?
> > + */
> > +static int find_selector_for_value_low(struct linear_range *r, int selectors,
> > +                                      unsigned int val, unsigned int *sel,
> > +                                      bool *found)
> > +{
> > +       int i;
> > +       int ret = -EINVAL;
> > +
> > +       *found = false;
> > +       for (i = 0; i < selectors; i++) {
> > +               if (r[i].min <= val) {
> > +                       if (r[i].min + r[i].step * r[i].vals >= val) {
> > +                               *found = true;
> > +                               *sel = r[i].low_sel + (val - r[i].min) /
> > +                                      r[i].step;
> > +                               ret = 0;
> > +                               break;
> > +                       }
> > +                       /*
> > +                        * If the range max is smaller than requested
> > +                        * we can set the max supported value from range
> > +                        */
> > +                       *sel = r[i].low_sel + r[i].vals;
> > +                       ret = 0;
> > +               }
> > +       }
> > +       return ret;
> > +}
> 
> If I'm not mistaken this is yet another instance of linear interpolation
> from a table?

"linear interpolation from a table" is really not part of my
vocabulary :] But I guess you know the REGULATOR_LINEAR_VOLTAGE - macro?
I borrowed the idea from there...
> 
> We really need to think about abstracting this. Last time this
> duplication appeared I suggested adding linear interpolation
> primitives to:
> include/linux/fixp-arith.h

... I really think a generic helper for this would be usefull.

It will take some time untill I can send a proper (non RFC patch) for
the charger block as I currently lack of HW I could use for testing the
charger properly. Do you think it is better to drop the charger part
from the series untill then and submit it only later? As I mentioned in
cover-letter, the charger part is currently submitted more to give an
overview of the chip than to be applied as 'finalized' version of
driver.

Br,
	Matti Vaittinen

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Matti Vaittinen]

Hello Linus,

Big Thanks for the proper review at this early satge!

On Mon, Jan 28, 2019 at 01:49:04PM +0100, Linus Walleij wrote:
> Hi Matti!
> 
> Thanks for your patch.
> 
> We are going to have a problem with the power subsystem.
> 
> These charging drivers are growing wild. This is starting to get out
> of hand, we need some more framework for properly handling charging
> state machines the kernel. Not specifically your problem, but
> when working on the driver try to keep generic support in mind.

I for sure can try - but as the power subsystem is quite new to me - any
specific items you would like me to really pay attention?

> On Fri, Jan 25, 2019 at 12:06 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
> > +#define CHG_STAT_SUSPEND       0x0
> > +#define CHG_STAT_TRICKLE       0x1
> > +#define CHG_STAT_FAST          0x3
> > +#define CHG_STAT_TOPOFF                0xe
> > +#define CHG_STAT_DONE          0xf
> > +#define CHG_STAT_OTP_TRICKLE   0x10
> > +#define CHG_STAT_OTP_FAST      0x11
> > +#define CHG_STAT_OTP_DONE      0x12
> > +#define CHG_STAT_TSD_TRICKLE   0x20
> > +#define CHG_STAT_TSD_FAST      0x21
> > +#define CHG_STAT_TSD_TOPOFF    0x22
> > +#define CHG_STAT_BAT_ERR       0x7f
> 
> So what I am seeing is that these states are starting to turn up in more
> and more drivers, so we really need to think about a central management
> component for charging state machines. I do not think they are all
> that different after all.

Any suggestions how I should take this into account with bd70528?

> > +BD_ERR_IRQ_HND(BAT_OV_DET, "Battery overvoltage detected\n");
> > +BD_ERR_IRQ_HND(DBAT_DET, "Dead battery detected\n");
> > +BD_ERR_IRQ_HND(COLD_DET, "Battery cold\n");
> > +BD_ERR_IRQ_HND(HOT_DET, "Battery hot\n");
> > +BD_ERR_IRQ_HND(CHG_TSD, "Charger thermal shutdown\n");
> > +BD_ERR_IRQ_HND(DCIN2_OV_DET, "DCIN2 overvoltage detected\n");
> > +
> > +BD_INFO_IRQ_HND(BAT_OV_RES, "Battery voltage back to normal\n");
> > +BD_INFO_IRQ_HND(COLD_RES, "Battery temperature back to normal\n");
> > +BD_INFO_IRQ_HND(HOT_RES, "Battery temperature back to normal\n");
> > +BD_INFO_IRQ_HND(BAT_RMV, "Battery removed\n");
> > +BD_INFO_IRQ_HND(BAT_DET, "Battery detected\n");
> > +BD_INFO_IRQ_HND(DCIN2_OV_RES, "DCIN2 voltage back to normal\n");
> > +BD_INFO_IRQ_HND(DCIN2_RMV, "DCIN2 removed\n");
> > +BD_INFO_IRQ_HND(DCIN2_DET, "DCIN2 detected\n");
> > +BD_INFO_IRQ_HND(DCIN1_RMV, "DCIN1 removed\n");
> > +BD_INFO_IRQ_HND(DCIN1_DET, "DCIN1 detected\n");
> 
> So we have states and events, and these events form edges
> between the states, right?

Right. State change causes an irq.

> I am certain you must have a graphical picture of this state
> machine somewhere, it seems to be how charging hardware people
> do their thinking.

I don't have any document I could link to yet. I can ask around if we
can have some public doc for this :/ And as a last resort I can do some
ASCII art in commenets - if this is seen helpfull.

> > +/*
> > + * For BD70528 voltage/current limits we happily accept any value which
> > + * belongs the range. We could check if value matching the selector is
> > + * desired by computing the range min + (sel - sel_low) * range step - but
> > + * I guess it is enough if we use voltage/current which is closest (below)
> > + * the requested?
> > + */
> > +static int find_selector_for_value_low(struct linear_range *r, int selectors,
> > +                                      unsigned int val, unsigned int *sel,
> > +                                      bool *found)
> > +{
> > +       int i;
> > +       int ret = -EINVAL;
> > +
> > +       *found = false;
> > +       for (i = 0; i < selectors; i++) {
> > +               if (r[i].min <= val) {
> > +                       if (r[i].min + r[i].step * r[i].vals >= val) {
> > +                               *found = true;
> > +                               *sel = r[i].low_sel + (val - r[i].min) /
> > +                                      r[i].step;
> > +                               ret = 0;
> > +                               break;
> > +                       }
> > +                       /*
> > +                        * If the range max is smaller than requested
> > +                        * we can set the max supported value from range
> > +                        */
> > +                       *sel = r[i].low_sel + r[i].vals;
> > +                       ret = 0;
> > +               }
> > +       }
> > +       return ret;
> > +}
> 
> If I'm not mistaken this is yet another instance of linear interpolation
> from a table?

"linear interpolation from a table" is really not part of my
vocabulary :] But I guess you know the REGULATOR_LINEAR_VOLTAGE - macro?
I borrowed the idea from there...
> 
> We really need to think about abstracting this. Last time this
> duplication appeared I suggested adding linear interpolation
> primitives to:
> include/linux/fixp-arith.h

... I really think a generic helper for this would be usefull.

It will take some time untill I can send a proper (non RFC patch) for
the charger block as I currently lack of HW I could use for testing the
charger properly. Do you think it is better to drop the charger part
from the series untill then and submit it only later? As I mentioned in
cover-letter, the charger part is currently submitted more to give an
overview of the chip than to be applied as 'finalized' version of
driver.

Br,
	Matti Vaittinen

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

On Mon, Jan 28, 2019 at 2:54 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> > These charging drivers are growing wild. This is starting to get out
> > of hand, we need some more framework for properly handling charging
> > state machines the kernel. Not specifically your problem, but
> > when working on the driver try to keep generic support in mind.
>
> I for sure can try - but as the power subsystem is quite new to me - any
> specific items you would like me to really pay attention?

So I am not saying you have to do this or anything, but I think
what we need is a generic state machine and policy engine
for charging, where different charging drivers just plug in.

They all seem to have trickle and fast charging, USB phy
interaction and AC plug interaction of some kind for detecting
those and in some cases temperature detection directly
or using an ADC.

We have a bunch of drivers with software-controlled charging:
ab8500*
axp288*
etc.

If we could get just two drivers to share some changing
infrastructure we would have a start.

I have no idea how hard it could be, but I think it would
be a pretty interesting adventure if someone gathered
some different hardwares and started to generalize parts
of this.

> > So what I am seeing is that these states are starting to turn up in more
> > and more drivers, so we really need to think about a central management
> > component for charging state machines. I do not think they are all
> > that different after all.
>
> Any suggestions how I should take this into account with bd70528?

Not more than above, it is unfair to ask random contributors to
invent entire new worlds of kernel infrastructure. But I guess I
just need to say it so we are aware: this charging state machine
engine is needed. Doing it is another thing.

> > I am certain you must have a graphical picture of this state
> > machine somewhere, it seems to be how charging hardware people
> > do their thinking.
>
> I don't have any document I could link to yet. I can ask around if we
> can have some public doc for this :/ And as a last resort I can do some
> ASCII art in commenets - if this is seen helpfull.

That'd be nice.

> > If I'm not mistaken this is yet another instance of linear interpolation
> > from a table?
>
> "linear interpolation from a table" is really not part of my
> vocabulary :] But I guess you know the REGULATOR_LINEAR_VOLTAGE - macro?
> I borrowed the idea from there...

I'm referring to this essentially:
https://en.wikipedia.org/wiki/Linear_interpolation

What many charging drivers tends to do is:
- Look up where I am in a table, say between row 4 and 5
- For x-axis n..n+1, interpolate y-axis between
  the values found for x=1 and x=n+1 using
  common linear interpolation.

> > We really need to think about abstracting this. Last time this
> > duplication appeared I suggested adding linear interpolation
> > primitives to:
> > include/linux/fixp-arith.h
>
> ... I really think a generic helper for this would be usefull.

Indeed.

> It will take some time untill I can send a proper (non RFC patch) for
> the charger block as I currently lack of HW I could use for testing the
> charger properly. Do you think it is better to drop the charger part
> from the series untill then and submit it only later?

Not really, we need to face the hardware out there and I usually
use the stance "rough consensus and running code". If noone
invents a unified charging framework, your hardware needs to
run so a custom driver isn't that bad either, and it's still better
to have it in-tree than to maintain it out-of-tree as long as it
is clearly isolated.

> As I mentioned in
> cover-letter, the charger part is currently submitted more to give an
> overview of the chip than to be applied as 'finalized' version of
> driver.

That's OK.

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

On Mon, Jan 28, 2019 at 2:54 PM Matti Vaittinen
<matti.vaittinen@fi.rohmeurope.com> wrote:

> > These charging drivers are growing wild. This is starting to get out
> > of hand, we need some more framework for properly handling charging
> > state machines the kernel. Not specifically your problem, but
> > when working on the driver try to keep generic support in mind.
>
> I for sure can try - but as the power subsystem is quite new to me - any
> specific items you would like me to really pay attention?

So I am not saying you have to do this or anything, but I think
what we need is a generic state machine and policy engine
for charging, where different charging drivers just plug in.

They all seem to have trickle and fast charging, USB phy
interaction and AC plug interaction of some kind for detecting
those and in some cases temperature detection directly
or using an ADC.

We have a bunch of drivers with software-controlled charging:
ab8500*
axp288*
etc.

If we could get just two drivers to share some changing
infrastructure we would have a start.

I have no idea how hard it could be, but I think it would
be a pretty interesting adventure if someone gathered
some different hardwares and started to generalize parts
of this.

> > So what I am seeing is that these states are starting to turn up in more
> > and more drivers, so we really need to think about a central management
> > component for charging state machines. I do not think they are all
> > that different after all.
>
> Any suggestions how I should take this into account with bd70528?

Not more than above, it is unfair to ask random contributors to
invent entire new worlds of kernel infrastructure. But I guess I
just need to say it so we are aware: this charging state machine
engine is needed. Doing it is another thing.

> > I am certain you must have a graphical picture of this state
> > machine somewhere, it seems to be how charging hardware people
> > do their thinking.
>
> I don't have any document I could link to yet. I can ask around if we
> can have some public doc for this :/ And as a last resort I can do some
> ASCII art in commenets - if this is seen helpfull.

That'd be nice.

> > If I'm not mistaken this is yet another instance of linear interpolation
> > from a table?
>
> "linear interpolation from a table" is really not part of my
> vocabulary :] But I guess you know the REGULATOR_LINEAR_VOLTAGE - macro?
> I borrowed the idea from there...

I'm referring to this essentially:
https://en.wikipedia.org/wiki/Linear_interpolation

What many charging drivers tends to do is:
- Look up where I am in a table, say between row 4 and 5
- For x-axis n..n+1, interpolate y-axis between
  the values found for x=1 and x=n+1 using
  common linear interpolation.

> > We really need to think about abstracting this. Last time this
> > duplication appeared I suggested adding linear interpolation
> > primitives to:
> > include/linux/fixp-arith.h
>
> ... I really think a generic helper for this would be usefull.

Indeed.

> It will take some time untill I can send a proper (non RFC patch) for
> the charger block as I currently lack of HW I could use for testing the
> charger properly. Do you think it is better to drop the charger part
> from the series untill then and submit it only later?

Not really, we need to face the hardware out there and I usually
use the stance "rough consensus and running code". If noone
invents a unified charging framework, your hardware needs to
run so a custom driver isn't that bad either, and it's still better
to have it in-tree than to maintain it out-of-tree as long as it
is clearly isolated.

> As I mentioned in
> cover-letter, the charger part is currently submitted more to give an
> overview of the chip than to be applied as 'finalized' version of
> driver.

That's OK.

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Vaittinen, Matti]

Hi dee Ho Peeps!

I started working for a driver for ROHM BD99954 charger chip and ended
up writing the linear range code once again. And that reminded me of
this year old discussion :)

On Mon, 2019-01-28 at 15:46 +0100, Linus Walleij wrote:
> On Mon, Jan 28, 2019 at 2:54 PM Matti Vaittinen
> <matti.vaittinen@fi.rohmeurope.com> wrote:
> 
> > > These charging drivers are growing wild. This is starting to get
> > > out
> > > of hand, we need some more framework for properly handling
> > > charging
> > > state machines the kernel. Not specifically your problem, but
> > > when working on the driver try to keep generic support in mind.
> > 
> > I for sure can try - but as the power subsystem is quite new to me
> > - any
> > specific items you would like me to really pay attention?
> 
> So I am not saying you have to do this or anything, but I think
> what we need is a generic state machine and policy engine
> for charging, where different charging drivers just plug in.

The BD99954 charger as well as the BD70528 charger (and BD71828 charger
- which I have not yet sumitted in-tree as it has a tuned-to-work-with-
only-one-battery fuel-gauge algorithm) do not need much of SW control
for the state machine. Basically the SW mostly needs to set the
voltage/current thresholds which match the system HW design and the
battery. My current idea is to bring these from DT - if this is a way
to go, then I can try seeing how much common DT-parsing/binding naming
I can use for these ROHM chargers...

> They all seem to have trickle and fast charging, USB phy
> interaction and AC plug interaction of some kind for detecting
> those and in some cases temperature detection directly
> or using an ADC.

Yes. That's pretty much what these ROHM chips have. But SW mostly needs
to set the limit values - it does not need to participate in state
changing and most of these things are also something users do not care
(I guess). Fuel gauging is other topic but I'm not planning to
implement it for in-tree drivers at least for now :/ 

The thing that comes to (my) mind is just a common DT properties for
input current/voltage limits, battery voltages for switching to next
charging state, current values for different charging states - and
parsing of these properties.

I've seen some comments about DT not being a good place for battery
specific properties as batteries may be replaced with another having
different type - but I don't think this is valid problem for many of
the devices today. Of course some devices may have batteries that can
be changed - but many don't - and for those it is perfectly Ok to have
battery data defined in DT, right?

First thought is that setting these values needs to be done by driver
(as it's chip specific) - and that the power-supply framework does not
need to know anything about this - it could just provide of-helper for
parsing the DT. That would be simple and no callbacks would be needed.

But ... do we need to provide a way for user-space to configure these
settings instead of the DT? Or any other possible sources for this
information?

If this is needed - then we probably would want to have the callbacks.
Individual driver would not need to care where the configuration comes
from - it would just provide callback and leave it to power-supply
framework to check if the limits are in DT or come from user-space or
some other source.

This is just some initial thinking - currently I have set of good old
rohm,blahblah-microvolts and rohm,blahblah-microamp charger specific
properties and parsing code is getting in-driver... But I would like to
hear about any thoughts this may invoke.

> We have a bunch of drivers with software-controlled charging:
> ab8500*
> axp288*
> etc.
> 
> If we could get just two drivers to share some changing
> infrastructure we would have a start.

Hmm. If changing means state changes - then these ROHM chips probably
play no role here as there the HW does most of the state changes
autonomously. (AFAIR, it's been a while since I looked the other but
BD99954).

> > > If I'm not mistaken this is yet another instance of linear
> > > interpolation
> > > from a table?
> > 
> > "linear interpolation from a table" is really not part of my
> > vocabulary :] But I guess you know the REGULATOR_LINEAR_VOLTAGE -
> > macro?
> > I borrowed the idea from there...
> 
> I'm referring to this essentially:
> https://en.wikipedia.org/wiki/Linear_interpolation
> 
> What many charging drivers tends to do is:
> - Look up where I am in a table, say between row 4 and 5
> - For x-axis n..n+1, interpolate y-axis between
>   the values found for x=1 and x=n+1 using
>   common linear interpolation.
> 
> > > We really need to think about abstracting this. Last time this
> > > duplication appeared I suggested adding linear interpolation
> > > primitives to:
> > > include/linux/fixp-arith.h
> > 
> > ... I really think a generic helper for this would be usefull.
> 
> Indeed.

And I am again doing the value lookup code here. I again have
voltage/current registers where writing value n (where n is in a range
0,...,N) will cause voltage Vto be set V = V0 + n*(Vstep). (Okay, n can
start from something else than 0 too - but I just wanted to explain the
idea). So I am again writing a look-up code to match "selector" n to a
value V or a value V to a selector n. This is required for example when
I convert voltage/current DT values to register values.

So ... If I extract the linear_range code from BD70528 driver (it
should be usable for the BD99954 as such) - should I place it to some
common header/lib? (This is plain integer maths so I don't like the
idea of placing it in fixp-arith.h). I would assume there is quite a
few chips with registers where increment of 1 in register means fixed
increment in some physical value (current, voltage, something else,...)
so having this code in some rohm-helpers.c and internal header is
suboptimal (but I can do that too).

Any guidance or suggestions?

Br,
	Matti Vaittinen

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

On Thu, Feb 6, 2020 at 8:54 AM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:

> I started working for a driver for ROHM BD99954 charger chip and ended
> up writing the linear range code once again. And that reminded me of
> this year old discussion :)

OK!

> > They all seem to have trickle and fast charging, USB phy
> > interaction and AC plug interaction of some kind for detecting
> > those and in some cases temperature detection directly
> > or using an ADC.
>
> Yes. That's pretty much what these ROHM chips have. But SW mostly needs
> to set the limit values - it does not need to participate in state
> changing and most of these things are also something users do not care
> (I guess). Fuel gauging is other topic but I'm not planning to
> implement it for in-tree drivers at least for now :/
>
> The thing that comes to (my) mind is just a common DT properties for
> input current/voltage limits, battery voltages for switching to next
> charging state, current values for different charging states - and
> parsing of these properties.
>
> I've seen some comments about DT not being a good place for battery
> specific properties as batteries may be replaced with another having
> different type - but I don't think this is valid problem for many of
> the devices today. Of course some devices may have batteries that can
> be changed - but many don't - and for those it is perfectly Ok to have
> battery data defined in DT, right?

If something is a property of the charging circuit, then it can be derived
from the compatible value, so anything that is just peculiar for this
chip version doesn't go into device tree, just use a custom struct and
the match data for that.

Then we have the battery. I suppose that could be defined as a DT
node for the battery itself, and not as part of the charging IC, and we
should think about how to create a battery DT binding. What
characteristics are chargers really interested in? This could be some
work.

If different devices have different batteries then the boot loader
could ideally patch the DT with the right battery. This was the solution
advocated for devices with different display panels, to a question
from Hans de Goede at one point IIRC.

> But ... do we need to provide a way for user-space to configure these
> settings instead of the DT? Or any other possible sources for this
> information?

What we usually have said is that "policy should be in userspace"
and "kernel manages hardware". This creates a not-so-small
grey area in between and it is unfortunately up to interpretation.

Today there is also a THIRD alternative, and that is to let
userspace insert a policy using a BPF program. This is the
approach taken by the network and tracing stacks and we look at
more applications. If the kernel needs to be able to handle charging
and emergencies even if userspace is not up or available, this or other
userspace policies are not viable.

I have a strong feeling that it should be a battery node in the device
tree.

> Hmm. If changing means state changes - then these ROHM chips probably
> play no role here as there the HW does most of the state changes
> autonomously. (AFAIR, it's been a while since I looked at the other but
> BD99954).

Good it's a simpler hardware. We just need to think about making
the code reusable.

> So ... If I extract the linear_range code from BD70528 driver (it
> should be usable for the BD99954 as such) - should I place it to some
> common header/lib? (This is plain integer math so I don't like the
> idea of placing it in fixp-arith.h).

Start with moving it to some separate file, like
power_supply_interpolation.c that we just always compile in
and we can take it from there.

Just some thoughts...

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Vaittinen, Matti]

Hello Linus,

First of all - thanks for taking the time to help me once again.

I just some time ago did submit the RFC for BD99954 - and immediately
regretted doing so as only few minutes later I spotted the already
existing battery code/bindings. It's quite embarrassing to send out an
email for wide audience just to notice that I've written large amount
of nonsense :/ (I suggested adding common bindings and parsers and
didn't notice we already had bunch of them).

On Mon, 2020-02-10 at 14:12 +0100, Linus Walleij wrote:
> On Thu, Feb 6, 2020 at 8:54 AM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> 
> 
> > > They all seem to have trickle and fast charging, USB phy
> > > interaction and AC plug interaction of some kind for detecting
> > > those and in some cases temperature detection directly
> > > or using an ADC.
> > 
> > Yes. That's pretty much what these ROHM chips have. But SW mostly
> > needs
> > to set the limit values - it does not need to participate in state
> > changing and most of these things are also something users do not
> > care
> > (I guess). Fuel gauging is other topic but I'm not planning to
> > implement it for in-tree drivers at least for now :/
> > 
> > The thing that comes to (my) mind is just a common DT properties
> > for
> > input current/voltage limits, battery voltages for switching to
> > next
> > charging state, current values for different charging states - and
> > parsing of these properties.
> > 
> > I've seen some comments about DT not being a good place for battery
> > specific properties as batteries may be replaced with another
> > having
> > different type - but I don't think this is valid problem for many
> > of
> > the devices today. Of course some devices may have batteries that
> > can
> > be changed - but many don't - and for those it is perfectly Ok to
> > have
> > battery data defined in DT, right?
> 
> If something is a property of the charging circuit, then it can be
> derived
> from the compatible value, so anything that is just peculiar for this
> chip version doesn't go into device tree, just use a custom struct
> and
> the match data for that.

Agree. Assuming the limitation comes from charging circuit itself. But
I thought that for example some input current limits might come from
the external circuitry (neither from charger, nor from battery).

> Then we have the battery. I suppose that could be defined as a DT
> node for the battery itself, and not as part of the charging IC, and
> we
> should think about how to create a battery DT binding.

Oh, yes. This is my newest mistake. We already seem to have the
"simple-battery" bindings and a helper to retrieve given configs. After
I understood that I noticed that there is only couple of bindings I
might add there.

>  What
> characteristics are chargers really interested in? This could be some
> work.
> 
> If different devices have different batteries then the boot loader
> could ideally patch the DT with the right battery. This was the
> solution
> advocated for devices with different display panels, to a question
> from Hans de Goede at one point IIRC.

Hmm. This sounds simpler than adding bunch of charger drivers in boot
loader. OTOH, if boot loader can detect the type of the battery, then I
see why linux couldn't? And if type of battery can be hard-coded in
boot, then I don't see why it couldn't be hard-coded in DT. But this
all goes far beyond my area of expertice ;)

> > But ... do we need to provide a way for user-space to configure
> > these
> > settings instead of the DT? Or any other possible sources for this
> > information?
> 
> What we usually have said is that "policy should be in userspace"
> and "kernel manages hardware". This creates a not-so-small
> grey area in between and it is unfortunately up to interpretation.
> 
> Today there is also a THIRD alternative, and that is to let
> userspace insert a policy using a BPF program. This is the
> approach taken by the network and tracing stacks and we look at
> more applications. If the kernel needs to be able to handle charging
> and emergencies even if userspace is not up or available, this or
> other
> userspace policies are not viable.

Just as a theoretical discussion this is interesting topic. I think the
fuel-gauge might be area where we could want to avoid waking up the
user-space when states change. But for my current crusade to power-
supply-world we are mostly limited to one-time configurations like
battery properties and system constraints for input currents etc.

> I have a strong feeling that it should be a battery node in the
> device
> tree.

Yes. Now that I learned about it - mostly so. Except the input current
limits and VSYS regulation.

> > Hmm. If changing means state changes - then these ROHM chips
> > probably
> > play no role here as there the HW does most of the state changes
> > autonomously. (AFAIR, it's been a while since I looked at the other
> > but
> > BD99954).
> 
> Good it's a simpler hardware. We just need to think about making
> the code reusable.
> 
> > So ... If I extract the linear_range code from BD70528 driver (it
> > should be usable for the BD99954 as such) - should I place it to
> > some
> > common header/lib? (This is plain integer math so I don't like the
> > idea of placing it in fixp-arith.h).
> 
> Start with moving it to some separate file, like
> power_supply_interpolation.c that we just always compile in
> and we can take it from there.

Oh, that's pretty much what I did :) And that is pretty much the only
patch that makes sense in this first RFC version :|

> 
> Just some thoughts...
> 
Thanks Linus. I _really_ appreciate your time and help! :)

Best Regards,
	Matti Vaittinen

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Linus Walleij]

On Mon, Feb 10, 2020 at 3:03 PM Vaittinen, Matti
<Matti.Vaittinen@fi.rohmeurope.com> wrote:
> On Mon, 2020-02-10 at 14:12 +0100, Linus Walleij wrote:

> > If different devices have different batteries then the boot loader
> > could ideally patch the DT with the right battery. This was the
> > solution
> > advocated for devices with different display panels, to a question
> > from Hans de Goede at one point IIRC.
>
> Hmm. This sounds simpler than adding bunch of charger drivers in boot
> loader. OTOH, if boot loader can detect the type of the battery, then I
> see why linux couldn't? And if type of battery can be hard-coded in
> boot, then I don't see why it couldn't be hard-coded in DT. But this
> all goes far beyond my area of expertice ;)

It's a gray area.

The boot loader, as well as the kernel, can detect the presence of
some specific battery and screen using e.g. probing with i2c
addresses or by reading GPIO lines or some other magic number
such as the serial number of the device.

The kernel does have similar code in some places. Also the
function where we enter is module is deceptively named "probe()".

So at some point it was common practice for the kernel to do this.

After the introduction of device tree, there has been some pushback
from boot architecture people (this is the name for people doing
thinking around DT, ACPI, UEFI and U-Boot) that this kind of funny
probing code should be done in the boot loader, then the boot loader
need to figure out how the device tree should actually look, construct
it and pass the result to the kernel. This works for anything that
detectable and not hot-plugged.

As we are in parallel, especially on the ARM architectures, pushing
a "single kernel image" concept this makes a lot of sense, so we
keep down the number of funny probing code in that single kernel
image.

Maybe we should actually write this up somewhere. (Or it is already?)
I only picked the above up from misc conversations.

Yours,
Linus Walleij

Re: [RFC PATCH v2 09/10] power: supply: Initial support for ROHM BD70528 PMIC charger block

[Vaittinen, Matti]

Hello Linus,

On Tue, 2020-02-11 at 14:15 +0100, Linus Walleij wrote:
> On Mon, Feb 10, 2020 at 3:03 PM Vaittinen, Matti
> <Matti.Vaittinen@fi.rohmeurope.com> wrote:
> > On Mon, 2020-02-10 at 14:12 +0100, Linus Walleij wrote:
> > > If different devices have different batteries then the boot
> > > loader
> > > could ideally patch the DT with the right battery. This was the
> > > solution
> > > advocated for devices with different display panels, to a
> > > question
> > > from Hans de Goede at one point IIRC.
> > 
> > Hmm. This sounds simpler than adding bunch of charger drivers in
> > boot
> > loader. OTOH, if boot loader can detect the type of the battery,
> > then I
> > see why linux couldn't? And if type of battery can be hard-coded in
> > boot, then I don't see why it couldn't be hard-coded in DT. But
> > this
> > all goes far beyond my area of expertice ;)
> 
> It's a gray area.
> 
> The boot loader, as well as the kernel, can detect the presence of
> some specific battery and screen using e.g. probing with i2c
> addresses or by reading GPIO lines or some other magic number
> such as the serial number of the device.
> 
> The kernel does have similar code in some places. Also the
> function where we enter is module is deceptively named "probe()".
> 
> So at some point it was common practice for the kernel to do this.

Hm. I think I've seen some i2c drivers doing cool probing to detect if
connected decvice is what it is expected to be :) So this didn't really
come as surprize to me :)

> After the introduction of device tree, there has been some pushback
> from boot architecture people (this is the name for people doing
> thinking around DT, ACPI, UEFI and U-Boot) that this kind of funny
> probing code should be done in the boot loader, then the boot loader
> need to figure out how the device tree should actually look,
> construct
> it and pass the result to the kernel. This works for anything that
> detectable and not hot-plugged.

Ah. I didn't know about this push. Besides, this may fall apart when
hot-plug comes to play :/

Although, I once worked with a device that had pluggable cards - each
of the different type of cards had a dt-binary blob on on-board eeprom
describing the contents of this card - and when the card was plugged in
the processor was reading the EEPROM and did overlay merging of the
found dt-blob. That made devices on plugged card detected and usable.
If card was removed the dt-overlay was removed... Oh, that was a fancy
project all in all :)

> As we are in parallel, especially on the ARM architectures, pushing
> a "single kernel image" concept this makes a lot of sense, so we
> keep down the number of funny probing code in that single kernel
> image.
> 
> Maybe we should actually write this up somewhere. (Or it is already?)
> I only picked the above up from misc conversations.

Well, that would be helpful - assuming the reader is able to look up
the documentation - I know that some people fail on this occasionally
*ahem*

Anyways, thanks for the explanation!

Best Regards
	Matti Vaittinen