Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware

[Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>]

Hi Krzysztof,

Le 24/06/2026 à 12:45, Krzysztof Kozlowski a écrit :
> On 23/06/2026 11:47, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Krzysztof,
>>
>>
>> On 6/22/2026 5:58 PM, Krzysztof Kozlowski wrote:
>>> On Sat, Jun 20, 2026 at 02:09:08AM +0530, Manaf Meethalavalappu Pallikunhi wrote:
>>>> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
>>>> based power monitoring and limiting capabilities for various domains.
>>>>
>>>> Add a DeviceTree binding to describe the SPEL block on Qualcomm's SoC.
>>>>
>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>>>> ---
>>>>    .../bindings/power/limits/qcom,spel.yaml           | 47 ++++++++++++++++++++++
>>>>    MAINTAINERS                                        |  6 +++
>>>>    2 files changed, 53 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
>>>
>>> What is "limits" directory for? What sort of class of devices fit there?
>>
>> Added for devices that integrate with the powercap framework (exposed
>> via sys/class/powercap). These devices are responsible for enforcing and
> 
> That's a driver answer. I asked about class of devices. powercap
> framework is Linux thing, not a class of devices.
> 
> Please describe hardware, not Linux frameworks.>>> monitoring power consumption limits across different domains, such as
>> the system, SoC, or specific subsystems. Any other better directory ?
> 
> I don't know what is this hardware doing and commit msg is quite short
> on explanation. Power monitoring is usually hwmon, but probably this is
> not a hwmon.
Right, it is relatively new in the device tree bindings. There is the 
Intel RAPL which is the same device but it does not belong to the DT 
namespace.

RAPL : Running Average Power Limit
SPEL : SoC Power and Electrical Limits

It allows power capping and read the average power consumption for a 
specific device (or/and an energy counter)

Basically you can set a power constraint (power limit) to a device and 
this one won't consume more than that power (the power limitation 
strategy is managed under the hood by the firmware depending on the 
device - lower OPP, idle injection, modem weaker signal, etc ...).

The RAPL or the SPEL have a hierarchical power limitation. For example:

                                     SoC
                                      |
                           ------------------------
                          |                        |
                      Cluster0                 Cluster1
                          |                        |
                 -----------------        -----------------
                |     |     |     |      |     |     |     |
              CPU0  CPU1  CPU2  CPU3   CPU4  CPU5  CPU6  CPU7


If you specify a power limit to 'SoC', then the power consumption of 
Cluster0 + Cluster1 <= SoC

If Cluster0 power consumption decreases, then Cluster1 is allowed to use 
more power until Cluster0 + Cluster1 <= SoC

For me it sounds reasonable to put the device description under power/limits