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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E386EC77B7F for ; Fri, 12 May 2023 17:53:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237996AbjELRxQ (ORCPT ); Fri, 12 May 2023 13:53:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237651AbjELRxP (ORCPT ); Fri, 12 May 2023 13:53:15 -0400 Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCE3F8A76; Fri, 12 May 2023 10:53:11 -0700 (PDT) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 07AEB1C0ABB; Fri, 12 May 2023 19:53:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1683913990; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b/kgvT3BKXQ+t2ds//F2bD3iB3PjsDiJV+brMHur6RQ=; b=Gi84IBxJBRzfHM5e9b/7a6K9v3L9mPEpuSKEaj51WdZpDxpvECSdAdIBzrxZ4N77agTBMc UiieET9PlbMGij7O6dbIBSKDETWtdJjw9qIFpvKlb/OSMS0IjAK9o0tyIBidgDqRfVPBbG zjbs82Jnh3iyhycUmmvJ2prohxOZAYw= Date: Fri, 12 May 2023 19:53:09 +0200 From: Pavel Machek To: Daniel Lezcano Cc: Caleb Connolly , Sebastian Reichel , "Rafael J. Wysocki" , Amit Kucheria , Zhang Rui , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm Subject: Re: power_supply cooling interface Message-ID: References: <164f2458-fb66-f238-7143-bdbe1e200870@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HOYeiAJ9Fpm6NkI" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org --+HOYeiAJ9Fpm6NkI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > > I've been working on a driver for the charger found in most Snapdragon > > > 845 phones (the OnePlus 6, SHIFT6mq, PocoPhone F1, etc). I wanted to > > > include support for the POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT > > > property. > > >=20 > > > My understanding is that it exposes the current limit as a cooling > > > device so that userspace (or frameworks like DTPM) can optimise for > > > performance in a thermally constrained device by limiting the input > > > current and thus reducing the heat generated by the charger circuitry, > > > a similar idea was applied on the Pixel C: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co= mmit/?id=3Da4496d52b3430cb3c4c16d03cdd5f4ee97ad1241 > > >=20 > > > However, reading through the sysfs docs for cooling devices, and > > > looking at the implementation in power_supply_core.c, it seems like t= he > > > behavior here is wrong in a few ways: > > > 1. The values should scale from 0: no cooling to max_state: max > > > cooling, but the power_supply docs and the only existing implementati= on > > > (the smbb driver) just export the current_limit, such that increasing > > > cur_state would increase the current limit, not decrease it. > > > 2. (unsure?)The scale is completely different to most other cooling > > > devices, most cooling devices don't seem to have a max state much > > > beyond the double digits, but CHARGE_CONTROL_LIMIT is on the scale of > > > uA, so approaches like incrementing the cooling state by 1 don't real= ly > > > work. > >=20 > > Did this get solved somehow? >=20 > Thanks for resurrecting the discussion. >=20 > > Anyway, I am not sure mW will be useful here, as elsewhere it is mW > > thermal and here it is mW from charger. Most of that energy should be > > stored in battery, not converted to heat. >=20 > I'm not sure to understand the comment. The question is about decreasing = the > speed of the charge of the battery because the faster it charges the warm= er > it gets. Doing a fast charge is ok, if the phone is for instance on a tab= le > doing nothing. But if the environment is hot (a car, a pocket) or there a= re > other sources of heat on the phone like a game, the temperature of the > battery could be too high (or the skin temperature). In this case we have= to > balance the heat contribution of the different components by reducing the= ir > performances. The first knob to act on is to reduce the charge speed of t= he > battery by reducing the delivered power. Understood. > For that we need a connection between the thermal framework which monitors > the battery temperature and the power supply to reduce the charge speed w= hen > it is too hot. This connection is the cooling device. >=20 > The cooling devices have opaque values where the min and max cooling effe= ct > vary depending on the implementation (eg. a fan 0/1, a LCD light 0/1023). Aha, ok. > Here the power supply has yet another unit (uA) to act on and difficult to > translate to a cooling device discrete numbers (that is my > understanding). Well, if you can accept 1000 steps like you do for LCD, all you really need is maximum current and then stepping in 1/100 of that. > With enough components in DTPM, it will be possible to create a generic > power cooling device using the unified unit uW with the powercap API. I was trying to point out trouble with uW: you don't know them in case of battery charging. You know phone is drawing 500mA @ close to 5V (-> 2.5W), but you don't really know how much is stored in battery, and how much is turned into heat. But I guess you could approximate that somehow. BR, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. --+HOYeiAJ9Fpm6NkI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCZF59BQAKCRAw5/Bqldv6 8kl6AJoC8T1J06TA7wMVmrT/7qi5p3Qm1QCggd70ihEYrC4+ImG+Zr8jiguNuPw= =jTk3 -----END PGP SIGNATURE----- --+HOYeiAJ9Fpm6NkI--