From: Guru Das Srinagesh <quic_gurus@quicinc.com>
To: Rajendra Nayak <quic_rjendra@quicinc.com>
Cc: Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
"David Heidelberg" <david@ixit.cz>,
Robert Marko <robimarko@gmail.com>,
Elliot Berman <quic_eberman@quicinc.com>
Subject: Re: [PATCH 5/5] firmware: qcom: scm: Add wait-queue handling logic
Date: Wed, 13 Jul 2022 17:57:35 -0700 [thread overview]
Message-ID: <20220714005735.GA22183@quicinc.com> (raw)
In-Reply-To: <ad5e875d-e5d7-3b6f-4915-98ba08df8c5d@quicinc.com>
On Jul 01 2022 16:51, Rajendra Nayak wrote:
>
>
> On 7/1/2022 4:32 PM, Rajendra Nayak wrote:
> >
> >
> >On 6/28/2022 1:14 AM, Guru Das Srinagesh wrote:
> >>Add logic to handle QCOM_SCM_WAITQ_SLEEP or QCOM_SCM_WAITQ_WAKE return
> >>codes.
> >>
> >>Scenario 1: Requests made by 2 different VMs:
> >>
> >> VM_1 VM_2 Firmware
> >> │ │ │
> >> │ │ │
> >> │ │ │
> >> │ │ │
> >> │ REQUEST_1 │ │
> >> ├────────────────────────┼─────────────────────────────────┤
> >> │ │ │
> >> │ │ ┌──┼──┐
> >> │ │ │ │ │
> >> │ │ REQUEST_2 │ │ │
> >> │ ├──────────────────────────────┼──┤ │
> >> │ │ │ │ │Resource
> >> │ │ │ │ │is busy
> >> │ │ {WQ_SLEEP} │ │ │
> >> │ │◄─────────────────────────────┼──┤ │
> >> │ │ wq_ctx, smc_call_ctx │ │ │
> >> │ │ └──┼──┘
> >> │ REQUEST_1 COMPLETE │ │
> >> │◄───────────────────────┼─────────────────────────────────┤
> >> │ │ │
> >> │ │ IRQ │
> >> │ │◄─-------------------------------│
> >> │ │ │
> >> │ │ get_wq_ctx() │
> >> │ ├────────────────────────────────►│
> >> │ │ │
> >> │ │ │
> >> │ │◄────────────────────────────────┤
> >> │ │ wq_ctx, flags, and │
> >> │ │ more_pending │
> >> │ │ │
> >> │ │ │
> >> │ │ wq_resume(smc_call_ctx) │
> >> │ ├────────────────────────────────►│
> >> │ │ │
> >> │ │ │
> >> │ │ REQUEST_2 COMPLETE │
> >> │ │◄────────────────────────────────┤
> >> │ │ │
> >> │ │ │
> >>
> >>Scenario 2: Two Requests coming in from same VM:
> >>
> >> VM_1 Firmware
> >> │ │
> >> │ │
> >> │ │
> >> │ │
> >> │ REQUEST_1 │
> >> ├──────────────────────────────────────────────────────────┤
> >> │ │
> >> │ ┌────┼───┐
> >> │ │ │ │
> >> │ │ │ │
> >> │ │ │ │
> >> │ REQUEST_2 │ │ │
> >> ├─────────────────────────────────────────────────────┼───►│ │
> >> │ │ │ │Resource
> >> │ │ │ │is busy
> >> │ {WQ_SLEEP} │ │ │
> >> │◄────────────────────────────────────────────────────┼────┤ │
> >> │ wq_ctx, req2_smc_call_ctx │ │ │
> >> │ │ │ │
> >> │ └────┼───┘
> >> │ │
> >> │ {WQ_WAKE} │
> >> │◄─────────────────────────────────────────────────────────┤
> >> │ wq_ctx, req1_smc_call_ctx, flags │
> >
> >
> >This is perhaps the same thing I asked on the previous patch,
> >I am guessing {WQ_WAKE} is returned in respone to REQUEST_1?
> >How do you know in this case if REQUEST_1 was a success or failure?
> >
>
> Ok looking at this some more, I think what we are saying is that the FW returns
> {WQ_WAKE} to REQUEST_1, we then call wq_wake_ack and the return of
> *that* will tell if REQUEST_1 was success or failure?
> Did I get it right?
Yes, that is correct. I should have added an explanatory note in the commit
message to this effect:
│ {WQ_WAKE} <-- Return value │
│◄─────────────────────────────────────────────────────────┤
│ wq_ctx, req1_smc_call_ctx, flags <-- Its payload │
What this means is that the WQ_WAKE is sent by the FW to VM1 (direction of
arrow is from right to left) and that the additional data packed as payload
indicate that it is meant for REQUEST_1 (`req1_smc_call_ctx`).
Hopefully this will help understand the diagram better.
Thank you.
Guru Das.
next prev parent reply other threads:[~2022-07-14 0:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 19:44 [PATCH 0/5] SCM: Add support for wait-queue aware firmware Guru Das Srinagesh
2022-06-27 19:44 ` [PATCH 1/5] dt-bindings: firmware: qcom-scm: Add "allow-multi-call" property Guru Das Srinagesh
2022-06-27 19:44 ` [PATCH 2/5] firmware: qcom: scm: Optionally remove SCM call serialization Guru Das Srinagesh
2022-06-27 19:44 ` [PATCH 3/5] dt-bindings: firmware: qcom-scm: Add optional interrupt Guru Das Srinagesh
2022-06-27 19:44 ` [PATCH 4/5] firmware: qcom: scm: Add wait-queue helper functions Guru Das Srinagesh
2022-06-28 13:33 ` Rajendra Nayak
2022-06-28 17:43 ` Guru Das Srinagesh
2022-07-14 1:04 ` Guru Das Srinagesh
2022-07-01 10:59 ` Rajendra Nayak
2022-07-14 1:04 ` Guru Das Srinagesh
2022-06-27 19:44 ` [PATCH 5/5] firmware: qcom: scm: Add wait-queue handling logic Guru Das Srinagesh
2022-07-01 11:02 ` Rajendra Nayak
2022-07-01 11:21 ` Rajendra Nayak
2022-07-14 0:57 ` Guru Das Srinagesh [this message]
2022-07-19 10:33 ` Rajendra Nayak
2022-07-21 16:50 ` Guru Das Srinagesh
2022-07-21 16:48 ` Guru Das Srinagesh
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=20220714005735.GA22183@quicinc.com \
--to=quic_gurus@quicinc.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=david@ixit.cz \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=quic_eberman@quicinc.com \
--cc=quic_rjendra@quicinc.com \
--cc=robimarko@gmail.com \
/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).