[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DEVEXHI9CEFA.19RL3BXTV8E38@linaro.org>
Date: Thu, 11 Dec 2025 13:14:06 +0000
From: "Alexey Klimov" <alexey.klimov@...aro.org>
To: "Vivek Aknurwar" <vivek.aknurwar@....qualcomm.com>,
<sudeep.holla@....com>, <cristian.marussi@....com>
Cc: <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linux-arm-msm@...r.kernel.org>, <mike.tipton@....qualcomm.com>
Subject: Re: [PATCH 1/1] firmware: arm_scmi: Increase MAX_OPPS to 64
On Wed Dec 10, 2025 at 11:28 PM GMT, Vivek Aknurwar wrote:
> Hello Sudeep/Cristian,
>
> Just following up on this patch. If there’s anything missing or
> needs adjustment, please let me know.
Vivek, please avoid top-posting.
> On 10/14/2025 12:34 AM, Vivek Aknurwar wrote:
>> Some upcoming SoCs define more than 32 operating performance points (OPPs),
>> exceeding the current SCMI protocol limit. Increase MAX_OPPS to 64
>> (next power of 2) to support these configurations.
Didn't touch for a while. The way it is stated confuses me a bit.
Should the value defined by protocol be updated out of the blue?
Should the protocol (defined by spec) be changed first?
If protocol changes, then should the version/minor version be
updated/added?
Thanks,
Alexey
>> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@....qualcomm.com>
>> ---
>> drivers/firmware/arm_scmi/perf.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
>> index 683fd9b85c5c..2249ef7fe790 100644
>> --- a/drivers/firmware/arm_scmi/perf.c
>> +++ b/drivers/firmware/arm_scmi/perf.c
>> @@ -27,7 +27,7 @@
>> /* Updated only after ALL the mandatory features for that version are merged */
>> #define SCMI_PROTOCOL_SUPPORTED_VERSION 0x40000
>>
>> -#define MAX_OPPS 32
>> +#define MAX_OPPS 64
>>
>> enum scmi_performance_protocol_cmd {
>> PERF_DOMAIN_ATTRIBUTES = 0x3,
Powered by blists - more mailing lists