On Sun, Feb 15, 2026 at 11:51:35PM +0530, 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. 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 <[email protected]>
> ---
> drivers/misc/fastrpc.c | 142 ++++++++++++++++++++++++++++++++++--
> include/uapi/misc/fastrpc.h | 10 +++
> 2 files changed, 145 insertions(+), 7 deletions(-)
>
> @@ -1812,6 +1912,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;
I think I've raised this question beforehand. This implementation will
return success to the userspace even on the platforms where polling is
not supported. This is not correct.
> +
> + return 0;
> +}
> +
> static int fastrpc_get_dsp_info(struct fastrpc_user *fl, char __user *argp)
> {
> struct fastrpc_ioctl_capability cap = {0};
--
With best wishes
Dmitry
