Devicetree
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dhruvin Rajpura <dhruvin.rajpura@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	kamal.wadhwa@oss.qualcomm.com, jishnu.prakash@oss.qualcomm.com,
	Dhruvin Rajpura <drajpura@qti.qualcomm.com>,
	Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>,
	Umang Chheda <quic_uchheda@quicinc.com>
Subject: Re: [PATCH 2/2] power: supply: qcom_battmgr: Add thermal mitigation support
Date: Fri, 19 Jun 2026 17:15:13 +0200	[thread overview]
Message-ID: <a0e7c439-e377-4607-9468-d7c1681ded4d@oss.qualcomm.com> (raw)
In-Reply-To: <CAB8MRjTAbpwcrD==eZuaJdaprQoEsgr2L1EEU6x+gEu8tAVijQ@mail.gmail.com>

On 6/11/26 1:32 PM, Dhruvin Rajpura wrote:
> On Tue, Jun 9, 2026 at 3:12 PM Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> wrote:
> 
>> On 6/9/26 11:16 AM, DhruvinRajpura wrote:
>>> From: Dhruvin Rajpura <drajpura@qti.qualcomm.com>

[...]

>>> +static int qcom_battmgr_parse_dt(struct qcom_battmgr *battmgr)
>>> +{
>>> +     struct device_node *node = battmgr->dev->of_node;
>>> +     int len, ret;
>>> +
>>> +     ret = of_property_count_elems_of_size(node,
>> "qcom,thermal-mitigation", sizeof(u32));
>>> +     if (ret == -EINVAL)
>>> +             return 0;               /* property not defined, thermal
>> mitigation disabled */
>>> +     if (ret <= 0)
>>> +             return ret;              /* real error, propagate */
>>
>> Does battmgr really expect the OS to house this information? Can we not
>> retrieve it from the running firmware?
>>
> 
> The firmware exposes only a single maximum FCC value via
> BATT_CHG_CTRL_LIM_MAX, not a set of discrete throttle levels.
> The thermal mitigation levels represent a platform policy
> decision - how aggressively to throttle charging at each
> thermal state - which varies per platform based on thermal
> design, battery capacity and use case requirements.
> 
> That said, if the preference is to avoid DT for this and instead
> derive levels programmatically from the firmware maximum, we
> could generate N evenly spaced levels between 0 and
> BATT_CHG_CTRL_LIM_MAX. However this would reduce platform
> flexibility. Happy to discuss the preferred approach.

Following up on what Krzysztof brought up in the other branch of this
thread, does battmgr only allow to throttle the charging current, or
are there toggles for e.g. power too?

And does the reported max limit current adapt to the selected PD voltage
level? (I would assume that's a stupid question, but never hurts to
confirm..)

Konrad

      parent reply	other threads:[~2026-06-19 15:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09  9:16 [PATCH 0/2] power: supply: qcom_battmgr: Add thermal mitigation support DhruvinRajpura
2026-06-09  9:16 ` [PATCH 1/2] bindings: power: supply: qcom,pmic-glink: Document thermal-mitigation DhruvinRajpura
2026-06-09  9:26   ` sashiko-bot
2026-06-10  9:04   ` Krzysztof Kozlowski
     [not found]     ` <CAB8MRjTwN6J3oSFVeF-w7WpZQamEyyQ6Ckyd=TAB=-N22b8k1g@mail.gmail.com>
2026-06-16  4:35       ` Krzysztof Kozlowski
2026-06-09  9:16 ` [PATCH 2/2] power: supply: qcom_battmgr: Add thermal mitigation support DhruvinRajpura
2026-06-09  9:30   ` sashiko-bot
2026-06-09  9:42   ` Konrad Dybcio
     [not found]     ` <CAB8MRjTAbpwcrD==eZuaJdaprQoEsgr2L1EEU6x+gEu8tAVijQ@mail.gmail.com>
2026-06-19 15:15       ` Konrad Dybcio [this message]

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=a0e7c439-e377-4607-9468-d7c1681ded4d@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dhruvin.rajpura@oss.qualcomm.com \
    --cc=drajpura@qti.qualcomm.com \
    --cc=jishnu.prakash@oss.qualcomm.com \
    --cc=kamal.wadhwa@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=quic_subbaram@quicinc.com \
    --cc=quic_uchheda@quicinc.com \
    --cc=robh@kernel.org \
    --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