From: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
To: Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-omap@vger.kernel.org, tony@atomide.com, sre@kernel.org,
nekit1000@gmail.com, mpartap@gmx.net, merlijn@wizzup.org,
martin_rysavy@centrum.cz, phone-devel@vger.kernel.org,
maemo-leste@lists.dyne.org
Subject: Re: Motorola Droid 4 -- Stopping charger when battery is full
Date: Tue, 7 Mar 2023 16:10:20 +0200 [thread overview]
Message-ID: <ef4409b2-abd8-0eac-f66e-6858c3358cc1@gmail.com> (raw)
In-Reply-To: <ZAcvuP8kmWveLoE/@duo.ucw.cz>
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)
>
next prev parent reply other threads:[~2023-03-07 14:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 12:36 Pavel Machek
2023-03-07 14:10 ` Ivaylo Dimitrov [this message]
2023-03-09 7:14 ` Tony Lindgren
2023-04-13 9:37 ` Pavel Machek
2023-04-13 9:45 ` Tony Lindgren
2023-04-13 9:34 ` Pavel Machek
2023-04-13 14:41 ` Ivaylo Dimitrov
2023-03-21 19:25 ` d4: Usable with some caveats Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef4409b2-abd8-0eac-f66e-6858c3358cc1@gmail.com \
--to=ivo.g.dimitrov.75@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=maemo-leste@lists.dyne.org \
--cc=martin_rysavy@centrum.cz \
--cc=merlijn@wizzup.org \
--cc=mpartap@gmx.net \
--cc=nekit1000@gmail.com \
--cc=pavel@ucw.cz \
--cc=phone-devel@vger.kernel.org \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®