Message ID | 20200520081118.54897-1-cristian.marussi@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | SCMI Notifications Core Support | expand |
Hi Cristian, On Wed, May 20, 2020 at 09:11:09AM +0100, Cristian Marussi wrote: > 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 eventis 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.7 [1], on top of: > > commit f7199cf48902 ("firmware: arm_scmi: Fix return error code in > smc_send_message") > > This series has been tested on JUNO with an experimental firmware only > supporting Perf Notifications. > Thanks for working on this. Looks mostly OK. I have few minor comments or queries. -- Regards, Sudeep