mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Subject: Re: [PATCH v8 2/3] firmware: qcom_scm: Support multiple waitq contexts
Date: Mon, 3 Nov 2025 21:46:17 +0530	[thread overview]
Message-ID: <da04aa57-f3dc-9bcd-5ba3-05088a6661ab@oss.qualcomm.com> (raw)
In-Reply-To: <CAMRc=Mfh+WQx-vasZed6jWi5nUjg=K+ScVRBMCiFgK397=JbVg@mail.gmail.com>



On 11/3/2025 9:16 PM, Bartosz Golaszewski wrote:
> On Sun, Nov 2, 2025 at 9:19 AM Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> wrote:
>>
>> From: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
>>
>> Currently, only a single waitqueue context exists in the driver.
>> Multi-waitqueue mechanism is added in firmware to support the case,
>> when multiple VMs make SMC calls or single VM making multiple calls on
>> same CPU. Enhance the driver to support multiple waitqueue when
>> support is present in the firmware.
>>
>> When VMs make a SMC call, firmware allocates a waitqueue context,
>> assuming the SMC call to be a blocking call. The SMC calls that cannot
>> acquire resources, while execution in firmware, are returned to sleep
>> in the calling VM. When the resource becomes available in the
>> firmware, the VM gets notified to wake the sleeping thread and resume
>> SMC call. The current qcom_scm driver supports single waitqueue as the
>> old firmwares support only single waitqueue with waitqueue id zero.
>> Multi-waitqueue mechanism is added in firmware starting SM8650 to
>> support the case when multiple VMs make SMC calls or single VM making
>> multiple calls on same CPU. To enable this support in qcom_scm driver,
>> add support for handling multiple waitqueues. For instance, SM8650
>> firmware can allocate two such waitq contexts, so the driver needs to
>> implement two waitqueue contexts. For a generalized approach, the
>> number of supported waitqueues can be queried from the firmware using
>> a SMC call.
>>
>> Introduce qcom_scm_query_waitq_count to get the number of waitqueue
>> contexts supported by the firmware and allocate “N” unique waitqueue
>> contexts with a dynamic sized array where each unique wq_ctx is
>> associated with a struct completion variable for easy lookup. Older
>> targets which support only a single waitqueue, may return an error for
>> qcom_scm_query_waitq_count, set the wq_cnt to one for such failures.
>>
>> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>>  drivers/firmware/qcom/qcom_scm.c | 75 ++++++++++++++++++++++++++++------------
>>  1 file changed, 53 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
>> index 28979f95e51fbee94b84c1570a4d88a76f72db4e..0b6efa7c2bdc25a3ba152c25d5451d1154779ddd 100644
>> --- a/drivers/firmware/qcom/qcom_scm.c
>> +++ b/drivers/firmware/qcom/qcom_scm.c
>> @@ -47,7 +47,7 @@ struct qcom_scm {
>>         struct clk *iface_clk;
>>         struct clk *bus_clk;
>>         struct icc_path *path;
>> -       struct completion waitq_comp;
>> +       struct completion *waitq;
> 
> Why this change? This makes the name less descriptive if not misleading.

Want to make it dynamic array of waitq`s. Should the name be kept as 
struct completion *waitq_comp; ?

thanks,
Shivendra

  reply	other threads:[~2025-11-03 16:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02  8:18 [PATCH v8 0/3] SCM: Support latest version of waitq-aware firmware Shivendra Pratap
2025-11-02  8:18 ` [PATCH v8 1/3] firmware: qcom_scm: Add API to get waitqueue IRQ info Shivendra Pratap
2025-11-02  8:18 ` [PATCH v8 2/3] firmware: qcom_scm: Support multiple waitq contexts Shivendra Pratap
2025-11-03 15:46   ` Bartosz Golaszewski
2025-11-03 16:16     ` Shivendra Pratap [this message]
2025-11-03 16:59       ` Bartosz Golaszewski
2025-11-03 17:05         ` Shivendra Pratap
2025-11-02  8:18 ` [PATCH v8 3/3] firmware: qcom_scm: Check for waitq state in wait_for_wq_completion() Shivendra Pratap
2025-11-03 15:51   ` Bartosz Golaszewski
2025-11-17 18:13     ` Shivendra Pratap

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=da04aa57-f3dc-9bcd-5ba3-05088a6661ab@oss.qualcomm.com \
    --to=shivendra.pratap@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=unnathi.chalicheemala@oss.qualcomm.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

all inboxes | Powered by JetHome®