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
