linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



      parent reply	other threads:[~2021-02-22  7:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-06 13:14 Droid 4 charging Pavel Machek
2021-02-15  4:35 ` Tony Lindgren
2021-02-19 21:57   ` Pavel Machek
2021-02-21 20:56     ` Sebastian Reichel
2021-02-22  7:56     ` Tony Lindgren [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).