Hej,
this is the next attempt adding support for the DART found in Apple's
M1 Pro/Max/Ultra. This adds a separate io-pgtable implementation for
DART. As already mentioned in v2 the pte format is not fully compatible
with io-pgtable-arm. Especially the 2nd least significant bit is used
and is not a
From: Sven Peter
The M1 Pro/Max/Ultra SoCs come with a new variant of DART which
supports a larger physical address space with a different PTE format.
Pass through the correct paddr address space size and the PTE format
to the io-pgtable code which will take care of the rest.
Signed-off-by: Sven
From: Sven Peter
DART allows to only expose a subpage to the device. While this is an
optional feature on the M1 DARTs the new ones present on the Pro/Max
models require this field in every PTE.
Signed-off-by: Sven Peter
Signed-off-by: Janne Grunau
---
Changes in v3:
- apply change to io-pgt
From: Sven Peter
The M1 Max/Pro SoCs come with a new DART variant that is incompatible with
the previous one. Add a new compatible for those.
Signed-off-by: Sven Peter
Acked-by: Rob Herring
Signed-off-by: Janne Grunau
---
(no changes since v2)
Changes in v2:
- added Rob's Acked-by:
Docum
From: Sven Peter
The DARTs present in the M1 Pro/Max/Ultra SoC use a diffent PTE format.
They support a 42bit physical address space by shifting the paddr and
extending its mask inside the PTE.
They also come with mandatory sub-page protection now which we just
configure to always allow access to
The pte format used by the DARTs found in the Apple M1 (t8103) is not
fully compatible with io-pgtable-arm. The 24 MSB are used for subpage
protection (mapping only parts of page) and conflict with the address
mask. In addition bit 1 is not available for tagging entries but disables
subpage protect
Hi,
* Saravana Kannan [700101 02:00]:
> Now that fw_devlink=on by default and fw_devlink supports
> "power-domains" property, the execution will never get to the point
> where driver_deferred_probe_check_state() is called before the supplier
> has probed successfully or before deferred probe time
On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao wrote:
The refcount only ensures that the uacce_device object is not freed as
long as there are open fds. But uacce_remo
On Tue, Jun 21, 2022 at 03:37:31PM +0800, Zhangfei Gao wrote:
>
>
> On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
> > On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao wrote:
> > > > > The refcount only ensures tha
On 6/17/22 14:57, Arnd Bergmann wrote:
From: Arnd Bergmann
The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008, but
it still has a stale reference in an error handling code path that could
never work.
Fix it up to build without VIRT_TO_BUS and remove the Kconfig dependency.
The a
On 6/17/22 14:57, Arnd Bergmann wrote:
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e
On 2022/6/21 13:48, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 12:28 PM
On 2022/6/21 11:46, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 11:39 AM
On 2022/6/21 10:54, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, June 20, 2022 4:17 PM
@@ -2564,7 +2564
Hi folks,
The former part of this series refactors the IOMMU SVA code by assigning
an SVA type of iommu_domain to a shared virtual address and replacing
sva_bind/unbind iommu ops with set/block_dev_pasid domain ops.
The latter part changes the existing I/O page fault handling framework
from only
Use this field to keep the number of supported PASIDs that an IOMMU
hardware is able to support. This is a generic attribute of an IOMMU
and lifting it into the per-IOMMU device structure makes it possible
to allocate a PASID for device without calls into the IOMMU drivers.
Any iommu driver that su
Use this field to save the number of PASIDs that a device is able to
consume. It is a generic attribute of a device and lifting it into the
per-device dev_iommu struct could help to avoid the boilerplate code
in various IOMMU drivers.
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 2 ++
dr
The current kernel DMA with PASID support is based on the SVA with a flag
SVM_FLAG_SUPERVISOR_MODE. The IOMMU driver binds the kernel memory address
space to a PASID of the device. The device driver programs the device with
kernel virtual address (KVA) for DMA access. There have been security and
f
The sva iommu_domain represents a hardware pagetable that the IOMMU
hardware could use for SVA translation. This adds some infrastructure
to support SVA domain in the iommu common layer. It includes:
- Extend the iommu_domain to support a new IOMMU_DOMAIN_SVA domain
type. The IOMMU drivers that
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 5
drivers/iommu/intel/iommu.c | 2 ++
drivers/iommu/intel/svm.c | 49 +
3 files changed, 56 insertions(+)
d
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 69 +++
drivers/iommu/arm/arm
The existing iommu SVA interfaces are implemented by calling the SVA
specific iommu ops provided by the IOMMU drivers. There's no need for
any SVA specific ops in iommu_ops vector anymore as we can achieve
this through the generic attach/detach_dev_pasid domain ops.
This refactors the IOMMU SVA in
These ops'es have been replaced with the dev_attach/detach_pasid domain
ops'es. There's no need for them anymore. Remove them to avoid dead
code.
Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
Reviewed-by: Kevin Tian
---
include/linux/intel-iommu.h | 3 --
includ
This adds some mechanisms around the iommu_domain so that the I/O page
fault handling framework could route a page fault to the domain and
call the fault handler from it.
Add pointers to the page fault handler and its private data in struct
iommu_domain. The fault handler will be called with the p
Tweak the I/O page fault handling framework to route the page faults to
the domain and call the page fault handler retrieved from the domain.
This makes the I/O page fault handling framework possible to serve more
usage scenarios as long as they have an IOMMU domain and install a page
fault handler
Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
for SVA implementation in iommu core.
Signed-off-by: Lu Baolu
Reviewed-by: Jean-Philippe Brucker
---
drivers/iommu/{iommu-sva-lib.h => iommu-sva.h} | 6 +++---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
drivers/io
From: Mikko Perttunen
Add code to do stream ID switching at the beginning of a job. The
stream ID is switched to the stream ID specified by the context
passed in the job structure.
Before switching the stream ID, an OP_DONE wait is done on the
channel's engine to ensure that there is no residual
From: Mikko Perttunen
Add Host1x context stream IDs on systems that support Host1x context
isolation. Host1x and attached engines can use these stream IDs to
allow isolation between memory used by different processes.
The specified stream IDs must match those configured by the hypervisor,
if one
From: Mikko Perttunen
-
Merging notes
-
The changes to DT bindings should be applied on top of Thierry's patch
'dt-bindings: display: tegra: Convert to json-schema'.
The change to the arm-smmu driver should be omitted if Robin Murphy's
IOMMU bus cleanup series is merged.
From: Mikko Perttunen
Set itself as the IOMMU for the host1x context device bus, containing
"dummy" devices used for Host1x context isolation.
Signed-off-by: Mikko Perttunen
---
This patch should only be applied if Robin Murphy's IOMMU bus
refactoring series doesn't get merged in time.
---
dri
From: Mikko Perttunen
Implement the get_streamid_offset and can_use_memory_ctx callbacks
required for supporting context isolation. Since old firmware on VIC
cannot support context isolation without hacks that we don't want to
implement, check the firmware binary to see if context isolation
shoul
From: Mikko Perttunen
Add schema information for specifying context stream IDs. This uses
the standard iommu-map property.
Signed-off-by: Mikko Perttunen
Reviewed-by: Robin Murphy
Acked-by: Rob Herring
---
v3:
* New patch
v4:
* Remove memory-contexts subnode.
---
.../bindings/display/tegra/n
From: Mikko Perttunen
The DMACTX field determines which context, as specified in the
TRANSCFG register, is used. While during boot it doesn't matter
which is used, later on it matters and this value is reused by
the firmware.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/falcon.c |
From: Mikko Perttunen
For engines that support context isolation, allocate a context when
opening a channel, and set up stream ID offset and context fields
when submitting a job.
As of this commit, the stream ID offset and fallback stream ID
are not used when context isolation is disabled. Howev
From: Thierry Reding
Convert the Tegra host1x controller bindings from the free-form text
format to json-schema.
This also adds the missing display-hub DT bindings that were not
previously documented.
Reviewed-by: Rob Herring
Signed-off-by: Thierry Reding
---
.../display/tegra/nvidia,tegra11
From: Mikko Perttunen
Add code to register context devices from device tree, allocate them
out and manage their refcounts.
Signed-off-by: Mikko Perttunen
---
v2:
* Directly set DMA mask instead of inheriting from Host1x.
* Use iommu-map instead of custom DT property.
v4:
* Use u64 instead of dm
From: Mikko Perttunen
NVDEC's TRANSCFG register is at a different offset than VIC.
This becomes a problem now when context isolation is enabled and
the reset value of the register is no longer sufficient.
Signed-off-by: Mikko Perttunen
---
v6:
* New patch
---
drivers/gpu/drm/tegra/nvdec.c | 4
Hi all,
Here are a few more thematically-related patches from my develompent
stack that don't depend on the rest, so may as well get some exposure
sooner rather than later.
Thanks,
Robin.
Robin Murphy (3):
iommu: Use dev_iommu_ops() for probe_finalize
iommu: Make .release_device optional
The ->probe_finalize hook only runs after ->probe_device succeeds,
so we can move that over to the new dev_iommu_ops() as well.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c
Many drivers do nothing meaningful for .release_device, and it's neatly
abstracted to just two callsites in the core code, so let's make it
optional to implement.
Signed-off-by: Robin Murphy
---
drivers/iommu/fsl_pamu_domain.c | 5 -
drivers/iommu/iommu.c | 6 --
drivers/iommu/
Since .release_device is now called through per-device ops, any call
which gets as far as a driver definitely *is* for that driver, for a
device which has successfully passed .probe_device, so all the checks to
that effect are now redundant and can be removed. In the same vein we
can also skip free
On 2022-06-10 01:03, Jason Gunthorpe via iommu wrote:
On Wed, Jun 08, 2022 at 03:25:49PM +0100, Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
must be on a bus supported by that IOMM
On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote:
>
> Hi,
>
> * Saravana Kannan [700101 02:00]:
> > Now that fw_devlink=on by default and fw_devlink supports
> > "power-domains" property, the execution will never get to the point
> > where driver_deferred_probe_check_state() is called before
Hi Marek,
On Fri, 21 Jan 2022 at 14:31, Marek Szyprowski wrote:
[snip]
>
> Well, for starting point the existing exynos-iommu driver is really
> enough. I've played a bit with newer Exyos SoCs some time ago. If I
> remember right, if you limit the iommu functionality to the essential
> things l
On Mon, Jun 20, 2022 at 01:03:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 17, 2022 at 04:07:20PM -0700, Nicolin Chen wrote:
>
> > > > > > + vfio_iommu_aper_expand(iommu, &iova_copy);
> > > > >
> > > > > but now it's done for every group detach. The aperture is decided
> > > > > by domain
On Mon, Jun 20, 2022 at 11:11:01AM +0100, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2022-06-17 03:53, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Friday, June 17, 2022 6:41 AM
> > >
> > > > ...
> > > > > - if (resv_msi) {
> > > > > +
On 6/17/22 06:57, Arnd Bergmann wrote:
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e
On Wed, 15 Jun 2022 17:03:01 -0700
Nicolin Chen wrote:
> From: Jason Gunthorpe
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
> So, ther
On Tue, Jun 21, 2022 at 04:46:02PM -0600, Alex Williamson wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, 15 Jun 2022 17:03:01 -0700
> Nicolin Chen wrote:
>
> > From: Jason Gunthorpe
> >
> > The KVM mechanism for controlling wbinvd is based on OR of the coherenc
On Thu, 2022-06-16 at 20:07 +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
> cause pgtable PA size larger than 32bit.
>
> Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
> so add a quirk to allow th
On 2022/6/21 23:14, Robin Murphy wrote:
Many drivers do nothing meaningful for .release_device, and it's neatly
abstracted to just two callsites in the core code, so let's make it
optional to implement.
Signed-off-by: Robin Murphy
---
drivers/iommu/fsl_pamu_domain.c | 5 -
drivers/iommu/
On 2022/6/21 23:14, Robin Murphy wrote:
Since .release_device is now called through per-device ops, any call
which gets as far as a driver definitely*is* for that driver, for a
device which has successfully passed .probe_device, so all the checks to
that effect are now redundant and can be remov
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 5:04 PM
>
> On 2022/6/21 13:48, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 12:28 PM
> >>
> >> On 2022/6/21 11:46, Tian, Kevin wrote:
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 11:39 AM
>
> On
Hi，
在 2022/6/20 16:17, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has alrea
On 2022/6/22 10:56, Ethan Zhao wrote:
在 2022/6/20 16:17, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed" fa
On 2022/6/22 11:06, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 5:04 PM
On 2022/6/21 13:48, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 12:28 PM
On 2022/6/21 11:46, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 11:39 AM
On 2022/6/21 10:5
> From: Baolu Lu
> Sent: Wednesday, June 22, 2022 11:28 AM
>
> On 2022/6/22 11:06, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Tuesday, June 21, 2022 5:04 PM
> >>
> >> On 2022/6/21 13:48, Tian, Kevin wrote:
> From: Baolu Lu
> Sent: Tuesday, June 21, 2022 12:28 PM
>
> On
On 2022/6/22 11:31, Tian, Kevin wrote:
From: Baolu Lu
Sent: Wednesday, June 22, 2022 11:28 AM
On 2022/6/22 11:06, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 5:04 PM
On 2022/6/21 13:48, Tian, Kevin wrote:
From: Baolu Lu
Sent: Tuesday, June 21, 2022 12:28 PM
On 2022/6/21 1
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has already been marked as present. As
the resul
Hi,
* Saravana Kannan [220621 19:29]:
> On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Saravana Kannan [700101 02:00]:
> > > Now that fw_devlink=on by default and fw_devlink supports
> > > "power-domains" property, the execution will never get to the point
> > > whe
> From: Lu Baolu
> Sent: Wednesday, June 22, 2022 12:41 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
> failed" fail
59 matches
Mail list logo
