All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexey Klimov" <alexey.klimov@linaro.org>
To: "Sudeep Holla" <sudeep.holla@arm.com>
Cc: "Vivek Aknurwar" <vivek.aknurwar@oss.qualcomm.com>,
	<cristian.marussi@arm.com>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-arm-msm@vger.kernel.org>, <mike.tipton@oss.qualcomm.com>
Subject: Re: [PATCH 1/1] firmware: arm_scmi: Increase MAX_OPPS to 64
Date: Thu, 11 Dec 2025 13:54:01 +0000	[thread overview]
Message-ID: <DEVFS1MAP8J6.2263USIPE4Y74@linaro.org> (raw)
In-Reply-To: <20251211-masterful-caterpillar-of-love-bc2d4c@sudeepholla>

On Thu Dec 11, 2025 at 1:48 PM GMT, Sudeep Holla wrote:
> On Thu, Dec 11, 2025 at 01:14:06PM +0000, Alexey Klimov wrote:
>> > 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?
>> 
>
> Ah good point on confusing commit message. I just assumed it is limitation
> of the implementation. I can update the log when applying. It is not spec
> or protocol limitation for sure.
>
> How about this ?
>
>   | firmware: arm_scmi: Increase performance MAX_OPPS limit to 64
>   |
>   | Some platforms expose more than 32 operating performance points (OPPs)
>   | per performance domain via the SCMI performance protocol, but the
>   | driver currently limits the number of OPPs it can handle to 32 via
>   | MAX_OPPS.
>   |
>   | Bump MAX_OPPS to 64 so that these platforms can register all their
>   | performance levels. This is an internal limit in the driver only and
>   | does not affect the SCMI protocol ABI.
>   |
>   | 64 is chosen as the next power of two above the existing limit.

Yeah, that sounds better :)

I also thought that this was a driver limitation, not the protocol/spec one
as stated in the original patch.

I don't mind updating the commit message like this (but I am not the author
of the original patch).

Best regards,
Alexey



  reply	other threads:[~2025-12-11 13:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14  7:34 [PATCH 1/1] firmware: arm_scmi: Increase MAX_OPPS to 64 Vivek Aknurwar
2025-10-14  7:51 ` Konrad Dybcio
2025-12-10 23:28 ` Vivek Aknurwar
2025-12-11  9:50   ` Sudeep Holla
2025-12-11 13:14   ` Alexey Klimov
2025-12-11 13:48     ` Sudeep Holla
2025-12-11 13:54       ` Alexey Klimov [this message]
2025-12-11 14:07         ` Sudeep Holla
2025-12-11 14:25           ` Alexey Klimov
2025-12-15 22:19             ` Vivek Aknurwar
2026-01-01 17:57 ` Sudeep Holla

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=DEVFS1MAP8J6.2263USIPE4Y74@linaro.org \
    --to=alexey.klimov@linaro.org \
    --cc=cristian.marussi@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.tipton@oss.qualcomm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vivek.aknurwar@oss.qualcomm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.