Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 12 May 2023 19:53:09 +0200
From:   Pavel Machek <pavel@ucw.cz>
To:     Daniel Lezcano <daniel.lezcano@linaro.org>
Cc:     Caleb Connolly <caleb.connolly@linaro.org>,
        Sebastian Reichel <sre@kernel.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Amit Kucheria <amitk@kernel.org>,
        Zhang Rui <rui.zhang@intel.com>, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>
Subject: Re: power_supply cooling interface
Message-ID: <ZF59BS77uUpEZK6X@duo.ucw.cz>
References: <164f2458-fb66-f238-7143-bdbe1e200870@linaro.org>
 <ZF5t5BWqLLEvDdfz@localhost>
 <b1237581-3ece-a358-f1ba-7a3ebb08d8d2@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: <b1237581-3ece-a358-f1ba-7a3ebb08d8d2@linaro.org>
Precedence: bulk


--+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--