On Tue, Dec 29, 2020 at 8:06 PM Yong Wu wrote:
>
> On Wed, 2020-12-23 at 17:36 +0900, Tomasz Figa wrote:
> > On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
> > > In the previous SoC, the M4U HW is in the EMI power domain which is
> > > always on. the latest M4U is in the display power
On Wed, Dec 23, 2020 at 8:00 PM Robin Murphy wrote:
>
> On 2020-12-23 08:56, Tomasz Figa wrote:
> > On Wed, Dec 16, 2020 at 06:36:06PM +0800, Yong Wu wrote:
> >> In current iommu_unmap, this code is:
> >>
> >> iommu_iotlb_gather_init(_gather);
> >> ret = __iommu_unmap(domain, iova,
From: Chunyan Zhang
This patch only adds display iommu support, the driver was tested with sprd
dpu.
The iommu support for others would be added once finished tests with those
devices, such as Image codec(jpeg) processor, a few signal processors,
including VSP(video), GSP(graphic), ISP(image),
From: Chunyan Zhang
This patch only adds bindings to support display iommu.
The iommu support for others would be added once finished tests with those
devices, such as Image codec(jpeg) processor, a few signal processors,
including VSP(video), GSP(graphic), ISP(image), and camera CPP, etc.
From: Chunyan Zhang
Changes since RFC v1:
* Rebased on v5.11-rc1;
* Changed sprd-iommu to tristate;
* Removed check for args_count of iommu OF node, since there's no args
for sprd-iommu device node;
* Added another IP version (i.e. vau);
* Removed unnecessary configs selection from
On Fri, 8 Jan 2021 at 10:25, Rob Herring wrote:
>
> On Wed, Dec 23, 2020 at 07:16:32PM +0800, Chunyan Zhang wrote:
> > From: Chunyan Zhang
> >
> > This patch only adds bindings to support display iommu, support for others
> > would be added once finished tests with those devices, such as Image
>
Hi Lu,
On Fri, Jan 08, 2021 at 07:52:47AM +0800, Lu Baolu wrote:
> On 2021/1/6 9:09, Lu Baolu wrote:
> > On 2021/1/6 3:03, Will Deacon wrote:
> > > On Thu, Dec 31, 2020 at 08:53:20AM +0800, Lu Baolu wrote:
> > > > @@ -170,6 +172,22 @@ static void intel_flush_svm_range_dev
> > > > (struct
On Wed, Dec 23, 2020 at 8:00 PM Robin Murphy wrote:
>
> On 2020-12-23 08:56, Tomasz Figa wrote:
> > On Wed, Dec 16, 2020 at 06:36:06PM +0800, Yong Wu wrote:
> >> In current iommu_unmap, this code is:
> >>
> >> iommu_iotlb_gather_init(_gather);
> >> ret = __iommu_unmap(domain, iova,
On Fri, Jan 08, 2021 at 11:17:25AM +0530, Sai Prakash Ranjan wrote:
> On 2021-01-07 22:27, isa...@codeaurora.org wrote:
> > On 2021-01-06 03:56, Will Deacon wrote:
> > > On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
> > > > commit ecd7274fb4cd ("iommu: Remove unused
On 2021-01-08 10:18, Will Deacon wrote:
On Fri, Jan 08, 2021 at 11:17:25AM +0530, Sai Prakash Ranjan wrote:
On 2021-01-07 22:27, isa...@codeaurora.org wrote:
> On 2021-01-06 03:56, Will Deacon wrote:
> > On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
> > > commit
On 2021-01-07 21:47, Sai Prakash Ranjan wrote:
On 2021-01-07 22:27, isa...@codeaurora.org wrote:
On 2021-01-06 03:56, Will Deacon wrote:
On Thu, Dec 24, 2020 at 12:10:07PM +0530, Sai Prakash Ranjan wrote:
commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY
flag")
removed unused
Hi Linus,
Please pull these IOMMU fixes for -rc3. It's mainly all Intel VT-D stuff,
but there are some fixes for AMD and ARM as well. We've also got the
revert I promised during the merge window, which removes a temporary
hack to accomodate i915 while we transitioned the Intel IOMMU driver
over
Hi Eric,
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 16 November 2020 11:00
> To: eric.auger@gmail.com; eric.au...@redhat.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu;
Hi Eric,
> -Original Message-
> From: Eric Auger [mailto:eric.au...@redhat.com]
> Sent: 18 November 2020 11:22
> To: eric.auger@gmail.com; eric.au...@redhat.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> k...@vger.kernel.org; kvm...@lists.cs.columbia.edu;
Hi Will,
On 2021/1/8 22:09, Will Deacon wrote:
Hi Lu,
On Fri, Jan 08, 2021 at 07:52:47AM +0800, Lu Baolu wrote:
On 2021/1/6 9:09, Lu Baolu wrote:
On 2021/1/6 3:03, Will Deacon wrote:
On Thu, Dec 31, 2020 at 08:53:20AM +0800, Lu Baolu wrote:
@@ -170,6 +172,22 @@ static void
On 14.12.2020 14:01, Robin Murphy wrote:
> On 2020-12-13 16:32, Heiner Kallweit wrote:
>> Zillions of drivers use the unlikely() hint when checking the result of
>> dma_mapping_error(). This is an inline function anyway, so we can move
>> the hint into this function and remove it from drivers.
>
Allow drivers to query and enable IOMMU_DEV_FEAT_IOPF, which amounts to
checking whether PRI is enabled.
Signed-off-by: Jean-Philippe Brucker
---
Cc: David Woodhouse
Cc: Lu Baolu
---
drivers/iommu/intel/iommu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCIe PRI, but doesn't require devices to have
their own translation cache. Instead, faulting transactions are parked
and the OS is given a chance to fix the page tables and retry the
transaction.
Enable
Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCIe PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
fault report
Add stall support to the SMMUv3, along with a common I/O Page Fault
handler.
Changes since v8 [1]:
* Added patches 1 and 2 which aren't strictly related to IOPF but need to
be applied in order - 8 depends on 2 which depends on 1. Patch 2 moves
pasid-num-bits to a device property, following
Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
dev_iommu") removed iommu_priv from fwspec. Update the struct doc.
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index
Some devices manage I/O Page Faults (IOPF) themselves instead of relying
on PCIe PRI or Arm SMMU stall. Allow their drivers to enable SVA without
mandating IOMMU-managed IOPF. The other device drivers now need to first
enable IOMMU_DEV_FEAT_IOPF before enabling IOMMU_DEV_FEAT_SVA.
Signed-off-by:
The pasid-num-bits property shouldn't need a dedicated fwspec field,
it's a job for device properties. Add properties for IORT, and access
the number of PASID bits using device_property_read_u32().
Suggested-by: Robin Murphy
Signed-off-by: Jean-Philippe Brucker
---
include/linux/iommu.h
The IOPF (I/O Page Fault) feature is now enabled independently from the
SVA feature, because some IOPF implementations are device-specific and
do not require IOMMU support for PCIe PRI or Arm SMMU stall.
Enable IOPF unconditionally when enabling SVA for now. In the future, if
a device driver
When handling faults from the event or PRI queue, we need to find the
struct device associated with a SID. Add a rb_tree to keep track of
SIDs.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 13 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 161
On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.
Reviewed-by: Rob Herring
Signed-off-by: Jean-Philippe Brucker
---
.../devicetree/bindings/iommu/iommu.txt|
Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.
Signed-off-by: Jean-Philippe Brucker
---
v9: dropped fwspec member in favor of device properties
---
drivers/acpi/arm64/iort.c | 4 +++-
1 file changed, 3 insertions(+),
Hi-
[ Please cc: me on replies, I'm not currently subscribed to
iommu@lists ].
I'm running NFS performance tests on InfiniBand using CX-3 Pro cards
at 56Gb/s. The test is iozone on an NFSv3/RDMA mount:
/home/cel/bin/iozone -M -+u -i0 -i1 -s1g -r256k -t12 -I
For those not familiar with the way
The iommu_map_sg() code currently iterates through the given
scatter-gather list, and in the worst case, invokes iommu_map()
for each element in the scatter-gather list, which calls into
the IOMMU driver through an indirect call. For an IOMMU driver
that uses a format supported by the io-pgtable
While mapping a scatter-gather list, iommu_map_sg() calls
into the IOMMU driver through an indirect call, which can
call into the io-pgtable code through another indirect call.
This sequence of going through the IOMMU core code, the IOMMU
driver, and finally the io-pgtable code, occurs for every
Add support for IOMMU drivers to have their own map_sg() callbacks.
This completes the path for having iommu_map_sg() invoke an IOMMU
driver's map_sg() callback, which can then invoke the io-pgtable
map_sg() callback with the entire scatter-gather list, so that it
can be processed entirely in the
Implement the map_sg io-pgtable op for the ARMv7s io-pgtable
code, so that IOMMU drivers can call it when they need to map
a scatter-gather list.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 90 ++
1 file changed, 90
Implement the map_sg io-pgtable op for the ARM LPAE io-pgtable
code, so that IOMMU drivers can call it when they need to map
a scatter-gather list.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm.c | 86 ++
drivers/iommu/iommu.c
Now that everything is in place for iommu_map_sg() to defer
mapping a scatter-gather list to the io-pgtable layer, implement
the map_sg() callback in the SMMU driver, so that iommu_map_sg()
can invoke it with the entire scatter-gather list that will be
mapped.
Signed-off-by: Isaac J. Manjarres
The pull request you sent on Fri, 8 Jan 2021 14:39:51 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/iommu-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3e2a590acbed38a6908a5c4df7754dcb65f6fd37
Thank you!
--
Deet-doot-dot, I am a
35 matches
Mail list logo
