On 04/12/2018 14:29, Christoph Hellwig wrote:
+ for (retry_count = 0; ; retry_count++) {
+ spin_lock_irqsave(&free_entries_lock, flags);
+
+ if (num_free_entries > 0)
+ break;
spin_unlock_irqrestore(&free_entries_lock, flags);
Takin
difference though, so either way,
Reviewed-by: Robin Murphy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 04/12/2018 16:30, John Garry wrote:
On 04/12/2018 13:11, Robin Murphy wrote:
Hi John,
On 03/12/2018 18:23, John Garry wrote:
On 03/12/2018 17:28, Robin Murphy wrote:
Certain drivers such as large multi-queue network adapters can use
pools
of mapped DMA buffers larger than the default
On 05/12/2018 13:54, Christoph Hellwig wrote:
On Wed, Dec 05, 2018 at 01:48:28PM +0800, Nicolas Boichat wrote:
IOMMUs using ARMv7 short-descriptor format require page tables
(level 1 and 2) to be allocated within the first 4GB of RAM, even
on 64-bit systems.
+#ifdef CONFIG_ZONE_DMA32
+#define
/usb/host/xhci.c | 2 +-
include/linux/device.h | 10 ++
6 files changed, 17 insertions(+), 7 deletions(-)
There looks to be one more here:
drivers/dma/sh/rcar-dmac.c: rcar_dmac_probe()
Other than that and a minor comment on the OF/IORT part, though, for the
whole series:
On 04/12/2018 17:25, Joerg Roedel wrote:
From: Joerg Roedel
Use Use device_iommu_mapped() to check if the device is
already mapped by an IOMMU.
FWIW, this check (and its ACPI equivalent in patch #3) is specifically
asking "has .add_device() already been called?", rather than the more
genera
On 04/12/2018 16:30, Joerg Roedel wrote:
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 7 +--
1
On 04/12/2018 16:29, Joerg Roedel wrote:
From: Joerg Roedel
Use the new helpers dev_iommu_fwspec_get()/set() to access
the dev->iommu_fwspec pointer. This makes it easier to move
that pointer later into another struct.
Cc: Lorenzo Pieralisi
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm6
On 05/12/2018 14:36, Joerg Roedel wrote:
From: Joerg Roedel
Put them into separate functions and call those where the
plain ops have been called before.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 54 ++-
include/linux/iommu.h | 3 +++
On 05/12/2018 14:36, Joerg Roedel wrote:
From: Joerg Roedel
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
---
drivers/iommu/of_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/of_i
ation behaviour more efficient in general.
Patches #1, #2 and #5 are some other cleanup and handy features which
fell out of the discussion/development.
Robin.
Robin Murphy (8):
dma-debug: Use pr_fmt()
dma-debug: Expose nr_total_entries in debugfs
dma-debug: Refactor dma_debug_entry a
Signed-off-by: Robin Murphy
---
v2: New
Documentation/DMA-API.txt | 3 +++
kernel/dma/debug.c| 7 +++
2 files changed, 10 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index ac66ae2509a9..6bdb095393b0 100644
--- a/Documentation/DMA-API.txt
+++ b
cases that the
preallocated entries are insufficient, which is arguably the least
surprising and most useful behaviour.
Signed-off-by: Robin Murphy
---
v2: Use GFP_ATOMIC, make retry loop redundant, update documentation
Documentation/DMA-API.txt | 11 +--
kernel/dma/debug.c| 15 +++
ph Hellwig
Signed-off-by: Robin Murphy
---
v2: Add Christoph's review tag
kernel/dma/debug.c | 74 --
1 file changed, 38 insertions(+), 36 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 231ca4628062..91b84140e4a5 100644
-
allocation size.
Signed-off-by: Robin Murphy
---
v2: Move the suggestion of a leak from the message to the documentation
Documentation/DMA-API.txt | 6 +-
kernel/dma/debug.c| 13 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/DMA-API.txt
it(),
we may as well tweak the preallocation behaviour so that as long as we
manage to allocate *some* pages, we can leave debugging enabled on a
best-effort basis rather than otherwise wasting them.
Signed-off-by: Robin Murphy
---
v2: New
Documentation/DMA-API.txt | 4 +++-
not.
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: x...@kernel.org
Signed-off-by: Robin Murphy
---
v2: New
Documentation/x86/x86_64/boot-options.txt | 5 +
arch/x86/kernel/amd_gart_64.c | 23 ---
2 files ch
Make the prealloc_memory() logic a little more general and robust so
that it serves for runtime reallocations too. The first thing we can
do with that is clean up dma_debug_resize_entries() a bit.
Signed-off-by: Robin Murphy
---
v2: Give it a better name, simplify the locking mess
kernel/dma
With no callers left, we can clean up this part of dma-debug's exposed
internals, making way to tweak the allocation behaviour.
Signed-off-by: Robin Murphy
---
v2: New
include/linux/dma-debug.h | 7 ---
kernel/dma/debug.c| 30 --
2 files change
On 06/12/2018 15:35, Joerg Roedel wrote:
Hi Robin,
On Wed, Dec 05, 2018 at 05:17:54PM +, Robin Murphy wrote:
FWIW, this check (and its ACPI equivalent in patch #3) is specifically
asking "has .add_device() already been called?", rather than the more
general "is this devic
On 06/12/2018 14:23, Christoph Hellwig wrote:
+static int dma_debug_add_entries(u32 num_entries, gfp_t gfp)
+{
+ struct dma_debug_entry *entry, *next_entry;
+ LIST_HEAD(tmp);
+ int i;
+
+ for (i = 0; i < num_entries; ++i) {
+ entry = kzalloc(sizeof(*entry), g
On 06/12/2018 14:24, Christoph Hellwig wrote:
@@ -47,6 +47,8 @@
#ifndef PREALLOC_DMA_DEBUG_ENTRIES
#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
#endif
FYI, I think we should drop the potential arch hook with the ifndef
here once we support the dynamic adjustment.
Sure - I have a vague f
On 06/12/2018 18:43, Christoph Hellwig wrote:
On Thu, Dec 06, 2018 at 10:28:22AM -0800, Linus Torvalds wrote:
which is counterproductive because it checks for the fast case *after*
you've done a load (and a check) that is entirely pointless for the
fast case.
Put another way, you made the fast
On 06/12/2018 20:00, Christoph Hellwig wrote:
On Thu, Dec 06, 2018 at 06:54:17PM +, Robin Murphy wrote:
I'm pretty sure we used to assign dummy_dma_ops explicitly to devices at
the point we detected the ACPI properties are wrong - that shouldn't be too
much of a headache to go bac
On 07/12/2018 05:49, Dongli Zhang wrote:
On 12/07/2018 12:12 AM, Joe Jin wrote:
Hi Dongli,
Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
I assume the call of swiotlb_tbl_map_single() might be frequent in some
situations, e.g., when 'swiotlb=force'.
That's why I declare
On 06/12/2018 18:43, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/iommu/dma-iommu.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git
On 06/12/2018 18:39, Souptick Joarder wrote:
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new functi
free up the dev->dma_ops == NULL case for some valuable
fastpath optimisations.
CC: Rafael J. Wysocki
CC: Len Brown
CC: Greg Kroah-Hartman
CC: Bjorn Helgaas
Signed-off-by: Robin Murphy
---
drivers/acpi/scan.c | 5 +
drivers/base/platform.c | 3 +--
drivers/pci/pci-driver.c | 3 +--
. In the process, we can prune all the optional
callbacks which just do the same thing as the default behaviour, and
fill in .map_resource for completeness.
CC: Catalin Marinas
CC: Will Deacon
Signed-off-by: Robin Murphy
---
arch/arm64/include/asm/dma-mapping.h | 4 +-
arch/arm64/mm/dma-mapping.c
.
[1] https://lore.kernel.org/lkml/20181206153720.10702-1-...@lst.de/
Robin Murphy (2):
dma-mapping: Factor out dummy DMA ops
ACPI / scan: Refactor _CCA enforcement
arch/arm64/include/asm/dma-mapping.h | 4 +-
arch/arm64/mm/dma-mapping.c | 92
drivers
On 07/12/2018 17:05, Christoph Hellwig wrote:
So I'd really prefer if we had a separate dummy.c file, like in
my take on your previous patch here:
http://git.infradead.org/users/hch/misc.git/commitdiff/e01adddc1733fa414dc16cd22e8f58be9b64a025
http://git.infradead.org/users/hch/misc.git/commitdi
On 2018-12-07 7:28 pm, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+ struct page **pages, unsigned long
improvement for running tcrypt with HiSilicon crypto engine.
We also include a modification to use kvzalloc() for kzalloc()/vzalloc()
combination.
[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1692998.html
Reviewed-by: Robin Murphy
Signed-off-by: Ganapatrao Kulkarni
[JPG: Added
ph Hellwig
Signed-off-by: Robin Murphy
---
v3: No change
kernel/dma/debug.c | 74 --
1 file changed, 38 insertions(+), 36 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 231ca4628062..91b84140e4a5 100644
--- a/kernel/dma/deb
behaviour more efficient in general.
Patches #1, #2 and #4 are some other cleanup and handy features which
fell out of the discussion/development.
Robin.
Robin Murphy (7):
dma-debug: Use pr_fmt()
dma-debug: Expose nr_total_entries in debugfs
dma-debug: Dynamically expand the dma_debug_entry p
Hellwig
Suggested-by: John Garry
Signed-off-by: Robin Murphy
---
v3: Add Christoph's review tag
Documentation/DMA-API.txt | 3 +++
kernel/dma/debug.c| 7 +++
2 files changed, 10 insertions(+)
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index ac66ae2
cases that the
preallocated entries are insufficient, which is arguably the least
surprising and most useful behaviour. To that end, refactor the
prealloc_memory() logic a little bit to generalise it for runtime
reallocations as well.
Signed-off-by: Robin Murphy
---
v3: Drop
not.
CC: Thomas Gleixner
CC: Ingo Molnar
CC: Borislav Petkov
CC: "H. Peter Anvin"
CC: x...@kernel.org
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v3: Add Christoph's review tag
Documentation/x86/x86_64/boot-options.txt | 5 +
arch/x
allocation size.
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v3: Add Christoph's review tag
Documentation/DMA-API.txt | 6 +-
kernel/dma/debug.c| 13 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/DMA-API.txt b/Docum
With the only caller now gone, we can clean up this part of dma-debug's
exposed internals and make way to tweak the allocation behaviour.
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v3: Add Christoph's review tag
include/linux/dma-debug.h | 7 --
kernel/d
on behaviour such that as long as we
manage to allocate *some* pages, we can leave debugging enabled on a
best-effort basis rather than otherwise wasting them.
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v3: Clean up #ifdef, misc. cosmetic tweaks, add Christoph's review t
On 07/12/2018 20:41, Souptick Joarder wrote:
On Fri, Dec 7, 2018 at 7:17 PM Robin Murphy wrote:
On 06/12/2018 18:43, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
On 08/12/2018 17:36, Christoph Hellwig wrote:
There is no need to have an additional kernel mapping for a contiguous
allocation if the device already is DMA coherent, so skip it.
FWIW, the "need" was that it kept the code in this path simple and the
mapping behaviour consistent with the regula
Hi Anders,
On 11/12/2018 10:36, Anders Roxell wrote:
When running a kernel in qemu with enough debugging options (slub-debug,
ftrace, kcov, kasan, ubsan, ...) enabled together, that results in a
slow initcall. So a 'watchdog: BUG: soft lockup' happens:
[ 44.105619] Call trace:
[ 44.106709]
On 12/12/2018 13:02, Yong Wu wrote:
If CONFIG_RANDOMIZE_BASE is enabled, the "memstart_addr" will be updated
randomly, then the PHYS_OFFSET may be random.
Oh, I hadn't ever realised that, good catch. However, since 29859aeb8a6e
I think we should probably just remove this check altogether.
F
expected. this PHYS_OFFSET check
is unnecessary now.
And this check may lead to fail. For example, If CONFIG_RANDOMIZE_BASE
is enabled, the "memstart_addr" will be updated randomly, then the
PHYS_OFFSET may be random.
Reviewed-by: Robin Murphy
Joerg, if you have any more fixes to send
On 2018-12-12 3:27 pm, Auger Eric wrote:
Hi,
On 12/12/18 3:56 PM, Michael S. Tsirkin wrote:
On Fri, Dec 07, 2018 at 06:52:31PM +, Jean-Philippe Brucker wrote:
Sorry for the delay, I wanted to do a little more performance analysis
before continuing.
On 27/11/2018 18:10, Michael S. Tsirkin
On 2018-12-18 8:34 pm, Guillaume Tucker wrote:
On 07/12/2018 19:07, Christoph Hellwig wrote:
Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: Christoph Hellwig
Sign
On 18/12/2018 18:48, Andrew Jones wrote:
The sum of dmaaddr and size may overflow, particularly considering
there are cases where size will be U64_MAX.
Only if the firmware is broken in the first place, though. It would be
weird to describe an explicit _DMA range of base=0 and size=U64_MAX,
b
On 18/12/2018 18:48, Andrew Jones wrote:
The sum of base and size may overflow, particularly considering there
are cases where size will be U64_MAX. Also, end_pfn is unused, so we
remove it. Finally, as size doesn't actually need to be IOMMU page
aligned we remove it from the comment stating both
Sorry, I'd somehow completely missed that you'd sent a proper patch for
this - indeed it looks like the right change to make.
Reviewed-by: Robin Murphy
Fixes: 356da6d0cd ("dma-mapping: bypass indirect calls for dma-direct")
Signed-off-by: Christoph Hellwig
Reported-by: Mar
Hi Krishna,
On 04/12/2018 01:36, Krishna Reddy wrote:
Add support to program multiple ARM SMMU's identically as one SMMU device.
Tegra194 uses Two ARM SMMU's as one SMMU device and both ARM SMMU's need
to be programmed identically.
The whole point of the library idea was to factor out the code
misbehaviour.
Reinstate the original logic, but without implicitly relying on ops
being set to infer !err as the initial condition (now that the validity
of ops for its own sake is checked elsewhere).
Fixes: 641fb0efbff0 ("iommu/of: Don't call iommu_ops->add_device directly")
Si
On 10/01/2019 10:44, Auger Eric wrote:
Hi Robin, Drew,
On 12/19/18 2:18 PM, Andrew Jones wrote:
On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
On 18/12/2018 18:48, Andrew Jones wrote:
The sum of dmaaddr and size may overflow, particularly considering
there are cases where size
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
knows as actual system/device memory" to better explain the WARN...
Either way, though,
Reviewed-by: Robin Murphy
- BUG_ON(pfn_valid(PHYS_PFN(phys_addr)));
+ if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr
+ return DMA_MAPPING_ERROR;
if (dma_is_direct(ops))
On 14/01/2019 16:09, Thierry Reding wrote:
On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
That patch broke IOMMU support for devices, which fails to probe for the
first time and use deferred probe approach. When no
On 14/01/2019 09:57, Christoph Hellwig wrote:
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC
On 14/01/2019 18:20, Michael S. Tsirkin wrote:
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
On 2019/1/14 下午5:50, Christoph Hellwig wrote:
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +08
On 16/01/2019 16:17, Laurentiu Tudor wrote:
This is an attempt to fix an iommu exception when doing dma to the
i2c controller with EDMA. Without these mappings the smmu raises a
context fault [1] exactly with the address of the i2c data i/o reg.
This was seen on an NXP LS1043A chip while working
On 16/01/2019 13:44, Corentin Labbe wrote:
While debugging a DMA mapping leak, I needed to access
debug_dma_dump_mappings() but easily from user space.
This patch adds a /sys/kernel/debug/dma-api/dump file which contain all
current DMA mapping.
Signed-off-by: Corentin Labbe
---
kernel/dma/de
On 15/01/2019 17:37, Pierre Morel wrote:
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the appropriate callback in iommu_ops.
The reserved region may la
On 17/01/2019 15:13, Dmitry Osipenko wrote:
16.01.2019 23:50, Navneet Kumar пишет:
* Allocate dma iova cookie for a domain while adding dma iommu
devices.
* Perform a stricter check for domain type parameter.
Commit message should tell what exactly is getting "fixed". Apparently you're
tryin
On 16/01/2019 20:50, Navneet Kumar wrote:
Add support for get/put reserved regions.
For any particular reason? If you're aiming to get
VFIO-passthrough-with-MSIs working on Tegra, this probably won't be
correct anyway...
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 31 +
On 18/01/2019 13:29, Pierre Morel wrote:
On 17/01/2019 14:02, Robin Murphy wrote:
On 15/01/2019 17:37, Pierre Morel wrote:
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_d
On 17/01/2019 09:27, Vivek Gautam wrote:
From Robin's comment [1] about touching TCR configurations -
"TBH if we're going to touch the TCR attributes at all then we should
probably correct that sloppiness first - there's an occasional argument
for using non-cacheable pagetables even on a cohere
On 21/01/2019 10:50, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 11:17, Vivek Gautam wrote:
Hi,
On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuvel
wrote:
On Mon, 21 Jan 2019 at 06:54, Vivek Gautam wrote:
Qualcomm SoCs have an additional level of cache called as
System cache, aka. Last le
On 21/01/2019 05:53, Vivek Gautam wrote:
A number of arm_smmu_domain's attributes can be assigned based
on the iommu domains's attributes. These local attributes better
be managed by a bitmap.
So remove boolean flags and move to a 32-bit bitmap, and enable
each bits separtely.
Signed-off-by: Viv
On 21/01/2019 13:36, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
On 21/01/2019 10:50, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 11:17, Vivek Gautam wrote:
Hi,
On Mon, Jan 21, 2019 at 12:56 PM Ard Biesheuvel
wrote:
On Mon, 21 Jan 2019 at 06:54, Vivek
: 1874619a7df4 "ARM: dma-mapping: Set proper DMA ops in
arm_iommu_detach_device()"
Tested-by: Tobias Jakobi
Signed-off-by: Robin Murphy
---
Sorry for the delay - there was a giant email infrastructure cock-up just
at the point I wanted to go back through my archive and double
On 21/01/2019 14:24, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote:
On 21/01/2019 13:36, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 14:25, Robin Murphy wrote:
On 21/01/2019 10:50, Ard Biesheuvel wrote:
On Mon, 21 Jan 2019 at 11:17, Vivek Gautam wrote:
Hi
debugfs entries
as they are never used at all once they are created.
Modulo one nit below, I certainly approve of the cleanup :)
Reviewed-by: Robin Murphy
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Greg Kroah-Hartman
On 25/01/2019 11:58, Andy Shevchenko wrote:
On Fri, Jan 25, 2019 at 3:50 AM Szabolcs Fruhwald wrote:
First of all, please do not top post!
I took a quick look at arch_setup_pdev_archdata(), overridden it in
dcdbas.c and it works well (despite it's being called twice, since
it's called from pl
On 08/01/2019 10:26, Eric Auger wrote:
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
arm_smmu_write_strtab_ent() is modified to write both stage
fields in the STE.
We add a nested_bypass field to the S1 configuration as th
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips wi
On 14/01/2019 09:41, Christoph Hellwig wrote:
Add a Kconfig symbol that indicates an architecture provides a
arch_dma_prep_coherent implementation, and provide a stub otherwise.
This will allow the generic dma-iommu code to it while still allowing
to be built for cache coherent architectures.
On 14/01/2019 09:41, Christoph Hellwig wrote:
No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
comment describing the #else cpp statement. Last but not least include
instead of the asm version, which is fro
On 14/01/2019 09:41, Christoph Hellwig wrote:
Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.
It also defeats the whole purpose of __iommu_dma_alloc_pages(), so I'm
not really buying the simplification angle - you've *seen* that code,
rig
On 14/01/2019 09:41, Christoph Hellwig wrote:
We now have a arch_dma_prep_coherent architecture hook that is used
for the generic DMA remap allocator, and we should use the same
interface for the dma-iommu code.
Agreed - I'd definitely ack a version of this change which didn't depend
on patch
On 31/01/2019 10:17, lantianyu1...@gmail.com wrote:
From: Lan Tianyu
On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already
On 14/01/2019 09:41, Christoph Hellwig wrote:
The current iommu_dma_mmap code does not properly handle memory from the
page allocator that hasn't been remapped, which can happen in the rare
case of allocations for a coherent device that aren't allowed to block.
Fix this by replacing iommu_dma_mm
On 05/02/2019 16:55, Christoph Hellwig wrote:
On Tue, Feb 05, 2019 at 10:37:31AM -0600, Rob Herring wrote:
Move io-pgtable.h to include/linux/ and export alloc_io_pgtable_ops
and free_io_pgtable_ops. This enables drivers outside drivers/iommu/ to
use the ARM page table library. Specifically, som
On 14/01/2019 09:41, Christoph Hellwig wrote:
For entirely dma coherent architectures there is no good reason to ever
remap dma coherent allocation.
Yes there is, namely assembling large buffers without the need for
massive CMA areas and compaction overhead under memory fragmentation.
That ha
On 14/01/2019 09:41, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Acked-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 13 +
include/linux/dma-iommu.h | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma
On 14/01/2019 09:41, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
Acked-by: Robin Murphy
---
arch/arm64/mm/dma-mapping.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index
On 01/02/2019 16:13, Christoph Hellwig wrote:
On Fri, Feb 01, 2019 at 02:47:17PM +, Robin Murphy wrote:
On 14/01/2019 09:41, Christoph Hellwig wrote:
No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
On 01/02/2019 16:16, Christoph Hellwig wrote:
On Fri, Feb 01, 2019 at 03:24:45PM +, Robin Murphy wrote:
On 14/01/2019 09:41, Christoph Hellwig wrote:
Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.
It also defeats the whole purpose
ld only be indicative of a separate bug being hidden by this one.
This fix looks entirely valid and correct to me:
Reviewed-by: Robin Murphy
---
Adding some debug code, and comparing before/after commit
e8e683ae9a736407:
sata_rcar ee30.sata: of_iommu_configure:227: err = -517
On 08/02/2019 16:40, Joerg Roedel wrote:
Hi Geert,
On Thu, Feb 07, 2019 at 08:36:53PM +0100, Geert Uytterhoeven wrote:
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8ac10af17c0043a3..d62487d024559620 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -968,9 +968,9 @@ static vo
On 08/02/2019 18:55, Geert Uytterhoeven wrote:
Hi Robin,
On Fri, Feb 8, 2019 at 6:55 PM Robin Murphy wrote:
On 08/02/2019 16:40, Joerg Roedel wrote:
On Thu, Feb 07, 2019 at 08:36:53PM +0100, Geert Uytterhoeven wrote:
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8ac10af17c0043a3
On 14/02/2019 16:09, John David Anglin wrote:
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.0.0-rc6+ (root@espressobin) (gcc version 6.3.0
20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP PREEMPT Wed Feb 13
16:17:46 EST 2019
[
On 14/02/2019 17:36, Christoph Hellwig wrote:
On Thu, Feb 14, 2019 at 05:27:41PM +, Robin Murphy wrote:
Oh wow, that driver has possibly the most inventive way of passing a NULL
device to the DMA API that I've ever seen, and on arm64 it will certainly
have been failing since 4.2, b
Hi Doug,
On 2019-02-14 8:44 pm, Douglas Anderson wrote:
Right now the only way to disable the iommu bypass for the ARM SMMU is
with the kernel command line parameter 'arm-smmu.disable_bypass'.
In general kernel command line parameters make sense for things that
someone would like to tweak witho
On 18/02/2019 14:37, Stanislaw Gruszka wrote:
[...]
Another issue is that dma_map_sg() & dma_map_page() may require some
constraints. I'm not sure about that and I want to clarify that with
CCed mm maintainers. I think DMA drivers may expect sg->offset < PAGE_SIZE
for both dma_map_sg() and dma_ma
Hi Geert,
On 20/02/2019 15:05, Geert Uytterhoeven wrote:
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and all
IPMMU state is lost. Hence after s2ram, devices wired behind an IPMMU,
and configured to use it, will see their DMA operations hang.
To fix this, restore all IPMMU con
ct
format. AFAICS from the mali_kbase driver, this must be "LPAE mode"
rather than "AArch64 mode", so it seems unlikely that it really supports
the full VMSAv8 gamut of granules, address sizes, and page sizes that
this patch will happily let through.
Robin.
Cc: Will Deaco
On 2019-02-26 8:23 pm, Nicolin Chen wrote:
This reverts commit d222e42e88168fd67e6d131984b86477af1fc256.
The original change breaks omap dss:
omapdss_dispc 58001000.dispc:
dispc_errata_i734_wa_init: dma_alloc_writecombine failed
Let's revert it first and then find a safer solution
On 2019-02-26 8:05 pm, Rob Herring wrote:
On Tue, Feb 26, 2019 at 1:25 PM Robin Murphy wrote:
Hi Rob,
On 26/02/2019 18:17, Rob Herring wrote:
ARM Mali midgard GPUs have a few differences from standard 64-bit
stage 1 page tables.
The 3rd level page entry bits are 0x1 instead of 0x3 for page
On 01/01/2019 04:51, Yong Wu wrote:
MediaTek IOMMU don't have its power-domain. all the consumer connect
with smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec
401 - 500 of 3517 matches
Mail list logo
