From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
To: Abhinav Parihar <abhinav.parihar@oss.qualcomm.com>,
srinivas.kandagatla@linaro.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
Subject: Re: [PATCH] misc: fastrpc: Add cache maintenance for non-coherent platforms
Date: Wed, 14 Oct 2026 10:12:53 +0530 [thread overview]
Message-ID: <6e4d0fc2-3fe6-4dff-bdc1-b6051f3becef@oss.qualcomm.com> (raw)
In-Reply-To: <20260916185850.3686010-1-abhinav.parihar@oss.qualcomm.com>
On 17-09-2026 00:28, Abhinav Parihar wrote:
> Some platforms using fastrpc do not support DMA coherency on
> HLOS. On such systems, explicit cache maintenance is
> required to ensure data consistency for RPC argument buffers.
>
> Add cache maintenance for argument buffers when operating on
> non-coherent platforms:
> - Flush input buffers before invoking RPC to ensure CPU writes are
> visible to the DSP
> - Invalidate output buffers after RPC completion to ensure DSP
> writes are visible to the CPU
>
> Introduce helper functions fastrpc_flush_args() and
> fastrpc_inv_args() to perform the required dma-buf cache
> operations. These are invoked only when the device is not marked
> as DMA coherent.
>
> The coherency capability is determined using the "dma-coherent"
> device tree property and stored per session context.
>
> This ensures correct data synchronization on platforms lacking
> DMA coherency, while avoiding unnecessary overhead on coherent
> systems.
>
> Signed-off-by: Abhinav Parihar <abhinav.parihar@oss.qualcomm.com>
> ---
>
> Patch [v1]: https://lore.kernel.org/all/20260604194811.2437567-1-abhinav.parihar@oss.qualcomm.com/
>
> Changes in v2:
> - Fix buffer overlap handling to ensure cache maintenance is performed
> when input and output buffers overlap and the overlap calculation
> suppresses the buffer's mstart/mend range.
> - Add a do_cmo flag to track buffers that require cache maintenance
> even when their overlap range is clipped.
> - Invalidate output buffers before sending the RPC request, preventing
> stale CPU cache lines from being written back while the DSP updates
> the buffers.
> - Use DMA_FROM_DEVICE consistently for both begin_cpu_access() and
> end_cpu_access() when invalidating output buffers.
>
> drivers/misc/fastrpc.c | 77 +++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 76 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index d4fac2caca86..83d04b9d2ea0 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -217,6 +217,7 @@ struct fastrpc_buf_overlap {
> u64 mstart;
> u64 mend;
> u64 offset;
> + bool do_cmo;
> };
>
> struct fastrpc_buf {
> @@ -292,6 +293,7 @@ struct fastrpc_session_ctx {
> int sid;
> bool used;
> bool valid;
> + bool coherent;
> };
>
> struct fastrpc_soc_data {
> @@ -655,7 +657,9 @@ static int olaps_cmp(const void *a, const void *b)
> static void fastrpc_get_buff_overlaps(struct fastrpc_invoke_ctx *ctx)
> {
> u64 max_end = 0;
> + int max_raix = -1;
> int i;
> + int inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
>
> for (i = 0; i < ctx->nbufs; ++i) {
> ctx->olaps[i].start = ctx->args[i].ptr;
> @@ -675,6 +679,9 @@ static void fastrpc_get_buff_overlaps(struct fastrpc_invoke_ctx *ctx)
> if (ctx->olaps[i].end > max_end) {
> max_end = ctx->olaps[i].end;
should you update max_raix here also?> } else {
> + if ((max_raix < inbufs && ctx->olaps[i].raix + 1 > inbufs) ||
> + (ctx->olaps[i].raix < inbufs && max_raix + 1 > inbufs))
if ((max_raix < inbufs) != (ctx->olaps[i].raix < inbufs))
> + ctx->olaps[i].do_cmo = true;
> ctx->olaps[i].mend = 0;
> ctx->olaps[i].mstart = 0;
> }
> @@ -684,6 +691,7 @@ static void fastrpc_get_buff_overlaps(struct fastrpc_invoke_ctx *ctx)
> ctx->olaps[i].mstart = ctx->olaps[i].start;
> ctx->olaps[i].offset = 0;
> max_end = ctx->olaps[i].end;
> + max_raix = ctx->olaps[i].raix;
> }
> }
> }
> @@ -703,6 +711,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
>
> INIT_LIST_HEAD(&ctx->node);
> ctx->fl = user;
> + ctx->sc = sc;
> ctx->nscalars = REMOTE_SCALARS_LENGTH(sc);
> ctx->nbufs = REMOTE_SCALARS_INBUFS(sc) +
> REMOTE_SCALARS_OUTBUFS(sc);
> @@ -728,7 +737,6 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
> /* Take a reference to user, released in fastrpc_context_free() */
> fastrpc_user_get(user);
>
> - ctx->sc = sc;
> ctx->retval = -1;
> ctx->pid = current->pid;
> ctx->client_id = user->client_id;
> @@ -1067,6 +1075,64 @@ static int fastrpc_create_maps(struct fastrpc_invoke_ctx *ctx)
> return 0;
> }
>
> +static void fastrpc_flush_args(struct fastrpc_invoke_ctx *ctx)
> +{
> + union fastrpc_remote_arg *rpra = ctx->rpra;
> + int i, inbufs, outbufs;
> +
> + inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
> + outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc);
> +
> + for (i = 0; i < inbufs + outbufs; ++i) {
ctx->nbufs instead of inbufs + outbufs
> + int raix = ctx->olaps[i].raix;
> + struct fastrpc_map *map = ctx->maps[raix];
> +
> + if (raix + 1 > inbufs)
> + continue;
> + if (!map || !map->buf)
> + continue;
> +
> + if (rpra[raix].buf.len && (ctx->olaps[i].mstart || ctx->olaps[i].do_cmo)) {
> + dma_buf_begin_cpu_access(map->buf, DMA_TO_DEVICE);
> + dma_buf_end_cpu_access(map->buf, DMA_TO_DEVICE);
> + }
> + }
> +}
> +
> +static void fastrpc_inv_args(struct fastrpc_invoke_ctx *ctx)
> +{
> + union fastrpc_remote_arg *rpra = ctx->rpra;
> + int i, inbufs, outbufs;
> +
> + inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
> + outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc);
> +
> + for (i = 0; i < inbufs + outbufs; ++i) {
ctx->nbufs> + int raix = ctx->olaps[i].raix;
> + struct fastrpc_map *map = ctx->maps[raix];
> +
> + if (raix + 1 <= inbufs)
> + continue;
> + if (!rpra[raix].buf.len)
> + continue;
> + if (!map || !map->buf)
> + continue;
> +
> + /*
> + * Skip invalidation if the argument overlaps with the
> + * RPC control header page.
> + */
> + if (((uintptr_t)rpra & PAGE_MASK) ==
> + ((uintptr_t)rpra[raix].buf.pv & PAGE_MASK))
is this possible? for fd buffers, buf.pv is going to be a userspace VA
and rpta addr is going to be a kernel VA, those cannot be equal.> +
continue;
> +
> + if (ctx->olaps[i].mstart || ctx->olaps[i].do_cmo) {
> + dma_buf_begin_cpu_access(map->buf, DMA_FROM_DEVICE);
> + dma_buf_end_cpu_access(map->buf, DMA_FROM_DEVICE);
> + }
> + }
> +}
> +
> static struct fastrpc_invoke_buf *fastrpc_invoke_buf_start(union fastrpc_remote_arg *pra, int len)
> {
> return (struct fastrpc_invoke_buf *)(&pra[len]);
> @@ -1191,6 +1257,9 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
> }
> }
>
> + if (!ctx->fl->sctx->coherent)
> + fastrpc_flush_args(ctx);
> +
> for (i = ctx->nbufs; i < ctx->nscalars; ++i) {
> list[i].num = ctx->args[i].length ? 1 : 0;
> list[i].pgidx = i;
> @@ -1376,6 +1445,8 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel,
> if (err)
> goto bail;
>
> + if (!fl->sctx->coherent)
> + fastrpc_inv_args(ctx);
> /* make sure that all CPU memory writes are seen by DSP */
> dma_wmb();
> /* Send invoke buffer to remote dsp */
> @@ -1396,6 +1467,9 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel,
>
> /* make sure that all memory writes by DSP are seen by CPU */
> dma_rmb();
> + if (!fl->sctx->coherent)
> + fastrpc_inv_args(ctx);
> +
> /* populate all the output buffers with results */
> err = fastrpc_put_args(ctx, kernel);
> if (err)
> @@ -2393,6 +2467,7 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
> sess->used = false;
> sess->valid = true;
> sess->dev = dev;
> + sess->coherent = of_property_read_bool(dev->of_node, "dma-coherent");
see if you can use of_dma_is_coherent() instead.> dev_set_drvdata(dev,
sess);
> sess->sid = sid;
>
prev parent reply other threads:[~2026-10-14 4:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 18:58 Abhinav Parihar
2026-10-14 4:42 ` Ekansh Gupta [this message]
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=6e4d0fc2-3fe6-4dff-bdc1-b6051f3becef@oss.qualcomm.com \
--to=ekansh.gupta@oss.qualcomm.com \
--cc=abhinav.parihar@oss.qualcomm.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_bkumar@quicinc.com \
--cc=quic_chennak@quicinc.com \
--cc=srinivas.kandagatla@linaro.org \
/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®