mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Pavel Machek <pavel@ucw.cz>, Caleb Connolly <caleb.connolly@linaro.org>
Cc: 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
Date: Fri, 12 May 2023 19:22:38 +0200	[thread overview]
Message-ID: <b1237581-3ece-a358-f1ba-7a3ebb08d8d2@linaro.org> (raw)
In-Reply-To: <ZF5t5BWqLLEvDdfz@localhost>

On 12/05/2023 18:48, Pavel Machek wrote:
> 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.

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).

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).

My suggestion is adding to the power supply the power capping capability 
using the powercap framework and add it to the DTPM nomenclature.

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.



-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


  reply	other threads:[~2023-05-12 17:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 12:54 Caleb Connolly
2023-05-12 16:48 ` Pavel Machek
2023-05-12 17:22   ` Daniel Lezcano [this message]
2023-05-12 17:53     ` Pavel Machek
2023-05-13  2:07       ` Caleb Connolly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1237581-3ece-a358-f1ba-7a3ebb08d8d2@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=amitk@kernel.org \
    --cc=caleb.connolly@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=sre@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®