[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240212123233.1230090-1-cristian.marussi@arm.com>
Date: Mon, 12 Feb 2024 12:32:22 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Cc: sudeep.holla@....com,
vincent.guittot@...aro.org,
peng.fan@....nxp.com,
michal.simek@....com,
quic_sibis@...cinc.com,
quic_nkela@...cinc.com,
souvik.chakravarty@....com,
Cristian Marussi <cristian.marussi@....com>
Subject: [PATCH 00/11] Add SCMI core checks for notification support.
Hi,
this small series adds a new logic into the SCMI core to implicitly check
for notification support when some SCMI driver attempts to register for
notifications.
Till now, trying to register a notifier for an unsuppported notification
returned an error and this behaviour generated unneeded message exchanges:
the only way to avoid this was to lookup in advance the specific protocol
and resources available in order to avoid registering at all any notifier
where not supported.
Anyway, not all protocols currently expose the related notification info
to lookup and, moreover, no check was performed anywhere to verify if the
specific notification enable/disable command was supported at all (almost
all of these notification enable commands are optional).
Last but not least, this kind of support checks could and should be handled
transparently by the SCMI core.
With this series each protocol can optionally provide an event_ops
callcback that will be invoked by the core to lookup if the specific
command and event/resource notification is supported on the running
platform; the SCMI core then, at initialization time, will use such
callbacks to take care to collect such info and mark unsupported
events/resources.
Later on, when an SCMI driver attempts to register a notifier for a
specific event/resources, it will fail and return an error to the caller
if the requested notification was not supported.
The end-result is that the SCMI driver user will fail to register a
notifier if the related command or resource is not supported (like before),
BUT without the need of exchanging any message NOR the need to actively
lookup if the specified notification is supported.
The last two patches in the series, instead, take care to extend the Perf
notification report to provide the pre-calculated frequencies corresponding
to the level or index carried by the specific notification report.
These latter 2 patches are indeed only slighly related to this series at
large but are provided here for ease of access.
Based on sudeep/for-next/scmi/updates on top of commit
7dd3d11f4dac ("clk: scmi: Add support for forbidden clock state controls")
Thanks,
Cristian
---
Cristian Marussi (11):
firmware: arm_scmi: Check for notification support
firmware: arm_scmi: Add a common helper to check if a message is
supported
firmware: arm_scmi: Implement Perf .is_notify_supported callback
firmware: arm_scmi: Implement Power .is_notify_supported callback
firmware: arm_scmi: Implement SysPower .is_notify_supported callback
firmware: arm_scmi: Implement Clock .is_notify_supported callback
firmware: arm_scmi: Implement Sensor .is_notify_supported callback
firmware: arm_scmi: Implement Reset .is_notify_supported callback
firmware: arm_scmi: Implement Powercap .is_notify_supported callback
firmware: arm_scmi: Use opps_by_lvl to store opps
firmware: arm_scmi: Report frequencies in Perf notifications
drivers/firmware/arm_scmi/clock.c | 47 ++++++++-
drivers/firmware/arm_scmi/driver.c | 34 ++++++
drivers/firmware/arm_scmi/notify.c | 17 ++-
drivers/firmware/arm_scmi/notify.h | 4 +
drivers/firmware/arm_scmi/perf.c | 144 +++++++++++++++++++++++---
drivers/firmware/arm_scmi/power.c | 30 +++++-
drivers/firmware/arm_scmi/powercap.c | 45 +++++++-
drivers/firmware/arm_scmi/protocols.h | 4 +
drivers/firmware/arm_scmi/reset.c | 37 +++++--
drivers/firmware/arm_scmi/sensors.c | 37 ++++++-
drivers/firmware/arm_scmi/system.c | 16 +++
include/linux/scmi_protocol.h | 3 +
12 files changed, 383 insertions(+), 35 deletions(-)
--
2.43.0
Powered by blists - more mailing lists