From: Beleswar Prasad Padhi <b-padhi@ti.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>,
Lu Baolu <baolu.lu@linux.intel.com>, <andersson@kernel.org>,
<afd@ti.com>, <nm@ti.com>, <hnagalla@ti.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Kevin Tian <kevin.tian@intel.com>,
<linux-remoteproc@vger.kernel.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [PATCH 1/1] remoteproc: Use iommu_paging_domain_alloc()
Date: Sun, 22 Sep 2024 16:57:07 +0530 [thread overview]
Message-ID: <0dbde87b-593f-4b14-8929-b78e189549ad@ti.com> (raw)
In-Reply-To: <99c874f1-3d85-43b2-a3a0-40e1e0c25696@ti.com>
On 29-08-2024 11:47, Beleswar Prasad Padhi wrote:
> Hi All,
>
> On 22/08/24 21:47, Mathieu Poirier wrote:
>> Hi Baolu,
>>
>> Sorry for the late reply, this slipped through the cracks.
>>
>> On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
>> > An iommu domain is allocated in rproc_enable_iommu() and is
>> attached to
>> > rproc->dev.parent in the same function.
>> > > Use iommu_paging_domain_alloc() to make it explicit.
>> > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
>> > Link:
>> https://lore.kernel.org/r/20240610085555.88197-13-baolu.lu@linux.intel.com
>> > ---
>> > drivers/remoteproc/remoteproc_core.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> > > diff --git a/drivers/remoteproc/remoteproc_core.c
>> b/drivers/remoteproc/remoteproc_core.c
>> > index f276956f2c5c..eb66f78ec8b7 100644
>> > --- a/drivers/remoteproc/remoteproc_core.c
>> > +++ b/drivers/remoteproc/remoteproc_core.c
>> > @@ -109,10 +109,10 @@ static int rproc_enable_iommu(struct rproc
>> *rproc)
>> > return 0;
>> > }
>> > > - domain = iommu_domain_alloc(dev->bus);
>> > - if (!domain) {
>> > + domain = iommu_paging_domain_alloc(dev);
>>
>> I'm a little hesitant here. Function iommu_domain_alloc() passes
>> NULL two the
>> second argument of __iommu_domain_alloc() while
>> iommu_paging_domain_alloc()
>> provides a 'dev'. I don't have any HW to test on and I am not
>> familiar enough
>> with the IOMMU subsystem to confidently more forward.
>>
>> I am asking the Qualcomm (Bjorn and friends) and TI crew (Beleswar,
>> Andrew,
>> Nishanth and Hari) to test this patch on their IOMMU devices and get
>> back to me
>> with a "Tested-by".
>
>
> Just a heads-up. Currently, I am seeing boot failures while booting
> remotecores in TI's IOMMU devices with mainline kernel. Working on the
> the fix, once it is done, will apply the above patch and test it ASAP.
Since commit 17de3f5fdd35, the IOMMU framework has changed how it
handles callback ops, moving away from using bus->iommu_ops. The
omap-iommu driver has not yet been updated to align with these framework
changes. Therefore, omap-iommu, and hence, omap-remoteproc have been
broken since 17de3f5fdd35.
This patch is a step in the right direction for adapting the
remoteproc_core framework to the newer IOMMU framework by looking for
iommu_ops attached to the dev structure instead of dev->bus. Due to time
constraints, I was unable to update the omap-iommu driver to accommodate
these changes, so, I could not test this patch. However, logically, this
patch LGTM. So,
Acked-by: Beleswar Padhi <b-padhi@ti.com>
Thanks,
Beleswar
>
> Thanks,
> Beleswar
>
>>
>> Thanks,
>> Mathieu
>>
>> > + if (IS_ERR(domain)) {
>> > dev_err(dev, "can't alloc iommu domain\n");
>> > - return -ENOMEM;
>> > + return PTR_ERR(domain);
>> > }
>> > > iommu_set_fault_handler(domain, rproc_iommu_fault, rproc);
>> > -- > 2.34.1
>> >
next prev parent reply other threads:[~2024-09-22 11:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 7:28 Lu Baolu
2024-08-22 16:17 ` Mathieu Poirier
2024-08-22 16:24 ` Jason Gunthorpe
2024-09-15 14:09 ` Jason Gunthorpe
2024-09-16 15:22 ` Mathieu Poirier
2024-08-29 6:17 ` Beleswar Prasad Padhi
2024-09-22 11:27 ` Beleswar Prasad Padhi [this message]
2024-09-23 18:12 ` Jason Gunthorpe
2024-09-30 16:40 ` Mathieu Poirier
2024-10-01 13:35 ` Jason Gunthorpe
2024-10-03 13:58 ` Mathieu Poirier
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=0dbde87b-593f-4b14-8929-b78e189549ad@ti.com \
--to=b-padhi@ti.com \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=hnagalla@ti.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=nm@ti.com \
--cc=robin.murphy@arm.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
all inboxes | Powered by JetHome®