mbox series

[v11,0/9] SCMI Notifications Core Support

Message ID 20200701155348.52864-1-cristian.marussi@arm.com (mailing list archive)
Headers show
Series SCMI Notifications Core Support | expand

Message

Cristian Marussi July 1, 2020, 3:53 p.m. UTC
Hi all,

this series wants to introduce SCMI Notification Support, built on top of
the standard Kernel notification chain subsystem.

At initialization time each SCMI Protocol takes care to register with the
new SCMI notification core the set of its own events which it intends to
support.

Using the API exposed via scmi_handle.notify_ops a Kernel user can register
its own notifier_t callback (via a notifier_block as usual) against any
registered event as identified by the tuple:

		(proto_id, event_id, src_id)

where src_id represents a generic source identifier which is protocol
dependent like domain_id, performance_id, sensor_id and so forth.
(users can anyway do NOT provide any src_id, and subscribe instead to ALL
 the existing (if any) src_id sources for that proto_id/evt_id combination)

Each of the above tuple-specified events will be served on its own
dedicated blocking notification chain, dynamically allocated on-demand when
at least one user has shown interest on that event.

Upon a notification delivery all the users' registered notifier_t callbacks
will be in turn invoked and fed with the event_id as @action param and a
generated custom per-event struct _report as @data param.
(as in include/linux/scmi_protocol.h)

The final step of notification delivery via users' callback invocation is
instead delegated to a pool of deferred workers (Kernel cmwq): each
SCMI protocol has its own dedicated worker and dedicated queue to push
events from the rx ISR to the worker.

Based on scmi-next/for-next/scmi 5.8-rc3 [1], on top of:

commit 29c9e984d8e3 ("firmware: arm_scmi: Fix SCMI genpd domain probing")

This series has been tested on JUNO with an experimental firmware only
supporting Perf Notifications.


Thanks

Cristian

----
v10 --> v11:
- fixed macros for argument reuse checkpatch warning
- added missing mutex comments
- removed improper usage of IS_ERR_OR_NULL
- switch to int retvals for some core functions instead of bools
- removed all likely/unlikely

v9 --> v10:
- rebased on top of scmi-next 5.8-rc1
- fixed a couple of Warnings (-Wtype-limit)

v8 --> v9:
- rebased on top of scmi-next 5.8
- moved some pr_info() to dev_dbg()
- moved around some macros definitions (using FIELD_PREPARE properly)
- introduced some meaningful define
- shrunk hashtables' sizes
- shortened the naming of some massively long data struct

v7 --> v8:
- removed unneeded initialized/enabled atomics, added proper barriers
- added a few comments about queueing work item and kfifos

v6 --> v7:
- rebased on top of scmi-next 5.7, dropped the initial 4 patches
  since now already queued on base scmi-next [1]
- fixed some events' proto initialization
- removed some notify_enabled explicit methods exposed in some protocol_ops
  since not supposed to be used directly when using this notification
  framework (and of no other known use)
- exposing SCMI_EVENT_ enums in scmi_protocol.h
- added agent_id field in RESET_ISSUED payload as per reviewed SCMI spec
- removed POWER_STATE_CHANGE_REQUESTED pre-notification definition and
  handling as per reviewedSCMI spec
- fixed report.timestamp field type

v5 --> v6:
- added handle argument to fill_custom_report() helper

v4 --> v5:
- fixed kernel-doc
- added proper barriers around registered protocols and events
  initialization
- reviewed queues allocation using devm_add_action_or_reset
- reviewed REVT_NOTIFY_ENABLE macro

v3 --> v4:
- dropped RFC tag
- avoid one unneeded evt payload memcpy on the ISR RC code path by
  redesigning dispatcher to handle partial queue-reads (in_flight events,
  only header)
- fixed the initialization issue exposed by late SCMI modules loading by
  reviewing the init process to support possible late events registrations
  by protocols and early callbacks registrations by users (pending)
- cleanup/simplification of exit path: SCMI protocols are generally never
  de-initialized after the initial device creation, so do not deinit
  notification core either (we do halt the delivery, stop the wq and empty
  the queues though)
- reduced contention on regustered_events_handler to the minimum during
  delivery by splitting the common registered_events_handlers hashtable
  into a number of per-protocol tables
- converted registered_protocols and registered_events hastable to
  fixed size arrays: simpler and lockless in our usage scenario

v2 --> v3:
- added platform instance awareness to the notification core: a
  notification instance is created for each known handle
- reviewed notification core initialization and shutdown process
- removed generic non-handle-rooted registration API
- added WQ_SYSFS flag to workqueue instance

v1 --> v2:
- dropped anti-tampering patch
- rebased on top of scmi-for-next-5.6, which includes Viresh series that
  make SCMI core independent of transport (5c8a47a5a91d)
- add a few new SCMI transport methods on top of Viresh patch to address
  needs of SCMI Notifications
- reviewed/renamed scmi_handle_xfer_delayed_resp()
- split main SCMI Notification core patch (~1k lines) into three chunks:
  protocol-registration / callbacks-registration / dispatch-and-delivery
- removed awkward usage of IDR maps in favour of pure hashtables
- added enable/disable refcounting in notification core (was broken in v1)
- removed per-protocol candidate API: a single generic API is now proposed
  instead of scmi_register_<proto>_event_notifier(evt_id, *src_id, *nb)
- added handle->notify_ops as an alternative notification API
  for scmi_driver
- moved ALL_SRCIDs enabled handling from protocol code to core code
- reviewed protocol registration/unregistration logic to use devres
- reviewed cleanup phase on shutdown
- fixed  ERROR: reference preceded by free as reported by kbuild test robot

[1] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git

