[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Mfh+WQx-vasZed6jWi5nUjg=K+ScVRBMCiFgK397=JbVg@mail.gmail.com>
Date: Mon, 3 Nov 2025 16:46:37 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Shivendra Pratap <shivendra.pratap@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
Unnathi Chalicheemala <unnathi.chalicheemala@....qualcomm.com>
Subject: Re: [PATCH v8 2/3] firmware: qcom_scm: Support multiple waitq contexts
On Sun, Nov 2, 2025 at 9:19 AM Shivendra Pratap
<shivendra.pratap@....qualcomm.com> wrote:
>
> From: Unnathi Chalicheemala <unnathi.chalicheemala@....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@....qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@....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.
Bartosz
Powered by blists - more mailing lists