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 <[email protected]>
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)
--
People of Russia, stop Putin before his war on Ukraine escalates.
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/[email protected]/#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/[email protected]/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 <[email protected]>
>
> 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 <[email protected]> [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
--
People of Russia, stop Putin before his war on Ukraine escalates.
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
--
People of Russia, stop Putin before his war on Ukraine escalates.
> * Ivaylo Dimitrov <[email protected]> [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
--
People of Russia, stop Putin before his war on Ukraine escalates.
* Pavel Machek <[email protected]> [230413 09:37]:
>
> > * Ivaylo Dimitrov <[email protected]> [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
>