Re: [PATCH v4 3/4] misc: fastrpc: Expand context ID mask for DSP polling mode support

[Konrad Dybcio]

On 11/28/25 6:05 AM, Ekansh Gupta wrote:
> Current FastRPC message context uses a 12-bit mask where the upper
> 8 bits represent the context ID from idr_alloc_cyclic and the lower
> 4 bits represent the PD type.

<newline>

> This layout works for normal FastRPC
> calls but fails for polling mode because DSP expects a 16-bit context
> with an additional async mode bit. 

<newline>

> To enable polling mode support
> from DSP(DSP writes to poll memory), DSP expects a 16-bit context
> where the upper 8 bits are context ID, the lower 4 bits are PD type
> and the 5th bit from the end denotes async mode(not yet upstreamed).

<newline>

so we get

1
5	       0
CCCCCCCCxxxAPPPP

where C is context ID, A is is_async, and P is PD type

are the x bits reserved, or do they serve some purpose?

> If this bit is set, DSP disables polling. With the current design,
> odd context IDs set this bit, causing DSP to skip poll memory updates.

<newline>

> Update the context mask to ensure a hole which won't get populated,

"to avoid erroneously setting that bit"

> ensuring polling mode works as expected. This is not a bug and the
> change is added to support polling mode.

I think the main question that remains unanswered here is that you alter
the non-polling mode mask to become compliant with what polling-mode
expects.

Is that intended? Will this still work fine without patch 4 and the
new FASTRPC_IOCTL_SET_OPTION?

Konrad