Re: [PATCH 3/4] arm64: dts: qcom: pm7250b: Enable Qualcomm BCL device

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 2/24/26 7:35 PM, Manaf Meethalavalappu Pallikunhi wrote:
> Hi Konrad,
> 
> On 2/19/2026 6:34 PM, Konrad Dybcio wrote:
>> On 2/19/26 12:34 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>> Hi Konrad,
>>>
>>> On 2/16/2026 5:18 PM, Konrad Dybcio wrote:
>>>> On 2/13/26 12:55 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>>>> Hi Konrad,
>>>>>
>>>>> On 2/6/2026 2:41 PM, Konrad Dybcio wrote:
>>>>>> On 2/5/26 10:14 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>>>>>> Enable Qualcomm BCL hardware devicetree binding configuration
>>>>>>> for pm7250b.
>>>>>>>
>>>>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>>>>>>> ---
>>>>>>>     arch/arm64/boot/dts/qcom/pm7250b.dtsi | 10 ++++++++++
>>>>>>>     1 file changed, 10 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>>> index 0761e6b5fd8d..69ad76831cde 100644
>>>>>>> --- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
>>>>>>> @@ -202,6 +202,16 @@ pm7250b_gpios: gpio@c000 {
>>>>>>>                 interrupt-controller;
>>>>>>>                 #interrupt-cells = <2>;
>>>>>>>             };
>>>>>>> +
>>>>>>> +        bcl@1d00 {
>>>>>>> +            compatible = "qcom,pm7250b-bcl", "qcom,bcl-v1";
>>>>>>> +            reg = <0x1d00>;
>>>>>>> +            interrupts = <PM7250B_SID 0x1d 0x0 IRQ_TYPE_EDGE_RISING>,
>>>>>>> +                     <PM7250B_SID 0x1d 0x1 IRQ_TYPE_EDGE_RISING>;
>>>>>>> +            interrupt-names = "bcl-max-min",
>>>>>>> +                      "bcl-critical";
>>>>>> We should strip the "bcl-" prefix, since these interrupts happen
>>>>>> to be under the bcl device
>>>>> Ack
>>>>>>
>>>>>>> +            overcurrent-thresholds-milliamp = <5500 6000>;
>>>>>> Is that something that we expect to change between boards, or is
>>>>>> that an electrical characteristic of the PM7250B?
>>>>> Yes,  It can change based on battery used for that board as these thresholds will be close below battery OCP spec.
>>>>> It is not based on pmic spec. Max current threshold support for specific pmic bcl is taken care in driver pmic data.
>>>>
>>>> Okay, so this property must not live in the common PMIC DTSI then..
>>>
>>> Ack, I will move it into board file wherever it is required in next revision
>>>
>>>>
>>>> I think ideally this could be communicated over battmgr, since it already
>>>> has a lot of information about the battery that's currently connected to
>>>> the device. Do you think that would be reasonable? Would you know who we
>>>> could talk to internally?
>>>
>>> We are not adding any battery information here. This configuration is specifically for the BCL peripheral to monitor current and trigger an over‑current alarm. While the BCL settings are derived from battery specifications, they are not the same as the battery’s own limits,the BCL thresholds will always be set below the battery’s OCP specification.
>>> The intent of the BCL is to provide early detection of over‑current or under‑voltage conditions, notify the SoC/peripherals, and allow corrective action before the system ever reaches the battery’s actual protection limits.
>>
>> Right, but as you say they are derived from the battery spec, I would
>> guesstimate it's something like "90% max current", so swapping out different
>> batteries for the same device could potentially affect this value. Since we
> 
> No, there is no predefined equation to derive these values directly from the battery specifications. The actual limits depend on multiple factors, including the underlying mitigation support available on the board for different components (fast path/slow path), the peak‑current use cases defined for that board, the battery characteristics etc. Simply swapping the battery will not automatically make it work. These parameters must be carefully tuned and configured.

What I had in mind is that if a battery is dual- (or more-) sourced for a
given device by a given vendor, they could perform all that tuning and then
store the data alongside other battery configuration that they presumably
already are required to include in battmgr for all of the specific battery
types they intend to support

> I discussed this with the internal battery manager driver team, and they mentioned that the power‑supply framework does not expose any discharging current spec details. Typically, only charging‑current–related information is provided.

Right, but the power-supply framework happens to be open-source, so if that
would be worth implementing, I think the maintainers would certainly be open
to having that discussion (+Sebastian)


> For some modern battery use cases, these configurations must also be adjusted dynamically based on factors such as ambient temperature and battery state of charge. The driver already supports this through the hwmon sysfs interface, allowing these values to be overridden at runtime.

One could assume that depends on (presumably) proprietary userspace and I
would imagine it'd be generally preferred to keep as much charging infra as
possible inside the kernel (or even better, in some battle-tested FW).

Konrad