Cristian Marussi (9):
  firmware: arm_scmi: Add notification protocol-registration
  firmware: arm_scmi: Add notification callbacks-registration
  firmware: arm_scmi: Add notification dispatch and delivery
  firmware: arm_scmi: Enable notification core
  firmware: arm_scmi: Add power notifications support
  firmware: arm_scmi: Add perf notifications support
  firmware: arm_scmi: Add sensor notifications support
  firmware: arm_scmi: Add reset notifications support
  firmware: arm_scmi: Add base notifications support

 drivers/firmware/arm_scmi/Makefile  |    2 +-
 drivers/firmware/arm_scmi/base.c    |  108 +-
 drivers/firmware/arm_scmi/common.h  |    4 +
 drivers/firmware/arm_scmi/driver.c  |   10 +
 drivers/firmware/arm_scmi/notify.c  | 1525 +++++++++++++++++++++++++++
 drivers/firmware/arm_scmi/notify.h  |   66 ++
 drivers/firmware/arm_scmi/perf.c    |  139 ++-
 drivers/firmware/arm_scmi/power.c   |   92 +-
 drivers/firmware/arm_scmi/reset.c   |   96 +-
 drivers/firmware/arm_scmi/sensors.c |   69 +-
 include/linux/scmi_protocol.h       |  108 +-
 11 files changed, 2189 insertions(+), 30 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/notify.c
 create mode 100644 drivers/firmware/arm_scmi/notify.h

Comments

Sudeep Holla July 3, 2020, 2:49 p.m. UTC | #1
On Wed, 1 Jul 2020 16:53:39 +0100, Cristian Marussi wrote:
> this series wants to introduce SCMI Notification Support, built on top of
> the standard Kernel notification chain subsystem.
> 
> At initialization time each SCMI Protocol takes care to register with the
> new SCMI notification core the set of its own events which it intends to
> support.
> 
> [...]


Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/9] firmware: arm_scmi: Add notification protocol-registration
      https://git.kernel.org/sudeep.holla/c/1fc2dd1864
[2/9] firmware: arm_scmi: Add notification callbacks-registration
      https://git.kernel.org/sudeep.holla/c/e7c215f358
[3/9] firmware: arm_scmi: Add notification dispatch and delivery
      https://git.kernel.org/sudeep.holla/c/bd31b24969
[4/9] firmware: arm_scmi: Enable notification core
      https://git.kernel.org/sudeep.holla/c/6b8a69131d
[5/9] firmware: arm_scmi: Add power notifications support
      https://git.kernel.org/sudeep.holla/c/e27077bc04
[6/9] firmware: arm_scmi: Add perf notifications support
      https://git.kernel.org/sudeep.holla/c/fb5086dc47
[7/9] firmware: arm_scmi: Add sensor notifications support
      https://git.kernel.org/sudeep.holla/c/128e3e9311
[8/9] firmware: arm_scmi: Add reset notifications support
      https://git.kernel.org/sudeep.holla/c/469ca1822d
[9/9] (korg_sudeep/for-next/scmi) firmware: arm_scmi: Add base notifications support
      https://git.kernel.org/sudeep.holla/c/585dfab3fb

--
Regards,
Sudeep
Sudeep Holla July 3, 2020, 2:49 p.m. UTC | #2
On Wed, 17 Jun 2020 10:43:31 +0100, Nicola Mazzucato wrote:
> Add a new fast_switch_possible interface to the existing
> perf_ops api to export the information of whether or not
> fast_switch is possible in this driver.
> 
> This can be used by the CPUFreq driver and framework to
> choose proper mechanism for frequency change.


Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/2] firmware: arm_scmi: Add fast_switch_possible() interface
      https://git.kernel.org/sudeep.holla/c/1909872ff2
[2/2] cpufreq: arm_scmi: Set fast_switch_possible conditionally
      https://git.kernel.org/sudeep.holla/c/fb3571276b

--
Regards,
Sudeep
Sudeep Holla July 3, 2020, 2:49 p.m. UTC | #3
On Thu, 25 Jun 2020 11:19:37 +0100, Sudeep Holla wrote:
> Commit e5bfb21d98b6 ("firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to
> identify SMCCC v1.1 and above") introduced new config option to identify
> the availability of SMCCC discoverability of version and features
> transparently hiding the indirect dependency on ARM_PSCI_FW.
> 
> Commit 5a897e3ab429 ("firmware: arm_scmi: fix psci dependency") just
> worked around the build dependency making SCMI SMC/HVC transport depend
> on ARM_PSCI_FW at the time. Since it really just relies on SMCCC directly
> and not on ARM_PSCI_FW, let us move to use CONFIG_HAVE_ARM_SMCCC_DISCOVERY
> instead of CONFIG_ARM_PSCI_FW.


Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/1] firmware: arm_scmi: Use HAVE_ARM_SMCCC_DISCOVERY instead of ARM_PSCI_FW
      https://git.kernel.org/sudeep.holla/c/d764282377

--
Regards,
Sudeep
Sudeep Holla July 3, 2020, 2:49 p.m. UTC | #4
On Tue, 9 Jun 2020 14:45:03 +0100, Sudeep Holla wrote:
> Currently the trace event 'scmi_xfer_end' reports the status of the
> transfer using the unsigned status field read from the firmware. This
> may not be easy to interpret and also may miss to present any timeouts
> that happen in the driver.
> 
> Let us use signed integer so that error values are emitted out after
> they are mapped from firmware errors to standard linux error codes.
> While at this, let us also include any timeouts in the driver itself.


Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/1] firmware: arm_scmi: Use signed integer to report transfer status
      https://git.kernel.org/sudeep.holla/c/bad0d73b65

--
Regards,
Sudeep