| Message ID | ZAcvuP8kmWveLoE/@duo.ucw.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Motorola Droid 4 -- Stopping charger when battery is full | expand |
Hi, On 7.03.23 г. 14:36 ч., Pavel Machek wrote: > Hi! > > I complained that "battery life is very poor" with leste. It seems to > be combination of several factors. > > 1) I was using very old battery > > 2) My charger is detected as "USB", not as "AC" > And this is because there is no working charger detection in the driver, so initial current limit is hard-coded to 500mA. I was on it, but had to suspend, partially because of https://lore.kernel.org/lkml/1668430562-27114-1-git-send-email-ivo.g.dimitrov.75@gmail.com/#r , which I will have to fix by other means. OTOH, I have cpcap-extcon driver around which does charger detection and sends the appropriate events, along with cpcap-charger patches that properly limit the charger current, however, until the issue in charger framework is fixed those are of no use. Didn't have enough spare time lately to resume the work :( > 3) Charger was cycling on/off, which was annoying and I often ending > up dissconnecting the charger > > 4) It probably has a bit higher power consuption than original android > > 5) Android is more aggressive, charges to 4.35V, and allows deeper > discharge > We can't charge to 4.35 without knowing the type of the battery, unfortunately https://lore.kernel.org/all/1667332425-12536-1-git-send-email-ivo.g.dimitrov.75@gmail.com/T/#t didn't make it, for reasons unknown to me. Yes, we have that in leste kernel, but I am getting sick of supporting out-of-tree patches, so I don't really want to build userspace on kernel features that are not upstream, if possible. Also, some guys have concerns about charging (and keeping it charged) @4.35, because of the possibly reduced battery life. > According to my measurements "CPCAP_REG_CRM_FET_OVRD | > CPCAP_REG_CRM_FET_CTRL" results in battery discharding and 0A drawn > frmo the USB. "CPCAP_REG_CRM_FET_OVRD" is phone powered from USB, > with battery more or less disconnected (<12mA), which is what we want > in battery full situation. > What will happen if phone needs to draw more than N mA (N is the set charger current limit)? > Second problem was that phone never really stayed in "battery full", > immediately exiting it. > > This should solve both issues (plus it enables a lot of > debugging). > Thanks and regards, Ivo > Best regards, > Pavel > > Signed-off-by: Pavel Machek <pavel@ucw.cz> > > diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c > index 8bd1abe246cc..af268fc87fbf 100644 > --- a/drivers/power/supply/cpcap-charger.c > +++ b/drivers/power/supply/cpcap-charger.c > @@ -10,6 +10,7 @@ > * Copyright (C) 2009-2010 Motorola, Inc. > */ > > +#define DEBUG > #include <linux/atomic.h> > #include <linux/init.h> > #include <linux/module.h> > @@ -410,8 +411,7 @@ static int cpcap_charger_disable(struct cpcap_charger_ddata *ddata) > int error; > > error = regmap_update_bits(ddata->reg, CPCAP_REG_CRM, 0x3fff, > - CPCAP_REG_CRM_FET_OVRD | > - CPCAP_REG_CRM_FET_CTRL); > + CPCAP_REG_CRM_FET_OVRD); > if (error) > dev_err(ddata->dev, "%s failed with %i\n", __func__, error); > > @@ -686,8 +686,11 @@ static void cpcap_usb_detect(struct work_struct *work) > if (error) > return; > > + dev_dbg(ddata->dev, "%d %d %d %d\n", s.chrg_det, s.chrgcurr1, s.chrgcurr2, s.vbusvld); > + > /* Just init the state if a charger is connected with no chrg_det set */ > if (!s.chrg_det && s.chrgcurr1 && s.vbusvld) { > + printk("Just init -- not chrg_det\n"); > cpcap_charger_update_state(ddata, > POWER_SUPPLY_STATUS_NOT_CHARGING); > > @@ -699,6 +702,7 @@ static void cpcap_usb_detect(struct work_struct *work) > * charged to 4.35V by Android. Try again in 10 minutes. > */ > if (cpcap_charger_get_charge_voltage(ddata) > ddata->voltage) { > + printk("Battery overcharged, wait\n"); > cpcap_charger_disconnect(ddata, > POWER_SUPPLY_STATUS_NOT_CHARGING, > HZ * 60 * 10); > @@ -713,14 +717,24 @@ static void cpcap_usb_detect(struct work_struct *work) > break; > new_state = POWER_SUPPLY_STATUS_FULL; > > + printk("No current -> we are done\n"); > + > if (s.chrgcurr1 && s.vbusvld) { > cpcap_charger_disconnect(ddata, new_state, HZ * 5); > return; > } > break; > case POWER_SUPPLY_STATUS_FULL: > + if (s.vbusvld) { > + printk("Full, stay full\n"); > + schedule_delayed_work(&ddata->detect_work, HZ * 10); > + return; > + } > if (!s.chrgcurr2) > break; > + > + printk("Full but we need to do something\n"); > + > if (s.vbusvld) > new_state = POWER_SUPPLY_STATUS_NOT_CHARGING; > else > @@ -762,6 +776,7 @@ static void cpcap_usb_detect(struct work_struct *work) > if (!delayed_work_pending(&ddata->ramp_work)) > schedule_delayed_work(&ddata->ramp_work, HZ/20); > } else { > + printk("No feeding bus, disabling\n"); > ddata->set_current = 0; > error = cpcap_charger_disable(ddata); > if (error) >
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [230307 14:10]: > Also, some guys have concerns about charging (and keeping it charged) @4.35, > because of the possibly reduced battery life. Yes for devices connected to a charger for long periods the battery will bloat up within some weeks or months. This happens easily when using a lapdock for example. A simple and safe solution here might be that we allow charging up to 4.35V only once when the charger is connected. Then we let the voltage decrease to 4.2V (or whatever known good maintenance voltage) if the charger stays connected. For folks wanting to force the charge voltage higher we have the sysfs interface. Regards, Tony
Hi! So I believe I found out reason to high power consumption -- web browser. It is really easy to leave it running, and power consumption goes from 0.05A to 0.15A to roof depending on website. With the fix to stop charging on battery full, it is nice enough to use on daily basis. But there are still few problems: 1) Booting with empty battery will result in Maemo booting then immediately shutting down, discharging battery all the time. 2) Enabling bluetooth and leaving it enabled overnight will result in so many oopses it fills root filesystem with syslog. 3) When root filesystem is full on boot, it results in hang with black screen. (And yes, today I hit 2) which let to empty battery and 3).) Best regards, Pavel
Hi! > > I complained that "battery life is very poor" with leste. It seems to > > be combination of several factors. > > > > 1) I was using very old battery > > > > 2) My charger is detected as "USB", not as "AC" > > > > And this is because there is no working charger detection in the driver, so > initial current limit is hard-coded to 500mA. Aha, thanks, makes sense. > > According to my measurements "CPCAP_REG_CRM_FET_OVRD | > > CPCAP_REG_CRM_FET_CTRL" results in battery discharding and 0A drawn > > frmo the USB. "CPCAP_REG_CRM_FET_OVRD" is phone powered from USB, > > with battery more or less disconnected (<12mA), which is what we want > > in battery full situation. > > > > What will happen if phone needs to draw more than N mA (N is the set charger > current limit)? We may run over the limit, AFAICT. I guess one solution would be to only do this when limit is high enough... With current setup, phone will not boot if battery is empty, so this needs quite urgent solution. I updated my leste, and now have: user@devuan-droid4:~/g/droid4-linux$ uname -a Linux devuan-droid4 6.1.9 #1 SMP PREEMPT Mon Mar 20 15:16:53 UTC 2023 armv7l GNU/Linux user@devuan-droid4:~/g$ apt show linux-image-omap Package: linux-image-omap Version: 6.1.8.0-1+m7 Where can I find corresponding sources? Best regards, Pavel
> * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [230307 14:10]: > > Also, some guys have concerns about charging (and keeping it charged) @4.35, > > because of the possibly reduced battery life. > > Yes for devices connected to a charger for long periods the battery will > bloat up within some weeks or months. This happens easily when using a > lapdock for example. > > A simple and safe solution here might be that we allow charging up to > 4.35V only once when the charger is connected. Then we let the voltage > decrease to 4.2V (or whatever known good maintenance voltage) if the > charger stays connected. Optimum solution would be user specifying "I want battery full tommorow at 8am" and doing the right thing. > For folks wanting to force the charge voltage higher we have the sysfs > interface. Yep, we just need to make sure it is usable for this. Best regards, Pavel
* Pavel Machek <pavel@ucw.cz> [230413 09:37]: > > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [230307 14:10]: > > > Also, some guys have concerns about charging (and keeping it charged) @4.35, > > > because of the possibly reduced battery life. > > > > Yes for devices connected to a charger for long periods the battery will > > bloat up within some weeks or months. This happens easily when using a > > lapdock for example. > > > > A simple and safe solution here might be that we allow charging up to > > 4.35V only once when the charger is connected. Then we let the voltage > > decrease to 4.2V (or whatever known good maintenance voltage) if the > > charger stays connected. > > Optimum solution would be user specifying "I want battery full > tommorow at 8am" and doing the right thing. I think you can already do that via sysfs with cron or at :) > > For folks wanting to force the charge voltage higher we have the sysfs > > interface. > > Yep, we just need to make sure it is usable for this. It should be but I have not tried for years. You need to first configure the allowed voltage for battery via sysfs, then set the charge voltage for the charger. Regards, Tony
On 13.04.23 г. 12:34 ч., Pavel Machek wrote: > Hi! > >>> I complained that "battery life is very poor" with leste. It seems to >>> be combination of several factors. >>> >>> 1) I was using very old battery >>> >>> 2) My charger is detected as "USB", not as "AC" >>> >> >> And this is because there is no working charger detection in the driver, so >> initial current limit is hard-coded to 500mA. > > Aha, thanks, makes sense. > >>> According to my measurements "CPCAP_REG_CRM_FET_OVRD | >>> CPCAP_REG_CRM_FET_CTRL" results in battery discharding and 0A drawn >>> frmo the USB. "CPCAP_REG_CRM_FET_OVRD" is phone powered from USB, >>> with battery more or less disconnected (<12mA), which is what we want >>> in battery full situation. >>> >> >> What will happen if phone needs to draw more than N mA (N is the set charger >> current limit)? > > We may run over the limit, AFAICT. I guess one solution would be to > only do this when limit is high enough... > > With current setup, phone will not boot if battery is empty, so this > needs quite urgent solution. > > I updated my leste, and now have: > > user@devuan-droid4:~/g/droid4-linux$ uname -a > Linux devuan-droid4 6.1.9 #1 SMP PREEMPT Mon Mar 20 15:16:53 UTC 2023 armv7l GNU/Linux > user@devuan-droid4:~/g$ apt show linux-image-omap > Package: linux-image-omap > Version: 6.1.8.0-1+m7 > > Where can I find corresponding sources? > https://github.com/maemo-leste/droid4-linux/tree/maemo-6.1.y > Best regards, > Pavel >
diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c index 8bd1abe246cc..af268fc87fbf 100644 --- a/drivers/power/supply/cpcap-charger.c +++ b/drivers/power/supply/cpcap-charger.c @@ -10,6 +10,7 @@ * Copyright (C) 2009-2010 Motorola, Inc. */ +#define DEBUG #include <linux/atomic.h> #include <linux/init.h> #include <linux/module.h> @@ -410,8 +411,7 @@ static int cpcap_charger_disable(struct cpcap_charger_ddata *ddata) int error; error = regmap_update_bits(ddata->reg, CPCAP_REG_CRM, 0x3fff, - CPCAP_REG_CRM_FET_OVRD | - CPCAP_REG_CRM_FET_CTRL); + CPCAP_REG_CRM_FET_OVRD); if (error) dev_err(ddata->dev, "%s failed with %i\n", __func__, error); @@ -686,8 +686,11 @@ static void cpcap_usb_detect(struct work_struct *work) if (error) return; + dev_dbg(ddata->dev, "%d %d %d %d\n", s.chrg_det, s.chrgcurr1, s.chrgcurr2, s.vbusvld); + /* Just init the state if a charger is connected with no chrg_det set */ if (!s.chrg_det && s.chrgcurr1 && s.vbusvld) { + printk("Just init -- not chrg_det\n"); cpcap_charger_update_state(ddata, POWER_SUPPLY_STATUS_NOT_CHARGING); @@ -699,6 +702,7 @@ static void cpcap_usb_detect(struct work_struct *work) * charged to 4.35V by Android. Try again in 10 minutes. */ if (cpcap_charger_get_charge_voltage(ddata) > ddata->voltage) { + printk("Battery overcharged, wait\n"); cpcap_charger_disconnect(ddata, POWER_SUPPLY_STATUS_NOT_CHARGING, HZ * 60 * 10); @@ -713,14 +717,24 @@ static void cpcap_usb_detect(struct work_struct *work) break; new_state = POWER_SUPPLY_STATUS_FULL; + printk("No current -> we are done\n"); + if (s.chrgcurr1 && s.vbusvld) { cpcap_charger_disconnect(ddata, new_state, HZ * 5); return; } break; case POWER_SUPPLY_STATUS_FULL: + if (s.vbusvld) { + printk("Full, stay full\n"); + schedule_delayed_work(&ddata->detect_work, HZ * 10); + return; + } if (!s.chrgcurr2) break; + + printk("Full but we need to do something\n"); + if (s.vbusvld) new_state = POWER_SUPPLY_STATUS_NOT_CHARGING; else @@ -762,6 +776,7 @@ static void cpcap_usb_detect(struct work_struct *work) if (!delayed_work_pending(&ddata->ramp_work)) schedule_delayed_work(&ddata->ramp_work, HZ/20); } else { + printk("No feeding bus, disabling\n"); ddata->set_current = 0; error = cpcap_charger_disable(ddata); if (error)
Hi! I complained that "battery life is very poor" with leste. It seems to be combination of several factors. 1) I was using very old battery 2) My charger is detected as "USB", not as "AC" 3) Charger was cycling on/off, which was annoying and I often ending up dissconnecting the charger 4) It probably has a bit higher power consuption than original android 5) Android is more aggressive, charges to 4.35V, and allows deeper discharge According to my measurements "CPCAP_REG_CRM_FET_OVRD | CPCAP_REG_CRM_FET_CTRL" results in battery discharding and 0A drawn frmo the USB. "CPCAP_REG_CRM_FET_OVRD" is phone powered from USB, with battery more or less disconnected (<12mA), which is what we want in battery full situation. Second problem was that phone never really stayed in "battery full", immediately exiting it. This should solve both issues (plus it enables a lot of debugging). Best regards, Pavel Signed-off-by: Pavel Machek <pavel@ucw.cz>