[PATCH 1/6] power: pcf50633: add ac power supply class to the charger

[PATCH 1/6] power: pcf50633: add ac power supply class to the charger

[Paul Fertser]

From: Sean McNeil <sean@mcneil.com>

This adds an appropriate ac power_supply class and shows usb only when
at the appropriate current limit.

Signed-off-by: Sean McNeil <sean@mcneil.com>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
 drivers/power/pcf50633-charger.c |   46 +++++++++++++++++++++++++++++++++++++-
 1 files changed, 45 insertions(+), 1 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index e8b278f..48e92c0 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -36,6 +36,7 @@ struct pcf50633_mbc {
 
 	struct power_supply usb;
 	struct power_supply adapter;
+	struct power_supply ac;
 
 	struct delayed_work charging_restart_work;
 };
@@ -237,6 +238,7 @@ pcf50633_mbc_irq_handler(int irq, void *data)
 	else if (irq == PCF50633_IRQ_USBLIMOFF)
 		mbc->usb_active = 1;
 
+	power_supply_changed(&mbc->ac);
 	power_supply_changed(&mbc->usb);
 	power_supply_changed(&mbc->adapter);
 
@@ -269,10 +271,34 @@ static int usb_get_property(struct power_supply *psy,
 {
 	struct pcf50633_mbc *mbc = container_of(psy, struct pcf50633_mbc, usb);
 	int ret = 0;
+	u8 usblim = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCC7) &
+						PCF50633_MBCC7_USB_MASK;
+
+	switch (psp) {
+	case POWER_SUPPLY_PROP_ONLINE:
+		val->intval = mbc->usb_online &&
+				(usblim <= PCF50633_MBCC7_USB_500mA);
+		break;
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int ac_get_property(struct power_supply *psy,
+			enum power_supply_property psp,
+			union power_supply_propval *val)
+{
+	struct pcf50633_mbc *mbc = container_of(psy, struct pcf50633_mbc, ac);
+	int ret = 0;
+	u8 usblim = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCC7) &
+						PCF50633_MBCC7_USB_MASK;
 
 	switch (psp) {
 	case POWER_SUPPLY_PROP_ONLINE:
-		val->intval = mbc->usb_online;
+		val->intval = mbc->usb_online &&
+				(usblim == PCF50633_MBCC7_USB_1000mA);
 		break;
 	default:
 		ret = -EINVAL;
@@ -337,6 +363,14 @@ static int __devinit pcf50633_mbc_probe(struct platform_device *pdev)
 	mbc->usb.supplied_to		= mbc->pcf->pdata->batteries;
 	mbc->usb.num_supplicants	= mbc->pcf->pdata->num_batteries;
 
+	mbc->ac.name			= "ac";
+	mbc->ac.type			= POWER_SUPPLY_TYPE_MAINS;
+	mbc->ac.properties		= power_props;
+	mbc->ac.num_properties		= ARRAY_SIZE(power_props);
+	mbc->ac.get_property		= ac_get_property;
+	mbc->ac.supplied_to		= mbc->pcf->pdata->batteries;
+	mbc->ac.num_supplicants		= mbc->pcf->pdata->num_batteries;
+
 	ret = power_supply_register(&pdev->dev, &mbc->adapter);
 	if (ret) {
 		dev_err(mbc->pcf->dev, "failed to register adapter\n");
@@ -352,6 +386,15 @@ static int __devinit pcf50633_mbc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	ret = power_supply_register(&pdev->dev, &mbc->ac);
+	if (ret) {
+		dev_err(mbc->pcf->dev, "failed to register ac\n");
+		power_supply_unregister(&mbc->adapter);
+		power_supply_unregister(&mbc->usb);
+		kfree(mbc);
+		return ret;
+	}
+
 	INIT_DELAYED_WORK(&mbc->charging_restart_work,
 				pcf50633_mbc_charging_restart);
 
@@ -379,6 +422,7 @@ static int __devexit pcf50633_mbc_remove(struct platform_device *pdev)
 
 	power_supply_unregister(&mbc->usb);
 	power_supply_unregister(&mbc->adapter);
+	power_supply_unregister(&mbc->ac);
 
 	cancel_delayed_work_sync(&mbc->charging_restart_work);
 
-- 
1.6.4.4

[PATCH 2/6] power: pcf50633: introduces battery charging current control

[Paul Fertser]

From: Balaji Rao <balajirrao@openmoko.org>

Implement a new sysfs attribute to allow changing MBC charging limit on the
fly independently of usb current limit. It also gets set automatically
every time usb current limit is changed.

Limiting charging current also prevents violating USB specification in the
case when the whole device is shut down and usb current limit is reset to
the factory default by the pcf50633 state transition.

Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
 drivers/power/pcf50633-charger.c  |   78 ++++++++++++++++++++++++++++++++++--
 include/linux/mfd/pcf50633/core.h |    7 +++
 2 files changed, 80 insertions(+), 5 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index 48e92c0..21b6e64 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -48,16 +48,21 @@ int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
 	u8 bits;
 	int charging_start = 1;
 	u8 mbcs2, chgmod;
+	unsigned int mbcc5;
 
-	if (ma >= 1000)
+	if (ma >= 1000) {
 		bits = PCF50633_MBCC7_USB_1000mA;
-	else if (ma >= 500)
+		ma = 1000;
+	} else if (ma >= 500) {
 		bits = PCF50633_MBCC7_USB_500mA;
-	else if (ma >= 100)
+		ma = 500;
+	} else if (ma >= 100) {
 		bits = PCF50633_MBCC7_USB_100mA;
-	else {
+		ma = 100;
+	} else {
 		bits = PCF50633_MBCC7_USB_SUSPEND;
 		charging_start = 0;
+		ma = 0;
 	}
 
 	ret = pcf50633_reg_set_bit_mask(pcf, PCF50633_REG_MBCC7,
@@ -67,7 +72,24 @@ int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
 	else
 		dev_info(pcf->dev, "usb curlim to %d mA\n", ma);
 
-	/* Manual charging start */
+	/*
+	 * We limit the charging current to be the USB current limit.
+	 * The reason is that on pcf50633, when it enters PMU Standby mode,
+	 * which it does when the device goes "off", the USB current limit
+	 * reverts to the variant default.  In at least one common case, that
+	 * default is 500mA.  By setting the charging current to be the same
+	 * as the USB limit we set here before PMU standby, we enforce it only
+	 * using the correct amount of current even when the USB current limit
+	 * gets reset to the wrong thing
+	 */
+
+	if (mbc->pcf->pdata->charger_reference_current_ma) {
+		mbcc5 = (ma << 8) / mbc->pcf->pdata->charger_reference_current_ma;
+		if (mbcc5 > 255)
+			mbcc5 = 255;
+		pcf50633_reg_write(mbc->pcf, PCF50633_REG_MBCC5, mbcc5);
+	}
+
 	mbcs2 = pcf50633_reg_read(pcf, PCF50633_REG_MBCS2);
 	chgmod = (mbcs2 & PCF50633_MBCS2_MBC_MASK);
 
@@ -157,9 +179,55 @@ static ssize_t set_usblim(struct device *dev,
 
 static DEVICE_ATTR(usb_curlim, S_IRUGO | S_IWUSR, show_usblim, set_usblim);
 
+static ssize_t
+show_chglim(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct pcf50633_mbc *mbc = dev_get_drvdata(dev);
+	u8 mbcc5 = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCC5);
+	unsigned int ma;
+
+	if (!mbc->pcf->pdata->charger_reference_current_ma)
+		return -ENODEV;
+
+	ma = (mbc->pcf->pdata->charger_reference_current_ma *  mbcc5) >> 8;
+
+	return sprintf(buf, "%u\n", ma);
+}
+
+static ssize_t set_chglim(struct device *dev,
+		struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct pcf50633_mbc *mbc = dev_get_drvdata(dev);
+	unsigned long ma;
+	unsigned int mbcc5;
+	int ret;
+
+	if (!mbc->pcf->pdata->charger_reference_current_ma)
+		return -ENODEV;
+
+	ret = strict_strtoul(buf, 10, &ma);
+	if (ret)
+		return -EINVAL;
+
+	mbcc5 = (ma << 8) / mbc->pcf->pdata->charger_reference_current_ma;
+	if (mbcc5 > 255)
+		mbcc5 = 255;
+	pcf50633_reg_write(mbc->pcf, PCF50633_REG_MBCC5, mbcc5);
+
+	return count;
+}
+
+/*
+ * This attribute allows to change MBC charging limit on the fly
+ * independently of usb current limit. It also gets set automatically every
+ * time usb current limit is changed.
+ */
+static DEVICE_ATTR(chg_curlim, S_IRUGO | S_IWUSR, show_chglim, set_chglim);
+
 static struct attribute *pcf50633_mbc_sysfs_entries[] = {
 	&dev_attr_chgmode.attr,
 	&dev_attr_usb_curlim.attr,
+	&dev_attr_chg_curlim.attr,
 	NULL,
 };
 
diff --git a/include/linux/mfd/pcf50633/core.h b/include/linux/mfd/pcf50633/core.h
index 9aba7b7..09af8fd 100644
--- a/include/linux/mfd/pcf50633/core.h
+++ b/include/linux/mfd/pcf50633/core.h
@@ -31,6 +31,13 @@ struct pcf50633_platform_data {
 
 	int charging_restart_interval;
 
+	/*
+	 * Should be set accordingly to the reference resistor used, see
+	 * I_{ch(ref)} charger reference current in the pcf50633 User
+	 * Manual.
+	 */
+	int charger_reference_current_ma;
+
 	/* Callbacks */
 	void (*probe_done)(struct pcf50633 *);
 	void (*mbc_event_callback)(struct pcf50633 *, int);
-- 
1.6.4.4

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Paul Fertser]

From: Lars-Peter Clausen <lars@metafoo.de>

This value is board-specific and is needed for calculations to set charging
current limit properly.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---

Since this patch compile-depends on previous probably it should go through
the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
think is best.

Anton Vorontsov is ok with merging it through his tree but needs an explicit
ack.

 arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
index 0fb385b..b0a3d74 100644
--- a/arch/arm/mach-s3c2442/mach-gta02.c
+++ b/arch/arm/mach-s3c2442/mach-gta02.c
@@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
 
 	.batteries = gta02_batteries,
 	.num_batteries = ARRAY_SIZE(gta02_batteries),
+
+	.charger_reference_current_ma = 1000,
+
 	.reg_init_data = {
 		[PCF50633_REGULATOR_AUTO] = {
 			.constraints = {
-- 
1.6.4.4

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Paul Fertser]

From: Lars-Peter Clausen <lars@metafoo.de>

This value is board-specific and is needed for calculations to set charging
current limit properly.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---

Since this patch compile-depends on previous probably it should go through
the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
think is best.

Anton Vorontsov is ok with merging it through his tree but needs an explicit
ack.

 arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
index 0fb385b..b0a3d74 100644
--- a/arch/arm/mach-s3c2442/mach-gta02.c
+++ b/arch/arm/mach-s3c2442/mach-gta02.c
@@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
 
 	.batteries = gta02_batteries,
 	.num_batteries = ARRAY_SIZE(gta02_batteries),
+
+	.charger_reference_current_ma = 1000,
+
 	.reg_init_data = {
 		[PCF50633_REGULATOR_AUTO] = {
 			.constraints = {
-- 
1.6.4.4

[PATCH 4/6] power: pcf50633: get rid of charging restart software auto-triggering

[Paul Fertser]

After reaching Battery Full condition MBC state machine switches back
into charging mode when the battery voltage falls below 96% of a
battery float voltage. The voltage drop in Li-Ion batteries is
marginal (1-2%) till about 80% of its capacity - which means, after a
BATFULL, charging won't be restarted until 75-80%.

That is a desired behaviour recommended by battery manufacturers,
don't mess with it.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
 drivers/power/pcf50633-charger.c  |   46 -------------------------------------
 include/linux/mfd/pcf50633/core.h |    2 -
 2 files changed, 0 insertions(+), 48 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index 21b6e64..3383119 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -37,8 +37,6 @@ struct pcf50633_mbc {
 	struct power_supply usb;
 	struct power_supply adapter;
 	struct power_supply ac;
-
-	struct delayed_work charging_restart_work;
 };
 
 int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
@@ -236,44 +234,10 @@ static struct attribute_group mbc_attr_group = {
 	.attrs	= pcf50633_mbc_sysfs_entries,
 };
 
-/* MBC state machine switches into charging mode when the battery voltage
- * falls below 96% of a battery float voltage. But the voltage drop in Li-ion
- * batteries is marginal(1~2 %) till about 80% of its capacity - which means,
- * after a BATFULL, charging won't be restarted until 80%.
- *
- * This work_struct function restarts charging at regular intervals to make
- * sure we don't discharge too much
- */
-
-static void pcf50633_mbc_charging_restart(struct work_struct *work)
-{
-	struct pcf50633_mbc *mbc;
-	u8 mbcs2, chgmod;
-
-	mbc = container_of(work, struct pcf50633_mbc,
-				charging_restart_work.work);
-
-	mbcs2 = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCS2);
-	chgmod = (mbcs2 & PCF50633_MBCS2_MBC_MASK);
-
-	if (chgmod != PCF50633_MBCS2_MBC_BAT_FULL)
-		return;
-
-	/* Restart charging */
-	pcf50633_reg_set_bit_mask(mbc->pcf, PCF50633_REG_MBCC1,
-				PCF50633_MBCC1_RESUME, PCF50633_MBCC1_RESUME);
-	mbc->usb_active = 1;
-	power_supply_changed(&mbc->usb);
-
-	dev_info(mbc->pcf->dev, "Charging restarted\n");
-}
-
 static void
 pcf50633_mbc_irq_handler(int irq, void *data)
 {
 	struct pcf50633_mbc *mbc = data;
-	int chg_restart_interval =
-			mbc->pcf->pdata->charging_restart_interval;
 
 	/* USB */
 	if (irq == PCF50633_IRQ_USBINS) {
@@ -282,7 +246,6 @@ pcf50633_mbc_irq_handler(int irq, void *data)
 		mbc->usb_online = 0;
 		mbc->usb_active = 0;
 		pcf50633_mbc_usb_curlim_set(mbc->pcf, 0);
-		cancel_delayed_work_sync(&mbc->charging_restart_work);
 	}
 
 	/* Adapter */
@@ -297,10 +260,6 @@ pcf50633_mbc_irq_handler(int irq, void *data)
 	if (irq == PCF50633_IRQ_BATFULL) {
 		mbc->usb_active = 0;
 		mbc->adapter_active = 0;
-
-		if (chg_restart_interval > 0)
-			schedule_delayed_work(&mbc->charging_restart_work,
-							chg_restart_interval);
 	} else if (irq == PCF50633_IRQ_USBLIMON)
 		mbc->usb_active = 0;
 	else if (irq == PCF50633_IRQ_USBLIMOFF)
@@ -463,9 +422,6 @@ static int __devinit pcf50633_mbc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	INIT_DELAYED_WORK(&mbc->charging_restart_work,
-				pcf50633_mbc_charging_restart);
-
 	ret = sysfs_create_group(&pdev->dev.kobj, &mbc_attr_group);
 	if (ret)
 		dev_err(mbc->pcf->dev, "failed to create sysfs entries\n");
@@ -492,8 +448,6 @@ static int __devexit pcf50633_mbc_remove(struct platform_device *pdev)
 	power_supply_unregister(&mbc->adapter);
 	power_supply_unregister(&mbc->ac);
 
-	cancel_delayed_work_sync(&mbc->charging_restart_work);
-
 	kfree(mbc);
 
 	return 0;
diff --git a/include/linux/mfd/pcf50633/core.h b/include/linux/mfd/pcf50633/core.h
index 09af8fd..46df7f0 100644
--- a/include/linux/mfd/pcf50633/core.h
+++ b/include/linux/mfd/pcf50633/core.h
@@ -29,8 +29,6 @@ struct pcf50633_platform_data {
 	char **batteries;
 	int num_batteries;
 
-	int charging_restart_interval;
-
 	/*
 	 * Should be set accordingly to the reference resistor used, see
 	 * I_{ch(ref)} charger reference current in the pcf50633 User
-- 
1.6.4.4

[PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Paul Fertser]

If chgmod == BATFULL, setting chgena has no effect. Datasheet says we
need to set resume instead but when autoresume is used resume doesn't
work. Clear and set chgena instead.

This enables a user to force charging by re-plugging USB even when the
charger entered Battery Full mode, might be handy before a long trip.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
 drivers/power/pcf50633-charger.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index 3383119..4718733 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -92,14 +92,18 @@ int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
 	chgmod = (mbcs2 & PCF50633_MBCS2_MBC_MASK);
 
 	/* If chgmod == BATFULL, setting chgena has no effect.
-	 * We need to set resume instead.
+	 * Datasheet says we need to set resume instead but when autoresume is
+	 * used resume doesn't work. Clear and set chgena instead.
 	 */
 	if (chgmod != PCF50633_MBCS2_MBC_BAT_FULL)
 		pcf50633_reg_set_bit_mask(pcf, PCF50633_REG_MBCC1,
 				PCF50633_MBCC1_CHGENA, PCF50633_MBCC1_CHGENA);
-	else
+	else {
+		pcf50633_reg_clear_bits(pcf, PCF50633_REG_MBCC1,
+				PCF50633_MBCC1_CHGENA);
 		pcf50633_reg_set_bit_mask(pcf, PCF50633_REG_MBCC1,
-				PCF50633_MBCC1_RESUME, PCF50633_MBCC1_RESUME);
+				PCF50633_MBCC1_CHGENA, PCF50633_MBCC1_CHGENA);
+	}
 
 	mbc->usb_active = charging_start;
 
-- 
1.6.4.4

[PATCH 6/6] power: pcf50633: query charger status directly

[Paul Fertser]

Current scheme is fragile and is likely to go off sync, especially on
batfull->adapter charging automatic MBC transition.

Query the status bit every time we need it instead.

We need to export another function to query for USB presence because
we can't read anything from PCF50633 (via I2C) inside irq context and
that is needed by usb gadgets.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
 drivers/power/pcf50633-charger.c |   50 ++++++++++++++++++++++----------------
 include/linux/mfd/pcf50633/mbc.h |    1 +
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index 4718733..b915a00 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -29,9 +29,7 @@
 struct pcf50633_mbc {
 	struct pcf50633 *pcf;
 
-	int adapter_active;
 	int adapter_online;
-	int usb_active;
 	int usb_online;
 
 	struct power_supply usb;
@@ -88,7 +86,7 @@ int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
 		pcf50633_reg_write(mbc->pcf, PCF50633_REG_MBCC5, mbcc5);
 	}
 
-	mbcs2 = pcf50633_reg_read(pcf, PCF50633_REG_MBCS2);
+	mbcs2 = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCS2);
 	chgmod = (mbcs2 & PCF50633_MBCS2_MBC_MASK);
 
 	/* If chgmod == BATFULL, setting chgena has no effect.
@@ -105,8 +103,6 @@ int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma)
 				PCF50633_MBCC1_CHGENA, PCF50633_MBCC1_CHGENA);
 	}
 
-	mbc->usb_active = charging_start;
-
 	power_supply_changed(&mbc->usb);
 
 	return ret;
@@ -117,20 +113,44 @@ int pcf50633_mbc_get_status(struct pcf50633 *pcf)
 {
 	struct pcf50633_mbc *mbc  = platform_get_drvdata(pcf->mbc_pdev);
 	int status = 0;
+	u8 chgmod;
+
+	if (!mbc)
+		return 0;
+
+	chgmod = pcf50633_reg_read(mbc->pcf, PCF50633_REG_MBCS2)
+		& PCF50633_MBCS2_MBC_MASK;
 
 	if (mbc->usb_online)
 		status |= PCF50633_MBC_USB_ONLINE;
-	if (mbc->usb_active)
+	if (chgmod == PCF50633_MBCS2_MBC_USB_PRE ||
+	    chgmod == PCF50633_MBCS2_MBC_USB_PRE_WAIT ||
+	    chgmod == PCF50633_MBCS2_MBC_USB_FAST ||
+	    chgmod == PCF50633_MBCS2_MBC_USB_FAST_WAIT)
 		status |= PCF50633_MBC_USB_ACTIVE;
 	if (mbc->adapter_online)
 		status |= PCF50633_MBC_ADAPTER_ONLINE;
-	if (mbc->adapter_active)
+	if (chgmod == PCF50633_MBCS2_MBC_ADP_PRE ||
+	    chgmod == PCF50633_MBCS2_MBC_ADP_PRE_WAIT ||
+	    chgmod == PCF50633_MBCS2_MBC_ADP_FAST ||
+	    chgmod == PCF50633_MBCS2_MBC_ADP_FAST_WAIT)
 		status |= PCF50633_MBC_ADAPTER_ACTIVE;
 
 	return status;
 }
 EXPORT_SYMBOL_GPL(pcf50633_mbc_get_status);
 
+int pcf50633_mbc_get_usb_online_status(struct pcf50633 *pcf)
+{
+	struct pcf50633_mbc *mbc  = platform_get_drvdata(pcf->mbc_pdev);
+
+	if (!mbc)
+		return 0;
+
+	return mbc->usb_online;
+}
+EXPORT_SYMBOL_GPL(pcf50633_mbc_get_usb_online_status);
+
 static ssize_t
 show_chgmode(struct device *dev, struct device_attribute *attr, char *buf)
 {
@@ -248,26 +268,14 @@ pcf50633_mbc_irq_handler(int irq, void *data)
 		mbc->usb_online = 1;
 	} else if (irq == PCF50633_IRQ_USBREM) {
 		mbc->usb_online = 0;
-		mbc->usb_active = 0;
 		pcf50633_mbc_usb_curlim_set(mbc->pcf, 0);
 	}
 
 	/* Adapter */
-	if (irq == PCF50633_IRQ_ADPINS) {
+	if (irq == PCF50633_IRQ_ADPINS)
 		mbc->adapter_online = 1;
-		mbc->adapter_active = 1;
-	} else if (irq == PCF50633_IRQ_ADPREM) {
+	else if (irq == PCF50633_IRQ_ADPREM)
 		mbc->adapter_online = 0;
-		mbc->adapter_active = 0;
-	}
-
-	if (irq == PCF50633_IRQ_BATFULL) {
-		mbc->usb_active = 0;
-		mbc->adapter_active = 0;
-	} else if (irq == PCF50633_IRQ_USBLIMON)
-		mbc->usb_active = 0;
-	else if (irq == PCF50633_IRQ_USBLIMOFF)
-		mbc->usb_active = 1;
 
 	power_supply_changed(&mbc->ac);
 	power_supply_changed(&mbc->usb);
diff --git a/include/linux/mfd/pcf50633/mbc.h b/include/linux/mfd/pcf50633/mbc.h
index 4119579..df4f5fa 100644
--- a/include/linux/mfd/pcf50633/mbc.h
+++ b/include/linux/mfd/pcf50633/mbc.h
@@ -128,6 +128,7 @@ enum pcf50633_reg_mbcs3 {
 int pcf50633_mbc_usb_curlim_set(struct pcf50633 *pcf, int ma);
 
 int pcf50633_mbc_get_status(struct pcf50633 *);
+int pcf50633_mbc_get_usb_online_status(struct pcf50633 *);
 
 #endif
 
-- 
1.6.4.4

Re: [PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Pavel Machek]

On Thu 2009-11-05 00:24:58, Paul Fertser wrote:
> If chgmod == BATFULL, setting chgena has no effect. Datasheet says we
> need to set resume instead but when autoresume is used resume doesn't
> work. Clear and set chgena instead.
> 
> This enables a user to force charging by re-plugging USB even when the
> charger entered Battery Full mode, might be handy before a long
> trip.

And is against manufacturer recommendation and will unneccessary
shorted life of battery with frequent plugs/unplugs. Is it good idea?

If you want to "top-up" the battery, perhaps that should be on
explicit request, like something in /sys?
								Pavel




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

Re: [PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Paul Fertser]

Hi,

On Wed, Nov 04, 2009 at 10:46:22PM +0100, Pavel Machek wrote:
> On Thu 2009-11-05 00:24:58, Paul Fertser wrote:
> > If chgmod == BATFULL, setting chgena has no effect. Datasheet says we
> > need to set resume instead but when autoresume is used resume doesn't
> > work. Clear and set chgena instead.
> > 
> > This enables a user to force charging by re-plugging USB even when the
> > charger entered Battery Full mode, might be handy before a long
> > trip.
> 
> And is against manufacturer recommendation and will unneccessary
> shorted life of battery with frequent plugs/unplugs. Is it good idea?

Well, to me it seems that frequent plugs/unplugs is not exactly common
usecase so i consider that to be acceptable.

Especially comparing to millions of laptops and netbooks that always
top their battery while being externally powered and heat it at the
same time, probably the worst conditions lifetime-wise one can
imagine.

> If you want to "top-up" the battery, perhaps that should be on
> explicit request, like something in /sys?

Well, probably but to me it seems like an unnecessary complexity. Also
since Li* batteries are dominating the market nowadays this
functionality would need to be introduced in the power_supply core to
provide userspace with a consistent interface. Anton, can you please
comment on this?

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

Re: [PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Pavel Machek]

On Thu 2009-11-05 01:24:31, Paul Fertser wrote:
> Hi,
> 
> On Wed, Nov 04, 2009 at 10:46:22PM +0100, Pavel Machek wrote:
> > On Thu 2009-11-05 00:24:58, Paul Fertser wrote:
> > > If chgmod == BATFULL, setting chgena has no effect. Datasheet says we
> > > need to set resume instead but when autoresume is used resume doesn't
> > > work. Clear and set chgena instead.
> > > 
> > > This enables a user to force charging by re-plugging USB even when the
> > > charger entered Battery Full mode, might be handy before a long
> > > trip.
> > 
> > And is against manufacturer recommendation and will unneccessary
> > shorted life of battery with frequent plugs/unplugs. Is it good idea?
> 
> Well, to me it seems that frequent plugs/unplugs is not exactly common
> usecase so i consider that to be acceptable.

Well, they are quite common here with my HTC Dream at least (I'm not
sure what your device is). Often, I unplug it from 1A charger to
connect it to PC for file transfer, and back.

> Especially comparing to millions of laptops and netbooks that always
> top their battery while being externally powered and heat it at the
> same time, probably the worst conditions lifetime-wise one can
> imagine.

Well, at least thinkpads will not start charging the battery when over
95%. (And the limit is configurable).

> > If you want to "top-up" the battery, perhaps that should be on
> > explicit request, like something in /sys?
> 
> Well, probably but to me it seems like an unnecessary complexity. 

And leaving behaviour before patch, that is "do not charge if battery
is over 80%" -- AFAICT from the changelog.

>Also
> since Li* batteries are dominating the market nowadays this
> functionality would need to be introduced in the power_supply core to
> provide userspace with a consistent interface. Anton, can you please
> comment on this?

I agree that it is not important part of functionality, but at least
Dream, Spitz and Collie could use that support....
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Anton Vorontsov]

On Thu, Nov 05, 2009 at 01:24:31AM +0300, Paul Fertser wrote:
[...]
> > If you want to "top-up" the battery, perhaps that should be on
> > explicit request, like something in /sys?
> 
> Well, probably but to me it seems like an unnecessary complexity. Also
> since Li* batteries are dominating the market nowadays this
> functionality would need to be introduced in the power_supply core to
> provide userspace with a consistent interface. Anton, can you please
> comment on this?

Power supply class doesn't have writeable properties (initially
it was a 'battery monitor class'). Though. I'd happily merge
the support for writeable properties. ACPI batteries would
benefit too, i.e. they could export 'alarm' property (see
drivers/acpi/battery.c).

Though, I'd want to apply this patch set as is (i.e. I prefer 
the new behaviour, as it's really more 'user friendly'), and
we could implement configurable option later.

Pavel do you have a strong objection against this patch, or
you can live with it? :-)

Thanks!

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH 5/6] power: pcf50633: properly reenable charging when the supply conditions change

[Pavel Machek]

On Thu 2009-11-05 02:45:19, Anton Vorontsov wrote:
> On Thu, Nov 05, 2009 at 01:24:31AM +0300, Paul Fertser wrote:
> [...]
> > > If you want to "top-up" the battery, perhaps that should be on
> > > explicit request, like something in /sys?
> > 
> > Well, probably but to me it seems like an unnecessary complexity. Also
> > since Li* batteries are dominating the market nowadays this
> > functionality would need to be introduced in the power_supply core to
> > provide userspace with a consistent interface. Anton, can you please
> > comment on this?
> 
> Power supply class doesn't have writeable properties (initially
> it was a 'battery monitor class'). Though. I'd happily merge
> the support for writeable properties. ACPI batteries would
> benefit too, i.e. they could export 'alarm' property (see
> drivers/acpi/battery.c).

Yep, writable properties would be nice for at least Spitz and
Openmoko. Both of them have slow and fast charging modes, and
sometimes user will need to override the default.

> Though, I'd want to apply this patch set as is (i.e. I prefer 
> the new behaviour, as it's really more 'user friendly'), and
> we could implement configurable option later.
> 
> Pavel do you have a strong objection against this patch, or
> you can live with it? :-)

I can live with it... but thanks for asking :-).

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

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Paul Fertser]

Hi,

Ben, please give us an advice on how to proceed with this rather
trivial patch. Anton doesn't merge the other patches from this series
because we do not know via which tree to merge this particular patch.

On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> From: Lars-Peter Clausen <lars@metafoo.de>
> 
> This value is board-specific and is needed for calculations to set charging
> current limit properly.
> 
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> 
> Since this patch compile-depends on previous probably it should go through
> the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> think is best.
> 
> Anton Vorontsov is ok with merging it through his tree but needs an explicit
> ack.
> 
>  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> index 0fb385b..b0a3d74 100644
> --- a/arch/arm/mach-s3c2442/mach-gta02.c
> +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>  
>  	.batteries = gta02_batteries,
>  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> +
> +	.charger_reference_current_ma = 1000,
> +
>  	.reg_init_data = {
>  		[PCF50633_REGULATOR_AUTO] = {
>  			.constraints = {
> -- 
> 1.6.4.4
> 

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Paul Fertser]

Hi,

Ben, please give us an advice on how to proceed with this rather
trivial patch. Anton doesn't merge the other patches from this series
because we do not know via which tree to merge this particular patch.

On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> From: Lars-Peter Clausen <lars@metafoo.de>
> 
> This value is board-specific and is needed for calculations to set charging
> current limit properly.
> 
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> 
> Since this patch compile-depends on previous probably it should go through
> the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> think is best.
> 
> Anton Vorontsov is ok with merging it through his tree but needs an explicit
> ack.
> 
>  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> index 0fb385b..b0a3d74 100644
> --- a/arch/arm/mach-s3c2442/mach-gta02.c
> +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
>  
>  	.batteries = gta02_batteries,
>  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> +
> +	.charger_reference_current_ma = 1000,
> +
>  	.reg_init_data = {
>  		[PCF50633_REGULATOR_AUTO] = {
>  			.constraints = {
> -- 
> 1.6.4.4
> 

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Anton Vorontsov]

On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> Hi,
> 
> Ben, please give us an advice on how to proceed with this rather
> trivial patch. Anton doesn't merge the other patches from this series
> because we do not know via which tree to merge this particular patch.

Paul, I'll just merge the whole patch set but skip this particular
patch.

Thanks,

> On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> > From: Lars-Peter Clausen <lars@metafoo.de>
> > 
> > This value is board-specific and is needed for calculations to set charging
> > current limit properly.
> > 
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> > Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > 
> > Since this patch compile-depends on previous probably it should go through
> > the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> > think is best.
> > 
> > Anton Vorontsov is ok with merging it through his tree but needs an explicit
> > ack.
> > 
> >  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> > index 0fb385b..b0a3d74 100644
> > --- a/arch/arm/mach-s3c2442/mach-gta02.c
> > +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> > @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >  
> >  	.batteries = gta02_batteries,
> >  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> > +
> > +	.charger_reference_current_ma = 1000,
> > +
> >  	.reg_init_data = {
> >  		[PCF50633_REGULATOR_AUTO] = {
> >  			.constraints = {
> > -- 
> > 1.6.4.4
> > 
> 
> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav@gmail.com
> 

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Anton Vorontsov]

On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> Hi,
> 
> Ben, please give us an advice on how to proceed with this rather
> trivial patch. Anton doesn't merge the other patches from this series
> because we do not know via which tree to merge this particular patch.

Paul, I'll just merge the whole patch set but skip this particular
patch.

Thanks,

> On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> > From: Lars-Peter Clausen <lars@metafoo.de>
> > 
> > This value is board-specific and is needed for calculations to set charging
> > current limit properly.
> > 
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> > Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > 
> > Since this patch compile-depends on previous probably it should go through
> > the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> > think is best.
> > 
> > Anton Vorontsov is ok with merging it through his tree but needs an explicit
> > ack.
> > 
> >  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> > index 0fb385b..b0a3d74 100644
> > --- a/arch/arm/mach-s3c2442/mach-gta02.c
> > +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> > @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >  
> >  	.batteries = gta02_batteries,
> >  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> > +
> > +	.charger_reference_current_ma = 1000,
> > +
> >  	.reg_init_data = {
> >  		[PCF50633_REGULATOR_AUTO] = {
> >  			.constraints = {
> > -- 
> > 1.6.4.4
> > 
> 
> -- 
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav at gmail.com
> 

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Pavel Machek]

On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > Hi,
> > 
> > Ben, please give us an advice on how to proceed with this rather
> > trivial patch. Anton doesn't merge the other patches from this series
> > because we do not know via which tree to merge this particular patch.
> 
> Paul, I'll just merge the whole patch set but skip this particular
> patch.

Feel free to merge that patch, too. It is clearly related to the
other stuff, and Russell being totally unresponsive should not be
reason to block patches.

He is the maintainer, he was cc-ed, and at this point it is quite
clear that he does not care.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Pavel Machek]

On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > Hi,
> > 
> > Ben, please give us an advice on how to proceed with this rather
> > trivial patch. Anton doesn't merge the other patches from this series
> > because we do not know via which tree to merge this particular patch.
> 
> Paul, I'll just merge the whole patch set but skip this particular
> patch.

Feel free to merge that patch, too. It is clearly related to the
other stuff, and Russell being totally unresponsive should not be
reason to block patches.

He is the maintainer, he was cc-ed, and at this point it is quite
clear that he does not care.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Russell King - ARM Linux]

On Thu, Nov 12, 2009 at 08:40:59AM +0100, Pavel Machek wrote:
> On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> > On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > > Hi,
> > > 
> > > Ben, please give us an advice on how to proceed with this rather
> > > trivial patch. Anton doesn't merge the other patches from this series
> > > because we do not know via which tree to merge this particular patch.
> > 
> > Paul, I'll just merge the whole patch set but skip this particular
> > patch.
> 
> Feel free to merge that patch, too. It is clearly related to the
> other stuff, and Russell being totally unresponsive should not be
> reason to block patches.
> 
> He is the maintainer, he was cc-ed, and at this point it is quite
> clear that he does not care.

Err, WTF?  How do you come to the conclusion that I'm somehow related
to Samsung stuff, or GTA03 stuff?  Oh, that's right, you don't let facts
get in the way of blaming me for something.

The GTA03 stuff is Samsung stuff.  I've never had much to do with
Samsung stuff.  I'm certainly not the maintainer for it - that's
Ben Dooks domain.

I've been ignoring this because as far as I can see, it's got nothing
to do with me, and therefore its pointless me acking it.

Really Pavel, just take a moment to get your facts straight before you
start blaming people.

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Russell King - ARM Linux]

On Thu, Nov 12, 2009 at 08:40:59AM +0100, Pavel Machek wrote:
> On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> > On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > > Hi,
> > > 
> > > Ben, please give us an advice on how to proceed with this rather
> > > trivial patch. Anton doesn't merge the other patches from this series
> > > because we do not know via which tree to merge this particular patch.
> > 
> > Paul, I'll just merge the whole patch set but skip this particular
> > patch.
> 
> Feel free to merge that patch, too. It is clearly related to the
> other stuff, and Russell being totally unresponsive should not be
> reason to block patches.
> 
> He is the maintainer, he was cc-ed, and at this point it is quite
> clear that he does not care.

Err, WTF?  How do you come to the conclusion that I'm somehow related
to Samsung stuff, or GTA03 stuff?  Oh, that's right, you don't let facts
get in the way of blaming me for something.

The GTA03 stuff is Samsung stuff.  I've never had much to do with
Samsung stuff.  I'm certainly not the maintainer for it - that's
Ben Dooks domain.

I've been ignoring this because as far as I can see, it's got nothing
to do with me, and therefore its pointless me acking it.

Really Pavel, just take a moment to get your facts straight before you
start blaming people.

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Pavel Machek]

On Thu 2009-11-12 21:59:47, Russell King - ARM Linux wrote:
> On Thu, Nov 12, 2009 at 08:40:59AM +0100, Pavel Machek wrote:
> > On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> > > On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > > > Hi,
> > > > 
> > > > Ben, please give us an advice on how to proceed with this rather
> > > > trivial patch. Anton doesn't merge the other patches from this series
> > > > because we do not know via which tree to merge this particular patch.
> > > 
> > > Paul, I'll just merge the whole patch set but skip this particular
> > > patch.
> > 
> > Feel free to merge that patch, too. It is clearly related to the
> > other stuff, and Russell being totally unresponsive should not be
> > reason to block patches.
> > 
> > He is the maintainer, he was cc-ed, and at this point it is quite
> > clear that he does not care.
> 
> Err, WTF?  How do you come to the conclusion that I'm somehow related
> to Samsung stuff, or GTA03 stuff?  Oh, that's right, you don't let facts
> get in the way of blaming me for something.

Ok, you are right, Ben is listed as Samsung maintainer. Accept my
apologies. The rest stands: Anton should just take the patch, because
maintainer does not care.

Actually, given that Ben is unresponsive, it should be either you or
Anton taking the patch; so if you prefer, you can take it.

> I've been ignoring this because as far as I can see, it's got nothing
> to do with me, and therefore its pointless me acking it.
> 
> Really Pavel, just take a moment to get your facts straight before you
> start blaming people.

Now, you still are arm maintainer, and that includes arch-msm. There's
nice series in your inbox for week+ -- HTC Dream support. There's also
Daniel Walker who is willing to maintain the architecture. Can we get
the patches applied (or some other decision?).  Pavel

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

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Pavel Machek]

On Thu 2009-11-12 21:59:47, Russell King - ARM Linux wrote:
> On Thu, Nov 12, 2009 at 08:40:59AM +0100, Pavel Machek wrote:
> > On Wed 2009-11-11 18:31:43, Anton Vorontsov wrote:
> > > On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> > > > Hi,
> > > > 
> > > > Ben, please give us an advice on how to proceed with this rather
> > > > trivial patch. Anton doesn't merge the other patches from this series
> > > > because we do not know via which tree to merge this particular patch.
> > > 
> > > Paul, I'll just merge the whole patch set but skip this particular
> > > patch.
> > 
> > Feel free to merge that patch, too. It is clearly related to the
> > other stuff, and Russell being totally unresponsive should not be
> > reason to block patches.
> > 
> > He is the maintainer, he was cc-ed, and at this point it is quite
> > clear that he does not care.
> 
> Err, WTF?  How do you come to the conclusion that I'm somehow related
> to Samsung stuff, or GTA03 stuff?  Oh, that's right, you don't let facts
> get in the way of blaming me for something.

Ok, you are right, Ben is listed as Samsung maintainer. Accept my
apologies. The rest stands: Anton should just take the patch, because
maintainer does not care.

Actually, given that Ben is unresponsive, it should be either you or
Anton taking the patch; so if you prefer, you can take it.

> I've been ignoring this because as far as I can see, it's got nothing
> to do with me, and therefore its pointless me acking it.
> 
> Really Pavel, just take a moment to get your facts straight before you
> start blaming people.

Now, you still are arm maintainer, and that includes arch-msm. There's
nice series in your inbox for week+ -- HTC Dream support. There's also
Daniel Walker who is willing to maintain the architecture. Can we get
the patches applied (or some other decision?).  Pavel

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

Re: [PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Anton Vorontsov]

On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> Hi,

Paul, thanks a lot for your work!

> Ben, please give us an advice on how to proceed with this rather
> trivial patch. Anton doesn't merge the other patches from this series
> because we do not know via which tree to merge this particular patch.

OK, a) the patch is trivial; b) signed off and acked by people who
cares about and actually use gta devices; c) we can't wait forever
(a month, that is), even though we do realize maintainers could be
busy.

So, I've applied this patch to battery-2.6.git. Ben, I hope you're
fine with it.

Thanks,

> On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> > From: Lars-Peter Clausen <lars@metafoo.de>
> > 
> > This value is board-specific and is needed for calculations to set charging
> > current limit properly.
> > 
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> > Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > 
> > Since this patch compile-depends on previous probably it should go through
> > the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> > think is best.
> > 
> > Anton Vorontsov is ok with merging it through his tree but needs an explicit
> > ack.
> > 
> >  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> > index 0fb385b..b0a3d74 100644
> > --- a/arch/arm/mach-s3c2442/mach-gta02.c
> > +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> > @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >  
> >  	.batteries = gta02_batteries,
> >  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> > +
> > +	.charger_reference_current_ma = 1000,
> > +
> >  	.reg_init_data = {
> >  		[PCF50633_REGULATOR_AUTO] = {
> >  			.constraints = {
> > -- 
> > 1.6.4.4
> > 

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

[PATCH 3/6] gta02: set pcf50633 charger_reference_current_ma

[Anton Vorontsov]

On Wed, Nov 11, 2009 at 04:48:44PM +0300, Paul Fertser wrote:
> Hi,

Paul, thanks a lot for your work!

> Ben, please give us an advice on how to proceed with this rather
> trivial patch. Anton doesn't merge the other patches from this series
> because we do not know via which tree to merge this particular patch.

OK, a) the patch is trivial; b) signed off and acked by people who
cares about and actually use gta devices; c) we can't wait forever
(a month, that is), even though we do realize maintainers could be
busy.

So, I've applied this patch to battery-2.6.git. Ben, I hope you're
fine with it.

Thanks,

> On Thu, Nov 05, 2009 at 12:24:56AM +0300, Paul Fertser wrote:
> > From: Lars-Peter Clausen <lars@metafoo.de>
> > 
> > This value is board-specific and is needed for calculations to set charging
> > current limit properly.
> > 
> > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > Acked-by: Nelson Castillo <arhuaco@freaks-unidos.net>
> > Signed-off-by: Paul Fertser <fercerpav@gmail.com>
> > Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > 
> > Since this patch compile-depends on previous probably it should go through
> > the same tree as others. Nelson (gta02 maintainer) agrees with whatever you
> > think is best.
> > 
> > Anton Vorontsov is ok with merging it through his tree but needs an explicit
> > ack.
> > 
> >  arch/arm/mach-s3c2442/mach-gta02.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-s3c2442/mach-gta02.c b/arch/arm/mach-s3c2442/mach-gta02.c
> > index 0fb385b..b0a3d74 100644
> > --- a/arch/arm/mach-s3c2442/mach-gta02.c
> > +++ b/arch/arm/mach-s3c2442/mach-gta02.c
> > @@ -268,6 +268,9 @@ struct pcf50633_platform_data gta02_pcf_pdata = {
> >  
> >  	.batteries = gta02_batteries,
> >  	.num_batteries = ARRAY_SIZE(gta02_batteries),
> > +
> > +	.charger_reference_current_ma = 1000,
> > +
> >  	.reg_init_data = {
> >  		[PCF50633_REGULATOR_AUTO] = {
> >  			.constraints = {
> > -- 
> > 1.6.4.4
> > 

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2