Re: power_supply cooling interface

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3760 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]