From: rishabhb@codeaurora.org
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: ohad@wizery.com, tsoni@codeaurora.org,
linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, bjorn.andersson@linaro.org,
agross@kernel.org, Siddharth Gupta <sidgup@codeaurora.org>,
psodagud@codeaurora.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 6/6] remoteproc: qcom: Add notification types to SSR
Date: Thu, 27 Feb 2020 16:00:21 -0800 [thread overview]
Message-ID: <1a615fcd5a5c435d1d8babe8d5c3f8c3@codeaurora.org> (raw)
In-Reply-To: <20200227215940.GC20116@xps15>
On 2020-02-27 13:59, Mathieu Poirier wrote:
> On Wed, Feb 19, 2020 at 06:57:45PM -0800, Siddharth Gupta wrote:
>> The SSR subdevice only adds callback for the unprepare event. Add
>> callbacks
>> for unprepare, start and prepare events. The client driver for a
>> particular
>> remoteproc might be interested in knowing the status of the remoteproc
>> while undergoing SSR, not just when the remoteproc has finished
>> shutting
>> down.
>>
>> Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
>> ---
>> drivers/remoteproc/qcom_common.c | 39
>> +++++++++++++++++++++++++++++++++++----
>> include/linux/remoteproc.h | 15 +++++++++++++++
>> 2 files changed, 50 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/remoteproc/qcom_common.c
>> b/drivers/remoteproc/qcom_common.c
>> index 6714f27..6f04a5b 100644
>> --- a/drivers/remoteproc/qcom_common.c
>> +++ b/drivers/remoteproc/qcom_common.c
>> @@ -183,9 +183,9 @@ EXPORT_SYMBOL_GPL(qcom_remove_smd_subdev);
>> *
>> * Returns pointer to srcu notifier head on success, ERR_PTR on
>> failure.
>> *
>> - * This registers the @notify function as handler for restart
>> notifications. As
>> - * remote processors are stopped this function will be called, with
>> the rproc
>> - * pointer passed as a parameter.
>> + * This registers the @notify function as handler for
>> powerup/shutdown
>> + * notifications. This function will be invoked inside the callbacks
>> registered
>> + * for the ssr subdevice, with the rproc pointer passed as a
>> parameter.
>> */
>> void *qcom_register_ssr_notifier(struct rproc *rproc, struct
>> notifier_block *nb)
>> {
>> @@ -227,11 +227,39 @@ int qcom_unregister_ssr_notifier(void *notify,
>> struct notifier_block *nb)
>> }
>> EXPORT_SYMBOL_GPL(qcom_unregister_ssr_notifier);
>>
>> +static int ssr_notify_prepare(struct rproc_subdev *subdev)
>> +{
>> + struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
>> +
>> + srcu_notifier_call_chain(ssr->rproc_notif_list,
>> + RPROC_BEFORE_POWERUP, (void *)ssr->name);
>> + return 0;
>> +}
>> +
>> +static int ssr_notify_start(struct rproc_subdev *subdev)
>> +{
>> + struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
>> +
>> + srcu_notifier_call_chain(ssr->rproc_notif_list,
>> + RPROC_AFTER_POWERUP, (void *)ssr->name);
>> + return 0;
>> +}
>> +
>> +static void ssr_notify_stop(struct rproc_subdev *subdev, bool
>> crashed)
>> +{
>> + struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
>> +
>> + srcu_notifier_call_chain(ssr->rproc_notif_list,
>> + RPROC_BEFORE_SHUTDOWN, (void *)ssr->name);
>> +}
>> +
>> +
>> static void ssr_notify_unprepare(struct rproc_subdev *subdev)
>> {
>> struct qcom_rproc_ssr *ssr = to_ssr_subdev(subdev);
>>
>> - srcu_notifier_call_chain(ssr->rproc_notif_list, 0, (void
>> *)ssr->name);
>> + srcu_notifier_call_chain(ssr->rproc_notif_list,
>> + RPROC_AFTER_SHUTDOWN, (void *)ssr->name);
>> }
>>
>> /**
>> @@ -248,6 +276,9 @@ void qcom_add_ssr_subdev(struct rproc *rproc,
>> struct qcom_rproc_ssr *ssr,
>> {
>> ssr->name = ssr_name;
>> ssr->subdev.name = kstrdup("ssr_notifs", GFP_KERNEL);
>> + ssr->subdev.prepare = ssr_notify_prepare;
>> + ssr->subdev.start = ssr_notify_start;
>> + ssr->subdev.stop = ssr_notify_stop;
>
> Now that I have a better understanding of what this patchset is doing,
> I realise
> my comments in patch 04 won't work. To differentiate the subdevs of an
> rproc I
> suggest to wrap them in a generic structure with a type and an enum.
> That way
> you can differenciate between subdevices without having to add to the
> core.
Ok. I can try that.
>
> That being said, I don't understand what patches 5 and 6 are doing...
> Registering with the global ssr_notifiers allowed to gracefully
> shutdown all the
> MCUs in the system when one of them would go down. But now that we are
> using
> the notifier on a per MCU, I really don't see why each subdev couldn't
> implement
> the right prepare/start/stop functions.
>
> Am I missing something here?
We only want kernel clients to be notified when the Remoteproc they are
interested
in changes state. For e.g. audio kernel driver should be notified when
audio
processor goes down but it does not care about any other remoteproc.
If you are suggesting that these kernel clients be added as subdevices
then
we will end up having many subdevices registered to each remoteproc. So
we
implemented a notifier chain per Remoteproc. This keeps the SSR
notifications as
the subdevice per remoteproc, and all interested clients can register to
it.
>
>
>> ssr->subdev.unprepare = ssr_notify_unprepare;
>> ssr->rproc_notif_list = kzalloc(sizeof(struct srcu_notifier_head),
>> GFP_KERNEL);
>> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
>> index e2f60cc..4be4478 100644
>> --- a/include/linux/remoteproc.h
>> +++ b/include/linux/remoteproc.h
>> @@ -449,6 +449,21 @@ struct rproc_dump_segment {
>> };
>>
>> /**
>> + * enum rproc_notif_type - Different stages of remoteproc
>> notifications
>> + * @RPROC_BEFORE_SHUTDOWN: unprepare stage of remoteproc
>> + * @RPROC_AFTER_SHUTDOWN: stop stage of remoteproc
>> + * @RPROC_BEFORE_POWERUP: prepare stage of remoteproc
>> + * @RPROC_AFTER_POWERUP: start stage of remoteproc
>> + */
>> +enum rproc_notif_type {
>> + RPROC_BEFORE_SHUTDOWN,
>> + RPROC_AFTER_SHUTDOWN,
>> + RPROC_BEFORE_POWERUP,
>> + RPROC_AFTER_POWERUP,
>> + RPROC_MAX
>> +};
>> +
>> +/**
>> * struct rproc - represents a physical remote processor device
>> * @node: list node of this rproc object
>> * @domain: iommu domain
>> --
>> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-28 0:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-20 2:57 [PATCH 0/6] remoteproc: qcom: Add callbacks for remoteproc events Siddharth Gupta
2020-02-20 2:57 ` [PATCH 1/6] remoteproc: sysmon: Add ability to send type of notification Siddharth Gupta
2020-02-20 2:57 ` [PATCH 2/6] remoteproc: sysmon: Add notifications for events Siddharth Gupta
2020-02-20 2:57 ` [PATCH 3/6] remoteproc: sysmon: Inform current rproc about all active rprocs Siddharth Gupta
2020-02-27 18:47 ` Mathieu Poirier
2020-02-20 2:57 ` [PATCH 4/6] drivers: remoteproc: Add name field for every subdevice Siddharth Gupta
2020-02-27 20:14 ` Mathieu Poirier
2020-02-20 2:57 ` [PATCH 5/6] remoteproc: qcom: Add per subsystem SSR notification Siddharth Gupta
2020-02-20 2:57 ` [PATCH 6/6] remoteproc: qcom: Add notification types to SSR Siddharth Gupta
2020-02-27 21:59 ` Mathieu Poirier
2020-02-28 0:00 ` rishabhb [this message]
2020-02-28 18:38 ` Mathieu Poirier
2020-03-02 20:54 ` rishabhb
2020-03-03 18:05 ` Mathieu Poirier
2020-03-03 23:30 ` rishabhb
2020-03-09 17:34 ` Mathieu Poirier
2020-04-02 1:01 ` Siddharth Gupta
2020-04-02 17:47 ` Mathieu Poirier
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=1a615fcd5a5c435d1d8babe8d5c3f8c3@codeaurora.org \
--to=rishabhb@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=ohad@wizery.com \
--cc=psodagud@codeaurora.org \
--cc=sidgup@codeaurora.org \
--cc=tsoni@codeaurora.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).