From: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Thierry Reding <thierry.reding@kernel.org>,
Mikko Perttunen <mperttunen@nvidia.com>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Srinivas Kandagatla <srini@kernel.org>,
Bharath Kumar <quic_bkumar@quicinc.com>,
Chenna Kesava Raju <quic_chennak@quicinc.com>,
Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
iommu@lists.linux.dev, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 3/3] misc: fastrpc: Use context device bus for compute banks
Date: Wed, 22 Apr 2026 12:31:18 +0530 [thread overview]
Message-ID: <077a99c2-c954-c5e6-3699-cd0360e8b9f6@oss.qualcomm.com> (raw)
In-Reply-To: <r25ibbsw3flfashrp4x2cqy6thckgez5k3gtfqp46dcpbjniev@s4ngoa46ekvj>
On 4/19/2026 5:46 AM, Dmitry Baryshkov wrote:
> On Wed, Apr 15, 2026 at 09:35:47PM +0530, Vishnu Reddy wrote:
>>
>> On 4/14/2026 10:01 PM, Ekansh Gupta wrote:
>>> Replace the platform driver approach for compute bank (CB) devices
>>> with the generic context_device_bus_type. Compute bank devices are
>>> synthetic IOMMU context banks, not real platform devices, so using
>>> the context device bus provides a more accurate representation in
>>> the device model.
>>>
>>> Currently, fastrpc used of_platform_populate() to create platform
>>> devices for each "qcom,fastrpc-compute-cb" DT node, with a platform
>>> driver (fastrpc_cb_driver) to handle probe/remove. This approach
>>> had a race condition: device nodes were created before channel
>>> resources (like spin_lock) were initialized, and probe was async,
>>> so applications could open the device before sessions were available.
>>>
>>> This patch addresses the race by manually creating and configuring
>>> CB devices synchronously during fastrpc_rpmsg_probe(), after all
>>> channel resources are initialized. The approach follows the pattern
>>> used in host1x_memory_context_list_init().
>>>
>>> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
>>> ---
>>> drivers/misc/Kconfig | 1 +
>>> drivers/misc/fastrpc.c | 180 ++++++++++++++++++++++++++++++++++---------------
>>> 2 files changed, 125 insertions(+), 56 deletions(-)
>>>
>>> }
>>> dma_bits = cctx->soc_data->dma_addr_bits_default;
>>> + if (cctx->domain_id == CDSP_DOMAIN_ID)
>>> + dma_bits = cctx->soc_data->dma_addr_bits_cdsp;
>>> +
>>> sess = &cctx->session[cctx->sesscount++];
>>> sess->used = false;
>>> sess->valid = true;
>>> - sess->dev = dev;
>>> - dev_set_drvdata(dev, sess);
>>> + sess->sid = sid;
>>> + spin_unlock_irqrestore(&cctx->lock, flags);
>>> - if (cctx->domain_id == CDSP_DOMAIN_ID)
>>> - dma_bits = cctx->soc_data->dma_addr_bits_cdsp;
>>> + cb_dev = kzalloc_obj(*cb_dev);
>>> + if (!cb_dev)
>>> + return -ENOMEM;
>>> - if (of_property_read_u32(dev->of_node, "reg", &sess->sid))
>>> - dev_info(dev, "FastRPC Session ID not specified in DT\n");
>>> + cb_dev->sess = sess;
>>> - if (sessions > 0) {
>>> - struct fastrpc_session_ctx *dup_sess;
>>> + device_initialize(&cb_dev->dev);
>>> + cb_dev->dev.parent = parent;
>>> + cb_dev->dev.bus = &context_device_bus_type;
>>> + cb_dev->dev.release = fastrpc_cb_dev_release;
>>> + cb_dev->dev.of_node = of_node_get(cb_node);
>>> + cb_dev->dev.dma_mask = &cb_dev->dev.coherent_dma_mask;
>>> + cb_dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> + dev_set_name(&cb_dev->dev, "%s:compute-cb@%u", dev_name(parent), sid);
>>> + rc = device_add(&cb_dev->dev);
>> device_initialize() and device_add() can be replaced with single
>> device_register() call. You can refer the below patch,
> Keep in mind that for several arches device_initialize() sets the
> coherent_dma_mask. So one should set coherent_dma_mask (as it's done
> here) after calling device_initialize().
I can see that device_initialize() sets dma_coherent flag for several arches,
not the coherent_dma_mask. The final dma_coherent flag value is updated later
in of_dma_configure_id() based on the dt dma-coherent property.
Setting the coherent_dma_mask here and calling device_register() which will
call the device_initialize() won't change the coherent_dma_mask value.
Please correct me if I'm wrong?
>> https://lore.kernel.org/all/20260313-kaanapali-iris-v3-4-9c0d1a67af4b@oss.qualcomm.com/
>>
next prev parent reply other threads:[~2026-04-22 7:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 16:31 [PATCH 0/3] Introduce generic context device bus for IOMMU context isolation Ekansh Gupta via B4 Relay
2026-04-14 16:31 ` [PATCH 1/3] drivers: base: Add generic context device bus Ekansh Gupta via B4 Relay
2026-04-14 16:49 ` Greg Kroah-Hartman
2026-04-15 17:34 ` Vishnu Reddy
2026-04-20 22:56 ` Jason Gunthorpe
2026-04-15 11:25 ` Srinivas Kandagatla
2026-04-15 17:16 ` Vishnu Reddy
2026-04-14 16:31 ` [PATCH 2/3] gpu: host1x: Migrate to " Ekansh Gupta via B4 Relay
2026-04-14 16:31 ` [PATCH 3/3] misc: fastrpc: Use context device bus for compute banks Ekansh Gupta via B4 Relay
2026-04-14 17:59 ` Dmitry Baryshkov
2026-04-15 11:36 ` Srinivas Kandagatla
2026-04-15 16:05 ` Vishnu Reddy
2026-04-19 0:16 ` Dmitry Baryshkov
2026-04-22 7:01 ` Vishnu Reddy [this message]
2026-04-22 18:52 ` Dmitry Baryshkov
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=077a99c2-c954-c5e6-3699-cd0360e8b9f6@oss.qualcomm.com \
--to=busanna.reddy@oss.qualcomm.com \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=dakr@kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=ekansh.gupta@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mperttunen@nvidia.com \
--cc=quic_bkumar@quicinc.com \
--cc=quic_chennak@quicinc.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=simona@ffwll.ch \
--cc=srini@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=vikash.garodia@oss.qualcomm.com \
--cc=will@kernel.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