From: Cristian Marussi <cristian.marussi@arm.com>
To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Cc: sudeep.holla@arm.com, vincent.guittot@linaro.org,
peng.fan@oss.nxp.com, michal.simek@amd.com,
quic_sibis@quicinc.com, quic_nkela@quicinc.com,
souvik.chakravarty@arm.com,
Cristian Marussi <cristian.marussi@arm.com>
Subject: [PATCH 00/11] Add SCMI core checks for notification support.
Date: Mon, 12 Feb 2024 12:32:22 +0000 [thread overview]
Message-ID: <20240212123233.1230090-1-cristian.marussi@arm.com> (raw)
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2024-02-12 12:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 12:32 Cristian Marussi [this message]
2024-02-12 12:32 ` [PATCH 01/11] firmware: arm_scmi: Check for notification support Cristian Marussi
2024-02-12 12:32 ` [PATCH 02/11] firmware: arm_scmi: Add a common helper to check if a message is supported Cristian Marussi
2024-02-12 12:32 ` [PATCH 03/11] firmware: arm_scmi: Implement Perf .is_notify_supported callback Cristian Marussi
2024-02-12 12:32 ` [PATCH 04/11] firmware: arm_scmi: Implement Power " Cristian Marussi
2024-02-12 12:32 ` [PATCH 05/11] firmware: arm_scmi: Implement SysPower " Cristian Marussi
2024-02-12 12:32 ` [PATCH 06/11] firmware: arm_scmi: Implement Clock " Cristian Marussi
2024-02-12 23:00 ` kernel test robot
2024-02-12 23:20 ` kernel test robot
2024-02-13 2:58 ` kernel test robot
2024-02-13 8:49 ` Cristian Marussi
2024-02-13 18:24 ` Nikunj Kela
2024-02-14 18:21 ` Cristian Marussi
2024-02-12 12:32 ` [PATCH 07/11] firmware: arm_scmi: Implement Sensor " Cristian Marussi
2024-02-12 12:32 ` [PATCH 08/11] firmware: arm_scmi: Implement Reset " Cristian Marussi
2024-02-12 12:32 ` [PATCH 09/11] firmware: arm_scmi: Implement Powercap " Cristian Marussi
2024-02-12 12:32 ` [PATCH 10/11] firmware: arm_scmi: Use opps_by_lvl to store opps Cristian Marussi
2024-02-12 12:32 ` [PATCH 11/11] firmware: arm_scmi: Report frequencies in Perf notifications Cristian Marussi
2024-02-22 9:09 ` [PATCH 00/11] Add SCMI core checks for notification support 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=20240212123233.1230090-1-cristian.marussi@arm.com \
--to=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=quic_nkela@quicinc.com \
--cc=quic_sibis@quicinc.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).