From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B10F33AE1A5; Mon, 13 Apr 2026 14:50:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776091844; cv=none; b=Nc7slZ01lZclRkQCovY/leVpYdoHlEtsIlzyTj4WVhhnemufO6o3r+nTeIsDGtzm98CQA/NTYC3MG5txgurGdUVQpsOJvR6Hadi78/xKENHMPe7UEdbV8uxVQED8hSzXuqWNtUOnmVQkMAyRarxJiNLzbRusA5fTMMGStC4yvFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776091844; c=relaxed/simple; bh=RECNt4Lj0uwevLFCfiPVoqNfQbV8zEH+K0iuVtBlQZk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mpChUSd0p5Gcw0pNzEudEQPQEv+3C/o0ja0gWwf4IgTPUvBxjgOem7hMNCg21+isbNkb+FbTbgbP8hR5Xfd9ufHaTNMjEDJLv84I03x7CjcGbciaNur4GAfIW3vBfMXGkQiJfRebAiGqTI01QQEAlHvrSB+K+o9H663qikerADc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Su5pzllN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Su5pzllN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B255C2BCB0; Mon, 13 Apr 2026 14:50:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776091844; bh=RECNt4Lj0uwevLFCfiPVoqNfQbV8zEH+K0iuVtBlQZk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Su5pzllNMGZfoZ78Xyx8urjSNVj3ZR0SIpjhPPXpOkaycMAP8QQQfC7/7QKSF8v/k fbFCaSv8huvFeyngo0egOXORaznaDj2j3cGwwscED9aAIKEY+8kbz8MtmahFnQ4rg2 gsspsWJBfVG/38bmkPuUfTx0USK+BcZkVzmp8xTjnHFS1xmXDKGEyYzz6/bo6oZGV3 7hhIw0azf65hUJEVBlQsZGRwJo6GkxZEAOr1WZQhxQ0WgrDtY0PEe1hoXNK+EaS+4j 1xCov8NQtceNtUNC0a0exjOaT87XfHl7/+1yYKFeaSpHwOMog0m9GcKP1lVtdXE+bI p86g08zQK77Jg== Message-ID: <86853aa3-4af2-4670-a58e-342877e81ef9@kernel.org> Date: Mon, 13 Apr 2026 14:50:41 +0000 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 4/4] misc: fastrpc: Add polling mode support for fastRPC driver To: Ekansh Gupta , srini@kernel.org, linux-arm-msm@vger.kernel.org Cc: gregkh@linuxfoundation.org, quic_bkumar@quicinc.com, linux-kernel@vger.kernel.org, quic_chennak@quicinc.com, dri-devel@lists.freedesktop.org, arnd@arndb.de, dmitry.baryshkov@oss.qualcomm.com, andersson@kernel.org, konrad.dybcio@oss.qualcomm.com References: <20260402054923.3061925-1-ekansh.gupta@oss.qualcomm.com> <20260402054923.3061925-5-ekansh.gupta@oss.qualcomm.com> Content-Language: en-US From: Srinivas Kandagatla In-Reply-To: <20260402054923.3061925-5-ekansh.gupta@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/2/26 5:49 AM, Ekansh Gupta wrote: > For any remote call to DSP, after sending an invocation message, > fastRPC driver waits for glink response and during this time the > CPU can go into low power modes. This adds latency to overall fastrpc > call as CPU wakeup and scheduling latencies are included. Add polling > mode support with which fastRPC driver will poll continuously on a > memory after sending a message to remote subsystem which will eliminate > CPU wakeup and scheduling latencies and reduce fastRPC overhead. In case > poll timeout happens, the call will fallback to normal RPC mode. Poll > mode can be enabled by user by using FASTRPC_IOCTL_SET_OPTION ioctl > request with FASTRPC_POLL_MODE request id. > > Signed-off-by: Ekansh Gupta > --- > drivers/misc/fastrpc.c | 132 ++++++++++++++++++++++++++++++++++-- > include/uapi/misc/fastrpc.h | 10 +++ > 2 files changed, 135 insertions(+), 7 deletions(-) > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > index 4363e0cc296b..25f385f4704d 100644 > --- a/drivers/misc/fastrpc.c > +++ b/drivers/misc/fastrpc.c > @@ -24,6 +24,8 @@ > #include > #include > #include > +#include > +#include > > #define ADSP_DOMAIN_ID (0) > #define MDSP_DOMAIN_ID (1) > @@ -38,6 +40,7 @@ > #define FASTRPC_CTX_MAX (256) > #define FASTRPC_INIT_HANDLE 1 > #define FASTRPC_DSP_UTILITIES_HANDLE 2 > +#define FASTRPC_MAX_STATIC_HANDLE (20) Document please. > #define FASTRPC_CTXID_MASK GENMASK(15, 8) > #define INIT_FILELEN_MAX (2 * 1024 * 1024) > #define INIT_FILE_NAMELEN_MAX (128) > @@ -106,6 +109,12 @@ > > #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev) > > +/* Poll response number from remote processor for call completion */ > +#define FASTRPC_POLL_RESPONSE (0xdecaf) > + > +/* Polling mode timeout limit */ > +#define FASTRPC_POLL_MAX_TIMEOUT_US (10000) > + > struct fastrpc_phy_page { > dma_addr_t addr; /* dma address */ > u64 size; /* size of contiguous region */ > @@ -236,8 +245,14 @@ struct fastrpc_invoke_ctx { > u32 sc; > u64 *fdlist; > u32 *crc; > + /* Poll memory that DSP updates */ > + u32 *poll; > u64 ctxid; > u64 msg_sz; > + /* work done status flag */ > + bool is_work_done; > + /* process updates poll memory instead of glink response */ > + bool is_polled; This looks redundant as the user context already has this info. > struct kref refcount; > struct list_head node; /* list of ctxs */ > struct completion work; > @@ -308,6 +323,8 @@ struct fastrpc_user { > int client_id; > int pd; > bool is_secure_dev; > + /* Flags poll mode state */ > + bool poll_mode; > /* Lock for lists */ > spinlock_t lock; > /* lock for allocations */ > @@ -923,7 +940,8 @@ static int fastrpc_get_meta_size(struct fastrpc_invoke_ctx *ctx) > sizeof(struct fastrpc_invoke_buf) + > sizeof(struct fastrpc_phy_page)) * ctx->nscalars + > sizeof(u64) * FASTRPC_MAX_FDLIST + > - sizeof(u32) * FASTRPC_MAX_CRCLIST; > + sizeof(u32) * FASTRPC_MAX_CRCLIST + > + sizeof(u32); > > return size; > } > @@ -1019,6 +1037,9 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx) > list = fastrpc_invoke_buf_start(rpra, ctx->nscalars); > pages = fastrpc_phy_page_start(list, ctx->nscalars); > ctx->fdlist = (u64 *)(pages + ctx->nscalars); > + ctx->poll = (u32 *)((uintptr_t)ctx->fdlist + sizeof(u64) * FASTRPC_MAX_FDLIST + > + sizeof(u32) * FASTRPC_MAX_CRCLIST); > + > args = (uintptr_t)ctx->buf->virt + metalen; > rlen = pkt_size - metalen; > ctx->rpra = rpra; > @@ -1188,6 +1209,74 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx, > > } > > +static inline u32 fastrpc_poll_op(void *p) > +{ > + struct fastrpc_invoke_ctx *ctx = p; > + > + dma_rmb(); > + return READ_ONCE(*ctx->poll); > +} > + > +static int poll_for_remote_response(struct fastrpc_invoke_ctx *ctx) > +{ > + u32 val; > + int ret; > + > + /* > + * Poll until DSP writes FASTRPC_POLL_RESPONSE into *ctx->poll > + * or until another path marks the work done. > + */ > + ret = read_poll_timeout_atomic(fastrpc_poll_op, val, > + (val == FASTRPC_POLL_RESPONSE) || ctx->is_work_done, 1, > + FASTRPC_POLL_MAX_TIMEOUT_US, false, ctx); What happens if the dsp sends normal response with rpcmsg callback while the loop is still going on? > + > + if (!ret && val == FASTRPC_POLL_RESPONSE) { check redundant? > + ctx->is_work_done = true; > + ctx->retval = 0; > + } > + > + if (ret == -ETIMEDOUT) > + ret = -EIO; > + > + return ret; > +} > + > +static inline int fastrpc_wait_for_response(struct fastrpc_invoke_ctx *ctx, > + u32 kernel) > +{ > + int err = 0; > + > + if (kernel) { > + if (!wait_for_completion_timeout(&ctx->work, 10 * HZ)) > + err = -ETIMEDOUT; > + } else { > + err = wait_for_completion_interruptible(&ctx->work); > + } > + > + return err; > +} > + > +static int fastrpc_wait_for_completion(struct fastrpc_invoke_ctx *ctx, > + u32 kernel) > +{ > + int err; > + > + do { > + if (ctx->is_polled) { > + err = poll_for_remote_response(ctx); > + /* If polling timed out, move to normal response mode */ > + if (err) > + ctx->is_polled = false; > + } else { > + err = fastrpc_wait_for_response(ctx, kernel); > + if (err) > + return err; > + } > + } while (!ctx->is_work_done); > + > + return 0; > +} > + > static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, > u32 handle, u32 sc, > struct fastrpc_invoke_args *args) > @@ -1223,13 +1312,14 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel, > if (err) > goto bail; > > - if (kernel) { > - if (!wait_for_completion_timeout(&ctx->work, 10 * HZ)) > - err = -ETIMEDOUT; > - } else { > - err = wait_for_completion_interruptible(&ctx->work); > - } > + /* > + * Set message context as polled if the call is for a user PD > + * dynamic module and user has enabled poll mode. > + */ > + if (handle > FASTRPC_MAX_STATIC_HANDLE && fl->pd == USER_PD && fl->poll_mode) > + ctx->is_polled = true; There seems to be some level of validation here, which is not clearly documented anywhere, can we add this into uapi header please. > > + err = fastrpc_wait_for_completion(ctx, kernel); > if (err) > goto bail; > > @@ -1812,6 +1902,30 @@ static int fastrpc_get_info_from_kernel(struct fastrpc_ioctl_capability *cap, > return 0; > } > > +static int fastrpc_set_option(struct fastrpc_user *fl, char __user *argp) > +{ > + struct fastrpc_ioctl_set_option opt = {0}; > + int i; > + > + if (copy_from_user(&opt, argp, sizeof(opt))) > + return -EFAULT; > + > + for (i = 0; i < ARRAY_SIZE(opt.reserved); i++) { > + if (opt.reserved[i] != 0) > + return -EINVAL; > + } > + > + if (opt.req != FASTRPC_POLL_MODE) > + return -EINVAL; > + > + if (opt.value) > + fl->poll_mode = true; > + else > + fl->poll_mode = false; > + > + return 0; > +} > + > static int fastrpc_get_dsp_info(struct fastrpc_user *fl, char __user *argp) > { > struct fastrpc_ioctl_capability cap = {0}; > @@ -2167,6 +2281,9 @@ static long fastrpc_device_ioctl(struct file *file, unsigned int cmd, > case FASTRPC_IOCTL_MEM_UNMAP: > err = fastrpc_req_mem_unmap(fl, argp); > break; > + case FASTRPC_IOCTL_SET_OPTION: > + err = fastrpc_set_option(fl, argp); > + break; > case FASTRPC_IOCTL_GET_DSP_INFO: > err = fastrpc_get_dsp_info(fl, argp); > break; > @@ -2518,6 +2635,7 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data, > } > > ctx->retval = rsp->retval; > + ctx->is_work_done = true; > complete(&ctx->work); > > /* > diff --git a/include/uapi/misc/fastrpc.h b/include/uapi/misc/fastrpc.h > index c6e2925f47e6..c37e24a764ae 100644 > --- a/include/uapi/misc/fastrpc.h > +++ b/include/uapi/misc/fastrpc.h > @@ -16,6 +16,7 @@ > #define FASTRPC_IOCTL_INIT_CREATE_STATIC _IOWR('R', 9, struct fastrpc_init_create_static) > #define FASTRPC_IOCTL_MEM_MAP _IOWR('R', 10, struct fastrpc_mem_map) > #define FASTRPC_IOCTL_MEM_UNMAP _IOWR('R', 11, struct fastrpc_mem_unmap) > +#define FASTRPC_IOCTL_SET_OPTION _IOWR('R', 12, struct fastrpc_ioctl_set_option) > #define FASTRPC_IOCTL_GET_DSP_INFO _IOWR('R', 13, struct fastrpc_ioctl_capability) > > /** > @@ -67,6 +68,9 @@ enum fastrpc_proc_attr { > /* Fastrpc attribute for memory protection of buffers */ > #define FASTRPC_ATTR_SECUREMAP (1) > > +/* Set option request ID to enable poll mode */ Some documentation please on this feature and which PD's can use this. > +#define FASTRPC_POLL_MODE (1) Can we also document the values for this request? > + > struct fastrpc_invoke_args { > __u64 ptr; > __u64 length; > @@ -133,6 +137,12 @@ struct fastrpc_mem_unmap { > __s32 reserved[5]; > }; > > +struct fastrpc_ioctl_set_option { > + __u32 req; /* request id */ Can we expand this to proper name, request_id or something? > + __u32 value; /* value */ > + __s32 reserved[6]; > +}; > + > struct fastrpc_ioctl_capability { > __u32 unused; /* deprecated, ignored by the kernel */ > __u32 attribute_id;