lkml.org 
[lkml]   [2020]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v2 07/13] firmware: arm_scmi: Add notification dispatch and delivery
From
Date
Hi Cristian,

I didn't want to jump into your discussion with Jim in other broader
thread with this small thought, so I added a comment below.

On 2/14/20 3:35 PM, Cristian Marussi wrote:
> Add core SCMI Notifications dispatch and delivery support logic which is
> able, at first, to dispatch well-known received events from the RX ISR to
> the dedicated deferred worker, and then, from there, to final deliver the
> events to the registered users' callbacks.
>
> Dispatch and delivery is just added here, still not enabled.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> V1 --> V2
> - splitted out of V1 patch 04
> - moved from IDR maps to real HashTables to store event_handlers
> - simplified delivery logic
> ---
> drivers/firmware/arm_scmi/notify.c | 242 ++++++++++++++++++++++++++++-
> drivers/firmware/arm_scmi/notify.h | 22 +++
> 2 files changed, 262 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/notify.c b/drivers/firmware/arm_scmi/notify.c
> index 1339b6de0a4c..c2341c5304cf 100644
> --- a/drivers/firmware/arm_scmi/notify.c
> +++ b/drivers/firmware/arm_scmi/notify.c
> @@ -48,13 +48,44 @@
> * particular event coming only from a well defined source (like CPU vs GPU).
> * When the source is not specified the user callback will be registered for
> * all existing sources for that event (if any).

[snip]

>
> @@ -840,6 +1071,11 @@ static struct scmi_notify_ops notify_ops = {
> */
> int scmi_notification_init(struct scmi_handle *handle)
> {
> + scmi_notify_wq = alloc_workqueue("scmi_notify",
> + WQ_UNBOUND | WQ_FREEZABLE, 0);

I think it might limit some platforms. It depends on their workload.
If they have some high priority workloads which rely on this mechanisms,
they might need a RT task here. The workqueues would be scheduled in
CFS, so it depends on workload in there (we might even see 10s ms delays
in scheduling-up them). If we use RT we would grab the CPU from CFS.

It would be good if it is a customization option: which mechanism
to use based on some a parameter. Then we could create:
a) workqueue with the flags above
b) workqueue with WQ_HIGHPRI (limited by minimum nice)
c) kthread_create_worker() with RT/DL/FIFO sched policy
(with also a parameterized priority)

In default clients might use a) but when they want to tune their
platform, they might change only a parameter in their scmi code,
not maintaining a patch for the RT function out of tree.

Regards,
Lukasz

\
 
 \ /
  Last update: 2020-02-21 14:26    [W:0.121 / U:3.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site