public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
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/
>>

  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