On 2022-02-15 13:42, Will Deacon wrote:
On Tue, Feb 15, 2022 at 01:30:26PM +, Robin Murphy wrote:
On 2022-02-15 13:00, Will Deacon wrote:
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
On 2022/1/24 21:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work
On 2022-02-15 13:00, Will Deacon wrote:
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
On 2022/1/24 21:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work with identical
mapping. So add a quirk for the device to force the domain
passthrough.
Signed-off-by:
On 2022-02-15 09:11, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
Device drivers calling into iommu_attach_device() is seldom a good
idea. In this case the sound device has some generic
On 2022-02-11 20:27, alyssa.rosenzw...@collabora.com wrote:
From: Alyssa Rosenzweig
From the kernel's perspective, pre-CSF Valhall is more or less
compatible with Bifrost, although they differ to userspace. Add a
compatible for Valhall to the existing Bifrost bindings documentation.
On 2022-02-14 20:31, Alyssa Rosenzweig wrote:
MT8192 requires 5 power domains. Rather than bump MAX_PM_DOMAINS and
waste memory on every supported Panfrost chip, instead dynamically
allocate pm_domain_devs and pm_domain_links. This adds some flexibility;
it seems inevitable a new MediaTek device
at
the 7-instruction sequence that Mark and I had come up with and certain
that it could be shortened still. Kinda sad to see it go, but at the
same time, glad that it can.
Acked-by: Robin Murphy
On a defconfig build, this saves over 28KB of .text.
Not to mention saving those "WTF is
at
the 7-instruction sequence that Mark and I had come up with and certain
that it could be shortened still. Kinda sad to see it go, but at the
same time, glad that it can.
Acked-by: Robin Murphy
On a defconfig build, this saves over 28KB of .text.
Not to mention saving those "WTF is
On 2022-02-14 14:56, Jason Gunthorpe via iommu wrote:
On Mon, Feb 14, 2022 at 02:10:19PM +, Robin Murphy wrote:
On 2022-02-14 12:45, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace
On 2022-02-14 14:39, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote:
Groups should disappear into an internal implementation detail, not be
so prominent in the API.
Not going to happen, IOMMU groups are ABI and todays device assignment
code, including
Make "fast" users call a separate rcache init explicitly, which includes
error checking.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
Differences to v1:
- Drop stubs for iova_domain_init_rcaches() and iova_domain_free_rcaches()
- Use put_iova_domain() in vdpa code
diff --git
Make "fast" users call a separate rcache init explicitly, which includes
error checking.
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
---
Differences to v1:
- Drop stubs for iova_domain_init_rcaches() and iova_domain_free_rcaches()
- Use put_iova_domain() in vdpa code
diff --git
On 2022-02-14 12:45, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace the domain of an iommu group for frameworks
like vfio which claims the ownership of the whole iommu group
On 2022-02-14 11:43, Joerg Roedel wrote:
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
Because of the possible failure of the dma_supported(), the
dma_set_mask_and_coherent() may return error num.
Therefore, it should be better to check it and
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace the domain of an iommu group for frameworks
like vfio which claims the ownership of the whole iommu group.
But if the underlying point is the new expectation that
iommu_{attach,detach}_device() operate on the device's whole
On 2022-02-10 23:58, Martin Oliveira wrote:
On 2/9/22 1:41 AM, Chaitanya Kulkarni wrote:
On 2/8/22 6:50 PM, Martin Oliveira wrote:
Hello,
We have been hitting an error when running IO over our nvme-of setup, using the
mlx5 driver and we are wondering if anyone has seen anything similar/has
Implementing ops->capable to always return false is pointless since it's
the default behaviour anyway. Clean up the unnecessary implementations.
Signed-off-by: Robin Murphy
---
Spinning this out of my bus ops stuff (currently 30 patches and
counting...) since it would be better off alongs
On 2022-02-09 14:09, Aleksandr Fedorov wrote:
iommu_dma_get_resv_regions() assumes that iommu_fwspec field for
corresponding device is set which is not always true. Since
iommu_dma_get_resv_regions() seems to be a future-proof generic API
that can be used by any iommu driver, add an explicit
On 2022-02-08 01:25, Lu Baolu wrote:
The is_attach_deferred iommu_ops callback is a device op. The domain
argument is unnecessary and never used. Remove it to make code clean.
Suggested-by: Robin Murphy
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 2 +-
drivers/iommu/amd
On 2022-02-09 02:50, Martin Oliveira wrote:
Hello,
We have been hitting an error when running IO over our nvme-of setup, using the
mlx5 driver and we are wondering if anyone has seen anything similar/has any
suggestions.
Both initiator and target are AMD EPYC 7502 machines connected over
On 2022-02-08 15:19, Will Deacon wrote:
On Thu, Dec 23, 2021 at 02:14:35PM +, Robin Murphy wrote:
On 2021-12-23 13:00, Lad Prabhakar wrote:
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using
On 2022-02-07 14:13, Andy Shevchenko wrote:
Use DMA ops setter instead of direct assignment. Even we know that
this module doesn't perform access to the dma_ops member of struct device,
it's better to use setter to avoid potential problems in the future.
What potential problems are you
On 2022-02-05 17:11, Christophe JAILLET wrote:
Use devm_bitmap_zalloc() instead of hand writing it.
Heh, that reminds me that I have more or less the same patch sat locally
somewhere, except IIRC I took it further and removed the unhelpful error
message and pruned the local variables as well
-by: Christophe JAILLET
---
This is NOT compile tested.
I don't have the needed cross compiling tools.
FYI, https://cdn.kernel.org/pub/tools/crosstool/
Either way, the patch looks reasonable, thanks!
Acked-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 ++--
1 file
It's been a long time since there was any reason to register IOMMU
drivers early. Convert to the standard platform driver helper.
CC: Heiko Stuebner
Signed-off-by: Robin Murphy
---
drivers/iommu/rockchip-iommu.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers
It's been a long time since there was any reason to register IOMMU
drivers early. Convert to the standard platform driver helper.
CC: Andy Gross
CC: Bjorn Andersson
Signed-off-by: Robin Murphy
---
drivers/iommu/msm_iommu.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions
On 2022-02-04 05:46, Josh Poimboeuf wrote:
Hi all,
We've gotten significant slowdowns on arm64 with 4k pages compared to
64k. The slowdowns can be alleviated by setting iommu.strict=0 or
iommu.passthrough=1.
Is there a reason x86 defaults to lazy iommu, while arm64 does not? Are
there
On 2022-01-30 00:46, Linus Walleij wrote:
On Thu, Jan 20, 2022 at 4:00 PM Paul Kocialkowski
wrote:
There are lots of different versions of the logicvc block and it
makes little sense to list them all in compatibles since all versions
with the same major are found to be register-compatible.
On 2022-02-02 08:12, Christoph Hellwig wrote:
I think this interface is a little too hacky. In the end all the
non-trusted hypervisor schemes (including the per-device swiotlb one)
can allocate the memory from everywhere and want for force use of
swiotlb. I think we need some kind of proper
On 2022-01-30 07:43, Joerg Roedel wrote:
Hi Jacob, Baolu,
On Fri, Jan 28, 2022 at 11:10:01AM +0800, Lu Baolu wrote:
During PCI bus rescan, adding new devices involve two notifiers.
1. dmar_pci_bus_notifier()
2. iommu_bus_notifier()
The current code sets #1 as low priority (INT_MIN) which
On 2022-01-28 11:32, John Garry wrote:
On 26/01/2022 17:00, Robin Murphy wrote:
As above, I vote for just forward-declaring the free routine in iova.c
and keeping it entirely private.
BTW, speaking of forward declarations, it's possible to remove all the
forward declarations in iova.c now
On 2022-01-28 11:32, John Garry wrote:
On 26/01/2022 17:00, Robin Murphy wrote:
As above, I vote for just forward-declaring the free routine in iova.c
and keeping it entirely private.
BTW, speaking of forward declarations, it's possible to remove all the
forward declarations in iova.c now
was for omap_iommu_prepare() instead
Certainly no harm in keeping the documentation up to date!
Reviewed-by: Robin Murphy
Signed-off-by: John Garry
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index 50ee27bbd04e..06fee7416816 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
On 2022-01-28 08:11, Yong Wu wrote:
[...]
diff --git a/include/linux/component.h b/include/linux/component.h
index 16de18f473d7..5a7468ea827c 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,6 +2,8 @@
#ifndef COMPONENT_H
#define COMPONENT_H
+#include
On 2022-01-28 08:11, Yong Wu wrote:
[...]
diff --git a/include/linux/component.h b/include/linux/component.h
index 16de18f473d7..5a7468ea827c 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,6 +2,8 @@
#ifndef COMPONENT_H
#define COMPONENT_H
+#include
On 2022-01-26 18:44, Peter Geis wrote:
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
1 file changed, 36 insertions(+), 1
On 2022-01-26 13:55, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition, fails in init_iova_rcaches() are not handled safely, which is
less than ideal.
Make "fast"
On 2022-01-26 13:55, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition, fails in init_iova_rcaches() are not handled safely, which is
less than ideal.
Make "fast"
On 2022-01-26 15:09, Sergiy Kibrik wrote:
Hi Robin,
This could break Linux guests, since depending on the deferred probe
timeout setting it could lead to drivers never probing because the "IOMMU"
never becomes available.
I've noticed no deferred probe timeouts when booting with this patch.
On 2022-01-26 13:27, Jason Gunthorpe via iommu wrote:
On Wed, Jan 26, 2022 at 09:51:36AM +0800, Lu Baolu wrote:
they are fundamentally different things in their own right, and the ideal
API should give us the orthogonality to also bind a device to an SVA domain
without PASID (e.g. for KVM
On 2022-01-26 11:54, Hyeonggon Yoo wrote:
Last month we discussed drivers that uses kmalloc(GFP_DMA) for
noncoherent mapping should be converted to use DMA API [1]. Simple
grep with GFP_DMA shows that many of drivers are mistakenly
using GFP_DMA flag.
So our purpose was to make DMA API choose
Test email 2
[PES Logo]
Robin Murphy
Press & Communications Officer
Mobile: +32 491 86 97 48
robin.mur...@pes.eu<mailto:robin.mur...@pes.eu>
Party of European Socialists
10-12 Rue Guimard
B-1040 Brussels
Belgium
www.pes.eu<http://www.pes.eu/>
twitter.com/pes_pse<https://
Test email 2
[PES Logo]
Robin Murphy
Press & Communications Officer
Mobile: +32 491 86 97 48
robin.mur...@pes.eu<mailto:robin.mur...@pes.eu>
Party of European Socialists
10-12 Rue Guimard
B-1040 Brussels
Belgium
www.pes.eu<http://www.pes.eu/>
twitter.com/pes_pse<https://
On 2022-01-25 19:12, Helge Deller wrote:
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
On 2022-01-25 13:00, Shameerali Kolothum Thodi wrote:
Hi Robin/Lorenzo,
-Original Message-
From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf
Of Shameer Kolothum
Sent: 05 August 2021 09:07
To: linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
On 2022-01-24 17:44, Jason Gunthorpe wrote:
On Mon, Jan 24, 2022 at 09:46:26AM +, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, January 24, 2022 3:11 PM
Hi,
The guest pasid and aux-domain related code are dead code in current
iommu subtree. As we have reached a consensus that all these
On 2022-01-25 06:27, Lu Baolu wrote:
On 1/25/22 8:57 AM, Robin Murphy wrote:
On 2022-01-24 07:11, Lu Baolu wrote:
Add a domain specific callback set, domain_ops, for vendor iommu driver
to provide domain specific operations. Move domain-specific callbacks
from iommu_ops to the domain_ops
On 2022-01-24 07:11, Lu Baolu wrote:
Add a domain specific callback set, domain_ops, for vendor iommu driver
to provide domain specific operations. Move domain-specific callbacks
from iommu_ops to the domain_ops and hook them when a domain is allocated.
I think it would make a lot of sense for
On 2022-01-24 07:11, Lu Baolu wrote:
The common iommu_ops is hooked to both device and domain. When a helper
has both device and domain pointer, the way to get the iommu_ops looks
messy in iommu core. This sorts out the way to get iommu_ops. The device
related helpers go through device pointer,
Prefer kcalloc() to kzalloc(array_size()) for allocating an array.
Signed-off-by: Robin Murphy
---
kernel/dma/swiotlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index f56d6504903c..44c49c3616fe 100644
--- a/kernel/dma
io_tlb_default_mem now makes debugfs_dir redundant.
Signed-off-by: Robin Murphy
---
kernel/dma/swiotlb.c | 40 ++--
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index f1e7ea160b43..bdce89e053bd 100644
, linux/io.h subsumes asm/io.h; and by now it's a
mystery why asm/dma.h was ever here at all.
Signed-off-by: Robin Murphy
---
kernel/dma/swiotlb.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index
Hi all,
Here's a little collection of cleanup patches for some annoyances
that have built up while looking at SWIOTLB code recently.
Cheers,
Robin.
Robin Murphy (3):
swiotlb: Simplify debugfs setup
swiotlb: Tidy up includes
swiotlb: Simplify array allocation
kernel/dma/swiotlb.c | 74
On 2022-01-21 07:16, Vijayanand Jitta wrote:
On 1/18/2022 9:27 PM, Vijayanand Jitta wrote:
On 1/18/2022 7:19 PM, Robin Murphy wrote:
On 2022-01-12 13:13, Vijayanand Jitta wrote:
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in proc
On 2022-01-20 15:27, Keith Busch wrote:
On Thu, Jan 20, 2022 at 02:56:02PM +0100, Christoph Hellwig wrote:
- on the input side to dma mapping the bio_vecs (or phyrs) are chained
as bios or whatever the containing structure is. These already exist
and have infrastructure at least in
On 2022-01-12 13:13, Vijayanand Jitta wrote:
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in process of freeing dev->iommu
in dev_iommu_free function, a deferred_probe_work_func runs in parallel
and tries to access dev->iommu->fwspec in
On 2022-01-17 12:32, Sergiy Kibrik wrote:
In IOMMU-capable system hypervisor usually takes over IOMMU control.
Generally guest domains don't need to care about IOMMU management and take any
extra actions. Yet in some cases a knowledge about which device is protected
may be useful for privileged
On 2021-12-23 11:06, asheplya...@basealt.ru wrote:
From: Alexey Sheplyakov
T62x/T60x GPUs are known to not work with panfrost as of now.
One of the reasons is wrong/incomplete memory attributes which
the panfrost driver sets in the page tables:
- MEMATTR_IMP_DEF should be 0x48ULL, not
On 2021-12-24 08:02, Nicolin Chen wrote:
On Thu, Dec 23, 2021 at 11:14:17AM +, Robin Murphy wrote:
External email: Use caution opening links or attachments
On 2021-12-22 22:52, Nicolin Chen wrote:
On Wed, Dec 22, 2021 at 12:32:29PM +, Robin Murphy wrote:
External email: Use caution
controller that could cause deferral, but on the other hand I
don't think there's any good reason *not* to propagate the original
error anyway, so sure, why not.
Reviewed-by: Robin Murphy
Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Signed-off-by: Lad
On 2021-12-23 13:00, Lad Prabhakar wrote:
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup
On 2021-12-22 22:52, Nicolin Chen wrote:
On Wed, Dec 22, 2021 at 12:32:29PM +, Robin Murphy wrote:
External email: Use caution opening links or attachments
On 2021-11-19 07:19, Nicolin Chen via iommu wrote:
When VCMDQs are assigned to a VINTF that is owned by a guest, not
hypervisor
On 21/12/2021 6:46 pm, Jason Gunthorpe wrote:
On Tue, Dec 21, 2021 at 04:50:56PM +, Robin Murphy wrote:
this proposal is the worst of both worlds, in that drivers still have to be
just as aware of groups in order to know whether to call the _shared
interface or not, except it's now
On 2021-11-19 07:19, Nicolin Chen via iommu wrote:
When VCMDQs are assigned to a VINTF that is owned by a guest, not
hypervisor (HYP_OWN bit is unset), only TLB invalidation commands
are supported. This requires get_cmd() function to scan the input
cmd before selecting cmdq between smmu->cmdq
On 2021-12-21 22:00, Nicolin Chen wrote:
[...]
The challenge to make ECMDQ useful to Linux is how to make sure that all
the commands expected to be within scope of a future CMND_SYNC plus that
sync itself all get issued on the same queue, so I'd be mildly surprised
if you didn't have the same
On 2021-12-22 02:54, Guo Zhengkui wrote:
Remove a duplicate "#include ". The deleted one in line 43
is under "#ifdef CONFIG_DMA_RESTRICTED_POOL". However, there is already
one in line 53 with no conditional compile.
Signed-off-by: Guo Zhengkui
---
kernel/dma/swiotlb.c | 1 -
1 file changed,
On 2021-12-20 19:27, Nicolin Chen wrote:
Hi Robin,
Thank you for the reply!
On Mon, Dec 20, 2021 at 06:42:26PM +, Robin Murphy wrote:
On 2021-11-19 07:19, Nicolin Chen wrote:
From: Nate Watterson
NVIDIA's Grace Soc has a CMDQ-Virtualization (CMDQV) hardware,
which extends the standard
On 2021-12-20 23:58, Vlastimil Babka wrote:
On 12/16/21 16:00, Hyeonggon Yoo wrote:
On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote:
On 12/1/21 19:14, Vlastimil Babka wrote:
Folks from non-slab subsystems are Cc'd only to patches affecting them, and
this cover letter.
Series
On 2021-12-17 06:37, Lu Baolu wrote:
The iommu_attach/detach_device() interfaces were exposed for the device
drivers to attach/detach their own domains. The commit <426a273834eae>
("iommu: Limit iommu_attach/detach_device to device with their own group")
restricted them to singleton groups to
On 2021-11-19 07:19, Nicolin Chen wrote:
From: Nate Watterson
NVIDIA's Grace Soc has a CMDQ-Virtualization (CMDQV) hardware,
which extends the standard ARM SMMU v3 IP to support multiple
VCMDQs with virtualization capabilities. In-kernel of host OS,
they're used to reduce contention on a
Hi John,
On 2021-12-20 08:49, John Garry wrote:
On 24/09/2021 11:01, John Garry wrote:
Only dma-iommu.c and vdpa actually use the "fast" mode of IOVA alloc and
free. As such, it's wasteful that all other IOVA domains hold the rcache
memories.
In addition, the current IOVA domain init
Hi John,
On 2021-12-20 08:49, John Garry wrote:
On 24/09/2021 11:01, John Garry wrote:
Only dma-iommu.c and vdpa actually use the "fast" mode of IOVA alloc and
free. As such, it's wasteful that all other IOVA domains hold the rcache
memories.
In addition, the current IOVA domain init
On 2021-12-20 12:34, Joerg Roedel wrote:
From: Joerg Roedel
Some users of iova.h still expect that dma-mapping.h is also included.
Re-add the include until these users are updated to fix compile
failures in the iommu tree.
Acked-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
include
e than a year after
that commit ;)
As an improvement rather than a fix, though,
Reviewed-by: Robin Murphy
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
e than a year after
that commit ;)
As an improvement rather than a fix, though,
Reviewed-by: Robin Murphy
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
e than a year after
that commit ;)
As an improvement rather than a fix, though,
Reviewed-by: Robin Murphy
Signed-off-by: Lu Baolu
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/
Complete the move into iommu-dma by refactoring the flush queues
themselves to belong to the DMA cookie rather than the IOVA domain.
The refactoring may as well extend to some minor cosmetic aspects
too, to help us stay one step ahead of the style police.
Signed-off-by: Robin Murphy
code movement with no functional change; refactoring to
clean up the headers and definitions will follow.
Reviewed-by: John Garry
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 177 +-
drivers/iommu/iova.c | 175
Squash and simplify some of the freeing code, and move the init
and free routines down into the rest of the flush queue code to
obviate the forward declarations.
Reviewed-by: John Garry
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 131 +++
1
de over to using free_pages_list().
Signed-off-by: Matthew Wilcox (Oracle)
[rm: split from original patch, cosmetic tweaks, fix fq entries]
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/intel/iommu.c | 89 +
drivers/iommu/io
free_pages_list().
Signed-off-by: Matthew Wilcox (Oracle)
[rm: split from original patch, cosmetic tweaks]
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/io_pgtable.c | 50 --
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/am
thing to do before we work on it further. As part of
that, also fix the types to avoid all the needless casting back and
forth which just gets in the way.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/io_pgtable.c | 82 ++
1 file changed, 34 insertions(+), 48
around instead, but only until a later patch untangles it again.
Reviewed-by: John Garry
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 13 +
drivers/iommu/iova.c | 11 +--
include/linux/iova.h | 11 +++
3 files
All flush queues are driven by iommu-dma now, so there is no need to
abstract entry_dtor or its data any more. Squash the now-canonical
implementation directly into the IOVA code to get it out of the way.
Reviewed-by: John Garry
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
John Garry
Signed-off-by: Xiongfeng Wang
[ rm: rewrite commit message ]
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 9e8bc802ac05..920fcc27c9a1 100644
--- a/drivers/io
.git.robin.mur...@arm.com/
Matthew Wilcox (Oracle) (2):
iommu/amd: Use put_pages_list
iommu/vt-d: Use put_pages_list
Robin Murphy (6):
iommu/iova: Squash entry_dtor abstraction
iommu/iova: Squash flush_cb abstraction
iommu/amd: Simplify pagetable freeing
iommu/iova: Consolidate flush queue code
On 2021-12-16 08:02, Christoph Hellwig wrote:
@@ -147,7 +142,7 @@ struct iova *reserve_iova(struct iova_domain *iovad,
unsigned long pfn_lo,
unsigned long pfn_hi);
void init_iova_domain(struct iova_domain *iovad, unsigned long granule,
unsigned long start_pfn);
-int
Include dma-mapping.h directly in the remaining places that touch the
DMA API, to avoid imminent breakage from refactoring other headers.
Signed-off-by: Robin Murphy
---
This makes arm64 allmodconfig build cleanly for me with the IOVA series,
so hopefully is the last of it...
drivers/gpu/drm
Include dma-mapping.h directly in the remaining places that touch the
DMA API, to avoid imminent breakage from refactoring other headers.
Signed-off-by: Robin Murphy
---
This makes arm64 allmodconfig build cleanly for me with the IOVA series,
so hopefully is the last of it...
drivers/gpu/drm
Hi Andre,
On 2021-12-14 17:55, Andre Przywara wrote:
The Juno Arm development board is an open, vendor-neutral, Armv8-A
development platform.
Add documentation that briefly outlines the hardware, and describes
building and installation of U-Boot.
Signed-off-by: Andre Przywara
---
On 2021-12-14 17:18, John Garry via iommu wrote:
On 10/12/2021 17:54, Robin Murphy wrote:
+ iovad->fq_domain = fq_domain;
+ iovad->fq = queue;
+
+ timer_setup(>fq_timer, fq_flush_timeout, 0);
+ atomic_set(>fq_timer_on, 0);
+
+ return 0;
+}
+
+
nit: a singl
On 2021-11-08 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when programming engines
On 2021-11-08 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when programming engines
On 2021-12-14 14:48, Will Deacon wrote:
On Tue, Dec 07, 2021 at 02:32:48PM +0800, Zhou Wang wrote:
The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of
evtq and priq") decreases evtq and priq, which may lead evtq/priq to be
full with fault events, e.g HiSilicon ZIP/SEC/HPRE
On 2021-12-10 18:04, John Garry via iommu wrote:
On 10/12/2021 17:54, Robin Murphy wrote:
From: Xiongfeng Wang
It turns out to be possible for hotplugging out a device to reach the
stage of tearing down the device's group and default domain before the
domain's flush queue has drained naturally
Complete the move into iommu-dma by refactoring the flush queues
themselves to belong to the DMA cookie rather than the IOVA domain.
The refactoring may as well extend to some minor cosmetic aspects
too, to help us stay one step ahead of the style police.
Signed-off-by: Robin Murphy
---
v2
code movement with no functional change; refactoring to
clean up the headers and definitions will follow.
Signed-off-by: Robin Murphy
---
v2: Rebase with del_timer_sync() change
drivers/iommu/dma-iommu.c | 179 +-
drivers/iommu/iova.c | 175
Squash and simplify some of the freeing code, and move the init
and free routines down into the rest of the flush queue code to
obviate the forward declarations.
Signed-off-by: Robin Murphy
---
v2: Rebase with del_timer_sync() change
drivers/iommu/iova.c | 131
de over to using free_pages_list().
Signed-off-by: Matthew Wilcox (Oracle)
[rm: split from original patch, cosmetic tweaks, fix fq entries]
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/intel/iommu.c | 89 +
driv
free_pages_list().
Signed-off-by: Matthew Wilcox (Oracle)
[rm: split from original patch, cosmetic tweaks]
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/amd/io_pgtable.c | 50 --
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/d
601 - 700 of 7733 matches
Mail list logo
