Current FastRPC context uses a 12-bit mask:
  [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)

This works for normal calls but fails for DSP polling mode.
Polling mode expects a 16-bit layout:
  [15:8] = context ID (8 bits)
  [7:5]  = reserved
  [4]    = async mode bit
  [3:0]  = PD type (4 bits)

If async bit (bit 4) is set, DSP disables polling. With current
mask, odd IDs can set this bit, causing DSP to skip poll updates.

Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
byte and lower byte is left for DSP flags and PD type.

Reserved bits remain unused. This change is compatible with
polling mode and does not break non-polling behavior.

Bit layout:
  [15:8] = CCCCCCCC (context ID)
  [7:5]  = xxx (reserved)
  [4]    = A (async mode)
  [3:0]  = PPPP (PD type)

Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index f7fb44a8e9c0..222ff15e04bd 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -38,7 +38,7 @@
 #define FASTRPC_CTX_MAX (256)
 #define FASTRPC_INIT_HANDLE	1
 #define FASTRPC_DSP_UTILITIES_HANDLE	2
-#define FASTRPC_CTXID_MASK GENMASK(11, 4)
+#define FASTRPC_CTXID_MASK GENMASK(15, 8)
 #define INIT_FILELEN_MAX (2 * 1024 * 1024)
 #define INIT_FILE_NAMELEN_MAX (128)
 #define FASTRPC_DEVICE_NAME	"fastrpc"
-- 
2.34.1

On Tue, Dec 30, 2025 at 11:58:30AM +0530, Ekansh Gupta wrote:
> Current FastRPC context uses a 12-bit mask:
>   [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)

Is it Linux-only representation or is it also used by the DSP? Will it
work with MSM8916?

> 
> This works for normal calls but fails for DSP polling mode.
> Polling mode expects a 16-bit layout:
>   [15:8] = context ID (8 bits)
>   [7:5]  = reserved
>   [4]    = async mode bit
>   [3:0]  = PD type (4 bits)
> 
> If async bit (bit 4) is set, DSP disables polling. With current
> mask, odd IDs can set this bit, causing DSP to skip poll updates.
> 
> Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
> byte and lower byte is left for DSP flags and PD type.
> 
> Reserved bits remain unused. This change is compatible with
> polling mode and does not break non-polling behavior.
> 
> Bit layout:
>   [15:8] = CCCCCCCC (context ID)
>   [7:5]  = xxx (reserved)
>   [4]    = A (async mode)
>   [3:0]  = PPPP (PD type)
> 
> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> ---
>  drivers/misc/fastrpc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

-- 
With best wishes
Dmitry

On 1/6/2026 8:23 AM, Dmitry Baryshkov wrote:
> On Tue, Dec 30, 2025 at 11:58:30AM +0530, Ekansh Gupta wrote:
>> Current FastRPC context uses a 12-bit mask:
>>   [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)
> Is it Linux-only representation or is it also used by the DSP? Will it
> work with MSM8916?
Apologies for the delay in response, had to go back to check on older DSP software.

DSP will also use this but it handled properly across platforms. DSP get PD details from PD bits
and mask it to use further for async call checks. Other than async call check, the context ID is
majorly used for book-keeping on DSP side(no functional utility).

So, it should also work on MSM8916,
>
>> This works for normal calls but fails for DSP polling mode.
>> Polling mode expects a 16-bit layout:
>>   [15:8] = context ID (8 bits)
>>   [7:5]  = reserved
>>   [4]    = async mode bit
>>   [3:0]  = PD type (4 bits)
>>
>> If async bit (bit 4) is set, DSP disables polling. With current
>> mask, odd IDs can set this bit, causing DSP to skip poll updates.
>>
>> Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
>> byte and lower byte is left for DSP flags and PD type.
>>
>> Reserved bits remain unused. This change is compatible with
>> polling mode and does not break non-polling behavior.
>>
>> Bit layout:
>>   [15:8] = CCCCCCCC (context ID)
>>   [7:5]  = xxx (reserved)
>>   [4]    = A (async mode)
>>   [3:0]  = PPPP (PD type)
>>
>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>> ---
>>  drivers/misc/fastrpc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>

On Thu, Jan 29, 2026 at 03:56:55PM +0530, Ekansh Gupta wrote:
> 
> 
> On 1/6/2026 8:23 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 30, 2025 at 11:58:30AM +0530, Ekansh Gupta wrote:
> >> Current FastRPC context uses a 12-bit mask:
> >>   [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)
> > Is it Linux-only representation or is it also used by the DSP? Will it
> > work with MSM8916?
> Apologies for the delay in response, had to go back to check on older DSP software.
> 
> DSP will also use this but it handled properly across platforms. DSP get PD details from PD bits
> and mask it to use further for async call checks. Other than async call check, the context ID is
> majorly used for book-keeping on DSP side(no functional utility).
> 
> So, it should also work on MSM8916,

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



> >
> >> This works for normal calls but fails for DSP polling mode.
> >> Polling mode expects a 16-bit layout:
> >>   [15:8] = context ID (8 bits)
> >>   [7:5]  = reserved
> >>   [4]    = async mode bit
> >>   [3:0]  = PD type (4 bits)
> >>
> >> If async bit (bit 4) is set, DSP disables polling. With current
> >> mask, odd IDs can set this bit, causing DSP to skip poll updates.
> >>
> >> Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
> >> byte and lower byte is left for DSP flags and PD type.
> >>
> >> Reserved bits remain unused. This change is compatible with
> >> polling mode and does not break non-polling behavior.
> >>
> >> Bit layout:
> >>   [15:8] = CCCCCCCC (context ID)
> >>   [7:5]  = xxx (reserved)
> >>   [4]    = A (async mode)
> >>   [3:0]  = PPPP (PD type)
> >>
> >> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >> ---
> >>  drivers/misc/fastrpc.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> 

-- 
With best wishes
Dmitry