From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B3B7C433DB for ; Mon, 22 Feb 2021 07:57:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 22C9264E67 for ; Mon, 22 Feb 2021 07:57:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 22C9264E67 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SgNseAvm9/6Vf2rhqPbdD/SKeEoOJ3EnSmwOeynNcts=; b=aeUagKUpV/yOoZxIUnI9cL2IQ 9WdQni0vG0OShFYfniDfsRgD8kPLnsUwcoh8+JKpNzWoooWthUY9/icWzNU0ed83oQ8fHGZIBhTQr qEI2dV1/0blKbB6pyqmdKelKFmzxByQa5NhcZqV/I0UZfDCg9E1+OgcmOACDCOb43DoLxgZ4ZyZOp ukeUQw0RyxZ6VzJjItZ2J0nv9ulT2SbfIFFEpnZMBzdTDKWdwdP5vtO3XPcxU2GHZBVz1eN3cq2Xp +aEoGM8Jg+u+mDqbNzstcl/fZTVsVWcHTMxHN+xmjV1jaOvjVFUhcev2pyU74Z/oPRloXbGf7H+8F sHyvCuNtA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lE64x-00017e-1t; Mon, 22 Feb 2021 07:56:27 +0000 Received: from muru.com ([72.249.23.125]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lE64u-00017K-Fk for linux-arm-kernel@lists.infradead.org; Mon, 22 Feb 2021 07:56:25 +0000 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 08F3180C3; Mon, 22 Feb 2021 07:56:47 +0000 (UTC) Date: Mon, 22 Feb 2021 09:56:07 +0200 From: Tony Lindgren To: Pavel Machek Subject: Re: Droid 4 charging Message-ID: References: <20210206131415.GA4499@amd> <20210219215752.GA31435@amd> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210219215752.GA31435@amd> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210222_025624_583645_F1088974 X-CRM114-Status: GOOD ( 20.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maemo-leste@lists.dyne.org, Carl Philipp Klemm , phone-devel@vger.kernel.org, mpartap@gmx.net, merlijn@wizzup.org, martin_rysavy@centrum.cz, kernel list , sre@kernel.org, nekit1000@gmail.com, linux-omap@vger.kernel.org, linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org * Pavel Machek [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