Re: [PATCH 0/3] firmware: arm_scmi: Register and handle limits change notification

From: Cristian Marussi <cristian.marussi@arm.com>
To: Sibi Sankar <quic_sibis@quicinc.com>
Cc: sudeep.holla@arm.com, rafael@kernel.org, viresh.kumar@linaro.org,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, quic_mdtipton@quicinc.com,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 0/3] firmware: arm_scmi: Register and handle limits change notification
Date: Wed, 17 Jan 2024 09:41:40 +0000	[thread overview]
Message-ID: <Zaeg1H9G5jOeOXh2@pluto> (raw)
In-Reply-To: <20240108140118.1596-1-quic_sibis@quicinc.com>

On Mon, Jan 08, 2024 at 07:31:15PM +0530, Sibi Sankar wrote:
> This series registers for scmi limits change notifications and adds
> perf_notify_support/perf_opp_xlate interfaces which are used by the
> scmi cpufreq driver to determine the throttled frequency and apply HW
> pressure.
> 

Hi,

a few initial remarks from the mere SCMI standpoint.

Unlinke most SCMI protocols that expose domains info bits via an
*info_get protocol operation, PERF does no do this since (till now) there
wasn't a compelling reason (i.e. users)

Ulf recently in his GenPD/SCMI series recently started exposing something
and now you need to expose even more, adding also a new xlate ops.

For the sake of simplicity, I think that we could now expose straight
away the whole perf_domain_info and embedded structs via the usual *info_get.

After having done that, you can just drop your patch 1 and 2 since you
can access the needed info from the cpufreq_driver right away.

Having said, I have already such patch ready (for my internal testing), I
wll post it by the end of week after a minor cleanup, if you can bear with me.

Thoughts ?

Thanks,
Cristian