From: Tony Lindgren <tony@atomide.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-omap@vger.kernel.org, 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,
Carl Philipp Klemm <philipp@uvos.xyz>
Subject: Re: Droid 4 charging
Date: Mon, 22 Feb 2021 09:56:07 +0200 [thread overview]
Message-ID: <YDNjl+4M/hrmsbIj@atomide.com> (raw)
In-Reply-To: <20210219215752.GA31435@amd>
* Pavel Machek <pavel@ucw.cz> [210219 21:58]:
> > > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A
> > > is drawn from USB, and battery is not discharged:
> > >
> > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > input_current_limit
> > > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now
> > > 0
> >
> > Hmm so have you measured that setting the current limit to 0 actually
> > draws something from the USB?
>
> Yes, it does, if I do the echo when charge is done. (I have small USB
> passthrough with volt and amp meters). It has been behaving weirdly in
> other cases.p
OK great, seems like we can just change the charger timeout then.
> > I recall clearing the ichrgr bits stops the vbus draw completely, but
> > I could be wrong.
> >
> > > Is that a better way to handle full battery?
> >
> > We could experiment with switching over to usb power when the battery is
> > full. Looking at the docs for mc1378 it might be possible that setting
> > CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the
> > battery is full disables charging but still keep drawing power from
> > the usb. I'd assume the current limit still needs to be nonzero there
> > too? Totally untested..
>
> I may be able to test patches...
Yeah this too might be worth testing on some donor device..
> > And switching back to battery power on usb disconnect will potentially
> > only give us very little time based on the different line length for
> > vbus and ground pins compared to data pins on the usb connector.. And
> > uvos had some concerns about the battery capacity putting it back online,
> > so adding him to Cc also.
>
> You mean, we'd have to take interrupt and switch registers in order to
> switch back to battery power, and system would crash if we did not
> make it in time?
Yes hopefully we don't need to do that. My guess is we should find some
FET_OVRD and FET_CTRL setting we can always keep enabled after charger
negotation. Maybe we already have the right settings based on your tests :)
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: maemo-leste@lists.dyne.org, Carl Philipp Klemm <philipp@uvos.xyz>,
phone-devel@vger.kernel.org, mpartap@gmx.net, merlijn@wizzup.org,
martin_rysavy@centrum.cz,
kernel list <linux-kernel@vger.kernel.org>,
sre@kernel.org, nekit1000@gmail.com, linux-omap@vger.kernel.org,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: Droid 4 charging
Date: Mon, 22 Feb 2021 09:56:07 +0200 [thread overview]
Message-ID: <YDNjl+4M/hrmsbIj@atomide.com> (raw)
In-Reply-To: <20210219215752.GA31435@amd>
* Pavel Machek <pavel@ucw.cz> [210219 21:58]:
> > > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A
> > > is drawn from USB, and battery is not discharged:
> > >
> > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > input_current_limit
> > > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now
> > > 0
> >
> > Hmm so have you measured that setting the current limit to 0 actually
> > draws something from the USB?
>
> Yes, it does, if I do the echo when charge is done. (I have small USB
> passthrough with volt and amp meters). It has been behaving weirdly in
> other cases.p
OK great, seems like we can just change the charger timeout then.
> > I recall clearing the ichrgr bits stops the vbus draw completely, but
> > I could be wrong.
> >
> > > Is that a better way to handle full battery?
> >
> > We could experiment with switching over to usb power when the battery is
> > full. Looking at the docs for mc1378 it might be possible that setting
> > CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the
> > battery is full disables charging but still keep drawing power from
> > the usb. I'd assume the current limit still needs to be nonzero there
> > too? Totally untested..
>
> I may be able to test patches...
Yeah this too might be worth testing on some donor device..
> > And switching back to battery power on usb disconnect will potentially
> > only give us very little time based on the different line length for
> > vbus and ground pins compared to data pins on the usb connector.. And
> > uvos had some concerns about the battery capacity putting it back online,
> > so adding him to Cc also.
>
> You mean, we'd have to take interrupt and switch registers in order to
> switch back to battery power, and system would crash if we did not
> make it in time?
Yes hopefully we don't need to do that. My guess is we should find some
FET_OVRD and FET_CTRL setting we can always keep enabled after charger
negotation. Maybe we already have the right settings based on your tests :)
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-22 7:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-06 13:14 Droid 4 charging Pavel Machek
2021-02-06 13:14 ` Pavel Machek
2021-02-15 4:35 ` Tony Lindgren
2021-02-15 4:35 ` Tony Lindgren
2021-02-19 21:57 ` Pavel Machek
2021-02-19 21:57 ` Pavel Machek
2021-02-21 20:56 ` Sebastian Reichel
2021-02-21 20:56 ` Sebastian Reichel
2021-02-22 7:56 ` Tony Lindgren [this message]
2021-02-22 7:56 ` Tony Lindgren
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=YDNjl+4M/hrmsbIj@atomide.com \
--to=tony@atomide.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=philipp@uvos.xyz \
--cc=phone-devel@vger.kernel.org \
--cc=sre@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.