[PATCH v3 0/3] misc: fastrpc: fix ADSP duplicate session creation
Vinayak Katoch <[email protected]>
| Newsgroups | org.freedesktop.lists.dri-devel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
For ADSP, only a limited number of FastRPC context banks (CBs) are available. Each CB supports a single session, which means only a few processes can run on ADSP simultaneously. If all sessions are consumed by fastrpc daemons, no session remains available when a user application starts, causing the application to fail. To work around this, some DT set: qcom,nsessions = <5>; which duplicated sessions inline during context bank initialisation. Upstream feedback indicated that this policy does not belong in DT and should be handled at the driver level instead. This series iterates over CB child nodes directly and synchronously, replacing of_platform_populate(), and moves the ADSP session duplication to the driver. The qcom,nsessions binding is deprecated in the same series. Signed-off-by: Vinayak Katoch <[email protected]> --- Changes in v3: - Add patch to fix async probe race with of_platform_populate(). - Rename fastrpc_cb_probe() to fastrpc_cb_init(). - Reorder series: sync fix, nsessions, binding. - Collect Reviewed-by tags. - Link to v2: https://lore.kernel.org/r/[email protected] Changes in v2: - Added patch to deprecate the qcom,nsessions dt-binding. - Kept the logic unchanged; only split into two patches. - Link to v1: https://lore.kernel.org/r/[email protected] --- Vinayak Katoch (3): misc: fastrpc: iterate CB nodes manually instead of of_platform_populate misc: fastrpc: move ADSP duplicate session creation to the driver dt-bindings: misc: qcom,fastrpc: deprecate qcom,nsessions .../devicetree/bindings/misc/qcom,fastrpc.yaml | 2 + drivers/misc/fastrpc.c | 112 +++++++++------------ 2 files changed, 48 insertions(+), 66 deletions(-) --- base-commit: 97e797263a5e963da3d1e66e743fd518567dfe37 change-id: 20260609-dup-sessions-ea2acaac1994 Best regards, -- Vinayak Katoch <[email protected]>