[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240815135951.GM3468552@ziepe.ca>
Date: Thu, 15 Aug 2024 10:59:51 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Robin Murphy <robin.murphy@....com>
Cc: Mostafa Saleh <smostafa@...gle.com>, linux-kernel@...r.kernel.org,
iommu@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
will@...nel.org, joro@...tes.org, jean-philippe@...aro.org,
nicolinc@...dia.com, mshavit@...gle.com
Subject: Re: [PATCH v2] iommu/arm-smmu-v3: Match Stall behaviour for S2
On Thu, Aug 15, 2024 at 02:41:52PM +0100, Robin Murphy wrote:
> Unfortunately we can't do that, because there *are* RCiEP devices whose data
> interfaces are native AMBA, and thus for whom stalling is not actually a
> protocol violation as it would be on a real PCIe transport layer;
> correspondingly, it's *because* they are not true PCIe devices that they
> can't support ATS, and thus need stall support in order to do SVA, so things
> should still work out OK in practice.
I wondered if that would be the case.
Looks like if we want to do anything then arm_smmu_ats_supported()
would be the right place.
> > if (dev_is_pci(dev)) {
> >
> > Though I have no idea how the GPU driver that wants to use this
> > works - it doesn't seem to be intree :\
>
> It's not a GPU: drivers/crypto/hisilicon/zip/
Ohhhh.. so it goes through uacce, I see.
Jason
Powered by blists - more mailing lists