similar to stage 2 entries, but the memory attributes field matches
stage 1 being an index.
The nG bit is not set by the vendor driver. This one didn't seem to matter,
but we'll keep it aligned to the vendor driver.
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: lin
Hi Thomas,
On 04/03/2019 11:52, Thomas Zimmermann wrote:
This is an RFC patch set that adds support for configuring a default CMA
size, depending on the platform.
At SUSE, our ARM installer image runs on a variety of platforms. One of
these, the Raspberry Pi 3, requires CMA to be allocated on o
On 02/03/2019 06:12, Leizhen (ThunderTown) wrote:
On 2019/3/1 19:07, Jean-Philippe Brucker wrote:
Hi Leizhen,
On 01/03/2019 04:44, Leizhen (ThunderTown) wrote:
On 2019/2/26 20:36, Hanjun Guo wrote:
Hi Jean,
On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
Hi,
On 31/01/2019 13:52, Zhen
On 04/03/2019 15:32, Rob Herring wrote:
On Fri, Mar 1, 2019 at 10:28 AM Robin Murphy wrote:
On 27/02/2019 23:22, Rob Herring wrote:
ARM Mali midgard GPU page tables are similar to standard 64-bit stage 1
page tables, but have a few differences. Add a new format type to
represent the format
Hi Arnd,
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from include/linux/dma-direct.h:5,
On 04/03/2019 18:48, Rob Herring wrote:
On Mon, Mar 4, 2019 at 11:31 AM Robin Murphy wrote:
On 04/03/2019 15:32, Rob Herring wrote:
On Fri, Mar 1, 2019 at 10:28 AM Robin Murphy wrote:
On 27/02/2019 23:22, Rob Herring wrote:
ARM Mali midgard GPU page tables are similar to standard 64-bit
Hi Arnd,
On 2019-03-07 8:52 am, Arnd Bergmann wrote:
Clang has a rather annoying behavior of checking for integer
arithmetic problems in code paths that are discarded by gcc
before that perfoms the same checks.
For DMA_BIT_MASK(64), this leads to a warning despite the
result of the macro being
On 2019-03-07 9:28 am, Arnd Bergmann wrote:
On Thu, Mar 7, 2019 at 10:17 AM Robin Murphy wrote:
On 2019-03-07 8:52 am, Arnd Bergmann wrote:
-#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id
Hi John,
On 07/03/2019 14:45, John Garry wrote:
[...]
Hi guys,
Any idea what happened to this fix?
It's been in -next for a while (commit 376991db4b64) - I assume it will
land shortly and hit stable thereafter, at which point somebody gets to
sort out the manual backport past 4.20.
Robin.
signs to max32_alloc_size.
In that respect, the diff looks correct, so modulo possibly tweaking the
commit message,
Reviewed-by: Robin Murphy
Thanks,
Robin.
Cc: # 4.20+
Fixes: bee60e94a1e2 ("iommu/iova: Optimise attempts to allocate iova from 32bit
address range")
Signed-off-by:
On 19/03/2019 07:59, Lu Baolu wrote:
Hi Christoph,
On 3/14/19 12:10 AM, Christoph Hellwig wrote:
On Wed, Mar 13, 2019 at 10:31:52AM +0800, Lu Baolu wrote:
Hi again,
On 3/13/19 10:04 AM, Lu Baolu wrote:
Hi,
On 3/13/19 12:38 AM, Christoph Hellwig wrote:
On Tue, Mar 12, 2019 at 02:00:00PM +08
ss=n' to their command line or revert the
patch in their own private kernel. Of course these folks will be
less secure.
Suggested-by: Robin Murphy
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Flipped default to 'yes' and changed com
On 25/01/2019 10:13, Srinath Mannam wrote:
Few SOCs have limitation that their PCIe host can't allow few inbound
address ranges. Allowed inbound address ranges are listed in dma-ranges
DT property and this address ranges are required to do IOVA mapping.
Remaining address ranges have to be reserve
On 27/03/2019 15:00, Zhen Lei wrote:
This allows the default behaviour to be controlled by a kernel config
option instead of changing the command line for the kernel to include
"iommu.strict=0" on ARM64 where this is desired.
This is similar to CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
Note: At present
On 28/03/2019 10:34, Srinath Mannam wrote:
Hi Robin,
Thanks for your feedback. Please see my reply in line.
On Wed, Mar 27, 2019 at 8:32 PM Robin Murphy wrote:
On 25/01/2019 10:13, Srinath Mannam wrote:
Few SOCs have limitation that their PCIe host can't allow few inbound
address r
On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote:
From: Laurentiu Tudor
Add a one-to-one iommu mapping for bman private data memory (FBPR).
This is required for BMAN to work without faults behind an iommu.
Signed-off-by: Laurentiu Tudor
---
drivers/soc/fsl/qbman/bman_ccsr.c | 11 +
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
With the built-in topology description in place, x86 platforms can now
use the virtio-iommu.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/
On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
Hardware platforms usually describe the IOMMU topology using either
device-tree pointers or vendor-specific ACPI tables. For virtual
platforms that don't provide a device-tree, the virtio-iommu device
contains a description of the endpoints it
On 14/02/2020 2:09 pm, John Garry wrote:
@@ -2420,6 +2421,10 @@ void pci_device_add(struct pci_dev *dev, struct
pci_bus *bus)
/* Set up MSI IRQ domain */
pci_set_msi_domain(dev);
+ parent = dev->dev.parent;
+ if (parent && parent->bus == &pci_bus_type)
+ device_link_a
Hi Jerry,
On 2020-02-14 8:13 pm, Jerry Snitselaar wrote:
Hi Will,
On a gigabyte system with Cavium CN8xx, when doing a fio test against
an nvme drive we are seeing the following:
[ 637.161194] arm-smmu arm-smmu.1.auto: Unhandled context fault:
fsr=0x8402, iova=0x8010003f6000, fsynr=0x700
On 16/02/2020 10:11 pm, Jerry Snitselaar wrote:
On Fri Feb 14 20, Robin Murphy wrote:
Hi Jerry,
On 2020-02-14 8:13 pm, Jerry Snitselaar wrote:
Hi Will,
On a gigabyte system with Cavium CN8xx, when doing a fio test against
an nvme drive we are seeing the following:
[ 637.161194] arm-smmu
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote:
On 14/02/2020 4:04 pm, Jean-Philippe
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote:
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin
On 17/02/2020 8:01 am, Christoph Hellwig wrote:
On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote:
From: Liam Mark
Some devices have a memory map which contains gaps or holes.
In order for the device to have as much IOVA space as possible,
allow its driver to inform the DMA-IO
On 14/02/2020 11:06 pm, Isaac J. Manjarres wrote:
From: Liam Mark
Using the best-fit algorithm, instead of the first-fit
algorithm, may reduce fragmentation when allocating
IOVAs.
What kind of pathological allocation patterns make that a serious
problem? Is there any scope for simply changin
On 14/02/2020 8:30 pm, Liam Mark wrote:
When the IOVA framework applies IOVA alignment it aligns all
IOVAs to the smallest PAGE_SIZE order which is greater than or
equal to the requested IOVA size.
We support use cases that requires large buffers (> 64 MB in
size) to be allocated and mapped in
On 13/02/2020 9:49 pm, Rob Herring wrote:
On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote:
On 30/01/2020 3:06 pm, Auger Eric wrote:
Hi Rob,
On 1/17/20 10:16 PM, Rob Herring wrote:
Arm SMMUv3.2 adds support for TLB range invalidate operations.
Support for range invalidate is determined
On 18/02/2020 12:04 pm, Stephan Gerhold wrote:
[...]
Are you going to send a patch for the diff below?
AFAICT this problem still exists in 5.6-rc2.
Your patch also seems to fix a warning during probe deferral on arm64
that has been around for quite a while. (At least for me...)
(See
https://lo
On 18/02/2020 5:20 pm, Will Deacon wrote:
On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote:
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
Do not apply yet.
Please? ;)
drivers/iommu/arm-smmu-impl.c
; to
"arm_smmu". Whilst it's a bit of a bodge, this allows us to create a
single module without renaming any files and makes use of the fact that
underscores and hyphens can be used interchangeably in parameter names.
That's awful... and thus great :)
Reviewed-by: Robin Murp
ity check is full of fundamentally flawed assumptions. Make things
robust and actually functional by not trying to be quite so clever.
Reported-by: Brian Masney
Tested-by: Brian Masney
Reported-by: Naresh Kamboju
Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
Signed-off-by:
On 18/02/2020 6:23 pm, Greg Kroah-Hartman wrote:
[...]
Can you bisect to find the offending commit?
This particular presentation appears to be down to the DRM driver
starting to call of_platform_depopulate(), but it's merely exposing
badness in the IOMMU driver that's been there from day 1. I
On 19/02/2020 12:27 pm, Stephan Gerhold wrote:
Hi Will, Hi Robin,
On Fri, Jan 10, 2020 at 03:28:52PM +, Will Deacon wrote:
From: Robin Murphy
Now that we can correctly extract top-level indices without relying on
the remaining upper bits being zero, the only remaining impediments to
On 20/02/2020 5:01 pm, Christoph Hellwig wrote:
We currently only support remapping memory as uncached through vmap
or a magic uncached segment provided by some architectures. But there
is a simpler and much better way available on some architectures where
we can just remap the memory in place.
On 19/02/2020 11:22 pm, Liam Mark wrote:
On Wed, 19 Feb 2020, Will Deacon wrote:
On Mon, Feb 17, 2020 at 04:46:14PM +, Robin Murphy wrote:
On 14/02/2020 8:30 pm, Liam Mark wrote:
When the IOVA framework applies IOVA alignment it aligns all
IOVAs to the smallest PAGE_SIZE order which is
On 20/02/2020 6:38 am, isa...@codeaurora.org wrote:
On 2020-02-17 08:03, Robin Murphy wrote:
On 14/02/2020 11:06 pm, Isaac J. Manjarres wrote:
From: Liam Mark
Using the best-fit algorithm, instead of the first-fit
algorithm, may reduce fragmentation when allocating
IOVAs.
What kind of
On 20/02/2020 5:54 pm, Rob Herring wrote:
On Mon, Feb 17, 2020 at 1:17 PM Robin Murphy wrote:
On 13/02/2020 9:49 pm, Rob Herring wrote:
On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote:
On 30/01/2020 3:06 pm, Auger Eric wrote:
Hi Rob,
On 1/17/20 10:16 PM, Rob Herring wrote:
Arm
On 21/02/2020 4:47 pm, Rob Herring wrote:
On Fri, Feb 21, 2020 at 10:19 AM Robin Murphy wrote:
On 20/02/2020 5:54 pm, Rob Herring wrote:
On Mon, Feb 17, 2020 at 1:17 PM Robin Murphy wrote:
On 13/02/2020 9:49 pm, Rob Herring wrote:
On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote
We'd like to be aware of proposed DT binding changes even when they
don't directly touch the drivers themselves.
Signed-off-by: Robin Murphy
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 38fe2f3f7b6f..0a4da999fd72 100644
--- a/M
[ /me fires off MAINTAINERS patch... ]
On 20/02/2020 9:02 pm, Matthias Kaehlcke wrote:
On Thu, Feb 20, 2020 at 01:42:22PM +0530, Sharat Masetty wrote:
This patch adds a clock definition needed for powering on the GPU TBUs
and the GPU TCU.
Signed-off-by: Sharat Masetty
---
Documentation/devi
On 26/02/2020 3:44 pm, Lucas Stach wrote:
Hi all,
I'm currently struggling with how to properly check for restricted DMA
addressing from a device driver side. The basic issue I'm facing is
that I have a embedded GPU, which isn't able to address all system
memory due to interconnect being restric
On 26/02/2020 4:04 pm, Lucas Stach wrote:
On Mi, 2020-02-26 at 15:51 +, Robin Murphy wrote:
On 26/02/2020 3:44 pm, Lucas Stach wrote:
Hi all,
I'm currently struggling with how to properly check for restricted DMA
addressing from a device driver side. The basic issue I'm facing
On 27/02/2020 11:57 am, Russell King wrote:
On the LX2160A, there are lots (about 160) of IOMMU messages produced
during boot; this is excessive. Reduce the severity of these messages
to debug level.
That's... a lot. Does the system really have that many devices, or is
some driver being stupi
On 27/02/2020 1:48 pm, Russell King - ARM Linux admin wrote:
On Thu, Feb 27, 2020 at 01:44:56PM +, Robin Murphy wrote:
On 27/02/2020 11:57 am, Russell King wrote:
On the LX2160A, there are lots (about 160) of IOMMU messages produced
during boot; this is excessive. Reduce the severity of
t inadvertently get sign-extended, and thus considered invalid, if
they happen to be above 2GB in the TTB0 region.
Reported-by: Stephan Gerhold
Signed-off-by: Robin Murphy
---
Logically there may also have been a UBSAN "shift greater than size of
type" warning too, but
[ +Laurentiu ]
Hi Russell,
Thanks for sharing a log, now I properly understand what's up... further
comments at the end (for context).
On 28/02/2020 10:06 am, Russell King - ARM Linux admin wrote:
On Fri, Feb 28, 2020 at 09:33:40AM +, John Garry wrote:
On 28/02/2020 02:16, Lu Baolu wrot
segment support
For the whole series:
Reviewed-by: Robin Murphy
I think we might ultimately want to fiddle around a bit more in
dma_direct_alloc_pages() to give ARCH_HAS_DMA_SET_UNCACHED clear
precedence over DMA_DIRECT_REMAP if they have to coexist, but let's land
these patches first
On 09/03/2020 11:02 am, Kevin Grandemange wrote:
pageno is an int and the PAGE_SHIFT shift is done on an int,
overflowing if the memory is bigger than 2G
This can be reproduced using for example a reserved-memory of 4G
Nit: the example shows 16GB, not 4.
reserved-memory {
On 10/03/2020 4:23 pm, Joerg Roedel wrote:
On Tue, Mar 10, 2020 at 07:30:50PM +0530, Sibi Sankar wrote:
The accesses are initiated by the firmware
and they access modem reserved regions.
However as explained in ^^ any accesses
outside the region will result in a violation
and is controlled throu
On 11/03/2020 4:02 pm, Artem S. Tashkinov wrote:
On 3/11/20 3:47 PM, Christoph Hellwig wrote:
And actually one more idea after looking at what slab interactions
could exist. platform_device_register_full frees the dma_mask
unconditionally, even if it didn't allocated it, which might lead
to wei
use for an actual bug :)
Reviewed-by: Robin Murphy
Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform
device")
Reported-by: Artem S. Tashkinov
Tested-by: Artem S. Tashkinov
---
drivers/base/platform.c | 14 --
1 file changed, 14 deleti
On 2020-03-12 6:28 am, Sai Prakash Ranjan wrote:
Hi Robin,
On 2020-03-10 22:14, Robin Murphy wrote:
On 10/03/2020 4:23 pm, Joerg Roedel wrote:
On Tue, Mar 10, 2020 at 07:30:50PM +0530, Sibi Sankar wrote:
The accesses are initiated by the firmware
and they access modem reserved regions
omment to clarify that this is specifically
to allow vfio-platform to work with iommu-dma disabled, but either way,
Acked-by: Robin Murphy
Also this seems to be long broken, actually since Eric introduced MSI
support in 4.10-rc3, but at least since the initialisation order was
fixed with f6810c15cf9
On 2020-03-14 12:00 am, Nicolin Chen wrote:
More and more drivers set dma_masks above DMA_BIT_MAKS(32) while
only a handful of drivers call dma_set_seg_boundary(). This means
that most drivers have a 4GB segmention boundary because DMA API
returns DMA_BIT_MAKS(32) as a default value, though they
On 2020-03-16 12:46 pm, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 12:12:08PM +, Robin Murphy wrote:
On 2020-03-14 12:00 am, Nicolin Chen wrote:
More and more drivers set dma_masks above DMA_BIT_MAKS(32) while
only a handful of drivers call dma_set_seg_boundary(). This means
that
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
It might be possible to remove these obstacles if necessary. If the host
uses 64k
On 2020-03-18 4:14 pm, Auger Eric wrote:
Hi,
On 3/18/20 1:00 PM, Robin Murphy wrote:
On 2020-03-18 11:40 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO
[since this is in my inbox...]
On 2020-03-19 10:28 am, Borislav Petkov wrote:
On Thu, Mar 19, 2020 at 11:20:11AM +0100, Christoph Hellwig wrote:
I thought we agreed that decrypted is absolutely the wrong term.
I don't think we did. At least I don't know where we did that.
So NAK - if you wa
On 2020-03-02 6:16 pm, Alexander Dahl wrote:
For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4
("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's
a dependency on CONFIG_SWIOTLB, which was not necessarily active before.
The init code for swiotlb in 'pci
On 2020-03-20 2:16 pm, Christoph Hellwig wrote:
Several IOMMU drivers have a bypass mode where they can use a direct
mapping if the devices DMA mask is large enough. Add generic support
to the core dma-mapping code to do that to switch those drivers to
a common solution.
Hmm, this is _almost_,
g enough.
Thanks,
Robin.
->8-
Subject: [PATCH] iommu/arm-smmu: Refactor master_cfg/fwspec usage
In preparation for restructuring iommu_fwspec, refactor the way we
access the arm_smmu_master_cfg private data to be less dependent on
the current layout.
Signed-off-by: Robin Murphy
---
dri
On 2020-03-24 11:55 am, John Garry wrote:
On 24/03/2020 10:43, Marc Zyngier wrote:
On Tue, 24 Mar 2020 09:18:10 +
John Garry wrote:
On 23/03/2020 09:16, Marc Zyngier wrote:
+ Julien, Mark
Hi Marc,
Time to enable pseudo-NMIs in the PMUv3 driver...
Do you know if there is any plan for
On 2020-03-24 10:08 am, Joerg Roedel wrote:
Hey Robin,
On Mon, Mar 23, 2020 at 04:02:33PM +, Robin Murphy wrote:
Yikes, this ends up pretty ugly, and I'd prefer not have this much
complexity hidden in macros that were intended just to be convenient
shorthand. Would you mind pulling i
In preparation for restructuring iommu_fwspec, refactor the way we
access the arm_smmu_master_cfg private data to be less dependent on
the current layout.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 42 +---
1 file changed, 22 insertions(+), 20
omain.
Only initialise the vdomain->viommu pointer, which denotes a finalised
domain, at the end of a successful viommu_domain_finalise().
Reviewed-by: Robin Murphy
Fixes: edcd69ab9a32 ("iommu: Add virtio-iommu driver")
Reported-by: Eric Auger
Signed-off-by: Jean-Philippe Bruc
ow
setting different page masks for each endpoint.
Reviewed-by: Robin Murphy
Reported-by: Bharat Bhushan
Signed-off-by: Jean-Philippe Brucker
---
v1->v2: Move to vdomain_finalise(), improve commit message
---
drivers/iommu/virtio-iommu.c | 14 --
1 file changed, 12 insertions(+)
On 2020-03-27 1:28 pm, Sai Prakash Ranjan wrote:
Currently on reboot/shutdown, the following messages are
displayed on the console as error messages before the
system reboots/shutdown.
On SC7180:
arm-smmu 1500.iommu: removing device with active domains!
arm-smmu 504.iommu: removin
On 2020-03-27 1:02 pm, Ezequiel Garcia wrote:
Hello Joerg,
Thanks for reviewing.
I understand this change bears some controversy
for IOMMU, as developers are probably used to see these
messages.
On Fri, 2020-03-27 at 10:50 +0100, Joerg Roedel wrote:
On Mon, Mar 23, 2020 at 06:49:56PM -0300, E
On 2020-03-27 3:09 pm, Sai Prakash Ranjan wrote:
Hi Robin,
Thanks for taking a look at this.
On 2020-03-27 19:42, Robin Murphy wrote:
On 2020-03-27 1:28 pm, Sai Prakash Ranjan wrote:
Currently on reboot/shutdown, the following messages are
displayed on the console as error messages before
On 2020-03-31 2:59 pm, luanshi wrote:
Move error checking into common path to be consistent with
drivers/iommu/arm-smmu.c.
Signed-off-by: Liguang Zhang
---
drivers/iommu/arm-smmu-v3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b
On 2020-04-01 12:38 pm, Bharat Bhushan wrote:
Different endpoint can support different page size, probe
endpoint if it supports specific page size otherwise use
global page sizes.
Signed-off-by: Bharat Bhushan
---
drivers/iommu/virtio-iommu.c | 33 +++
includ
On 2020-04-02 11:16 am, Yoshihiro Shimoda wrote:
Hi John,
I found an issue after applied the following patches:
---
64c775f driver core: Rename deferred_probe_timeout and make it global
0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue()
bec6c0e pinctrl: Remove use of driver
On 2020-04-05 1:51 am, Nicolin Chen wrote:
The default segment_boundary_mask was set to DMA_BIT_MAKS(32)
a decade ago by referencing SCSI/block subsystem, as a 32-bit
mask was good enough for most of the devices.
Now more and more drivers set dma_masks above DMA_BIT_MAKS(32)
while only a handful
On 2020-04-07 7:37 pm, Joerg Roedel wrote:
From: Joerg Roedel
This is required to convert the arm-smmu driver to the
probe/release_device() interface.
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a
On 2020-04-08 3:37 pm, Joerg Roedel wrote:
Hi Robin,
thanks for looking into this.
On Wed, Apr 08, 2020 at 01:09:40PM +0100, Robin Murphy wrote:
For a hot-pluggable bus where logical devices may share Stream IDs (like
fsl-mc), this could happen:
create device A
iommu_probe_device(A
On 2020-04-13 11:25 am, Yoshihiro Shimoda wrote:
[...]
-Each bus master connected to an IPMMU must reference the IPMMU in its device
-node with the following property:
-
- - iommus: A reference to the IPMMU in two cells. The first cell is a phandle
-to the IPMMU and the second cell the numbe
On 2020-04-15 4:44 pm, Laurentiu Tudor wrote:
On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote:
On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
Hi Lorenzo,
On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote:
On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
On 2020-04-02 7:33 am, Tang Bin wrote:
Release resources when exiting on error.
Signed-off-by: Tang Bin
---
drivers/iommu/qcom_iommu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 4328da0b0..c08aa9651 10
the callback itself, but I'm not too concerned either
way. For the arm-smmu-impl.c changes,
Reviewed-by: Robin Murphy
Thanks,
Robin.
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-develope
On 2020-04-16 5:23 pm, Sai Prakash Ranjan wrote:
Hi Robin,
On 2020-04-16 19:28, Robin Murphy wrote:
On 2020-01-22 11:48 am, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm-smmu.c | 20
1 file cha
On 2020-04-20 3:37 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Signed-off-by: Jordan Crouse
Co-developed
On 2020-04-20 3:39 pm, Maxime Ripard wrote:
Hi,
On Wed, Apr 08, 2020 at 04:06:49PM +0200, Joerg Roedel wrote:
On Wed, Apr 01, 2020 at 01:47:10PM +0200, Maxime Ripard wrote:
As far as I understand it, the page table can be accessed concurrently
since the framework doesn't seem to provide any se
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Jordan Crouse
Some client devices want to directly map the IOMMU themselves instead
of using the DMA domain. Allow those devices to opt in to direct
mapping by way of a list of compatible strings.
Neat and tidy :)
Reviewed-by: Robin
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
Implement the new def_domain_type call-back for the ARM
SMMU driver. We need this to support requesting the domain
type by the client devices.
Modulo any further changes to the default domain rework,
Reviewed-by: Robin Murphy
Signed-off-by
On 2020-04-20 5:42 pm, Sai Prakash Ranjan wrote:
From: Sibi Sankar
Request direct mapping for modem on platforms which don't have TrustZone
(which programs the modem SIDs) to prevent the following global faults seen
on Cheza/Trogdor:
Not strictly true - it's patch #6/6 that prevents *those* f
On 2020-04-21 4:57 pm, Jean-Philippe Brucker wrote:
Some Arm SMMUv3 implementations, for example Arm CoreLink MMU-600, embed
the PMCG registers into the SMMU MMIO regions. It currently causes probe
failure because the PMU and SMMU drivers request overlapping resources.
Avoid the conflict by call
On 2020-04-23 9:17 am, Sai Prakash Ranjan wrote:
[...]
Any update on the status here? If I'm reading the conversation above,
Robin said: "we'll *always* see the warning because there's no way to
tear down the default DMA domains, and even if all devices *have* been
nicely quiesced there's no way
On 2020-04-24 1:40 am, Bin wrote:
Hello? anyone there?
Bin 于2020年4月23日周四 下午5:14写道：
Forget to mention, I've already disabled the slab merge, so this is what
it is.
Bin 于2020年4月23日周四 下午5:11写道：
Hey, guys:
I'm running a batch of CoreOS boxes, the lsb_release is:
```
# cat /etc/lsb-release
D
dern 64-bit-capable device, so such a latent bug could
have been easily overlooked.
Robin.
Bin 于 2020年4月24日周五 20:00写道：
Well, that's the problem! I'm assuming the iommu kernel module is leaking
memory. But I don't know why and how.
Do you have any idea about it? Or any further
On 2020-04-24 4:04 pm, Ajay kumar wrote:
Can someone check this?
On Mon, Apr 20, 2020 at 9:24 PM Ajay kumar wrote:
Hi All,
I have an IOMMU master which has limitations as mentioned below:
1) The IOMMU master internally executes a firmware, and the firmware memory
is allocated by the same mas
guess it would be fairly simple to tweak that for a
quick way to narrow down where to start looking in an offending driver.
Robin.
Robin Murphy 于2020年4月24日周五 下午8:15写道：
On 2020-04-24 1:06 pm, Bin wrote:
I'm not familiar with the mmu stuff, so what you mean by "some driver
lea
On 2020-04-28 4:32 pm, Daniel Vetter wrote:
On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote:
On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote:
1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
a proper sg_table entries and call respecti
IOMMU/VT-d? Though I am not sure it will help in reducing the amount of
memory
required for the buffers.
3. Also, have you checked the cpu-usage while your experiment is going on?
Thanks
Salil.
-Original Message-
From: iommu [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of
MMU-400 is compatible as well.
Allow this combination as well to let the Arm Juno board pass the test.
Acked-by: Robin Murphy
Signed-off-by: Andre Przywara
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a
message more informative and less scary.
>
> Reported-by: Douglas Anderson
> Suggested-by: Robin Murphy
> Signed-off-by: Sai Prakash Ranjan
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Douglas Anderson
Is this pa
On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
Hi Will, Robin
On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
Add stall implementation hook to enable stalling
faults on QCOM platforms which supports it without
causing any kind of hardware mishaps. Without this
on QCOM platforms, GPU faults ca
On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even if there is free iova space available in the nodes
which are next to the cac
On 2020-05-04 7:37 pm, Ajay Kumar wrote:
The current IOVA allocation code stores a cached copy of the
first allocated IOVA address node, and all the subsequent allocations
have no way to get past(higher than) the first allocated IOVA range.
Strictly they do, after that first allocation gets fre
501 - 600 of 3517 matches
Mail list logo
