[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZF59BS77uUpEZK6X@duo.ucw.cz>
Date: Fri, 12 May 2023 19:53:09 +0200
From: Pavel Machek <pavel@....cz>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Caleb Connolly <caleb.connolly@...aro.org>,
Sebastian Reichel <sre@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Amit Kucheria <amitk@...nel.org>,
Zhang Rui <rui.zhang@...el.com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: power_supply cooling interface
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.
> > >
> > > 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/commit/?id=a4496d52b3430cb3c4c16d03cdd5f4ee97ad1241
> > >
> > > However, reading through the sysfs docs for cooling devices, and
> > > looking at the implementation in power_supply_core.c, it seems like the
> > > 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 implementation
> > > (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 really
> > > work.
> >
> > Did this get solved somehow?
>
> Thanks for resurrecting the discussion.
>
> > 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.
>
> 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 warmer
> it gets. Doing a fast charge is ok, if the phone is for instance on a table
> doing nothing. But if the environment is hot (a car, a pocket) or there are
> 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 their
> performances. The first knob to act on is to reduce the charge speed of the
> 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 when
> it is too hot. This connection is the cooling device.
>
> The cooling devices have opaque values where the min and max cooling effect
> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists