: Robin Murphy
---
drivers/iommu/tegra-gart.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 37e708fdbb5a..29bafc6e82ae 100644
--- a/drivers/iommu/tegra-gart.c
+++ b/drivers/iommu/tegra-gart.c
@@ -334,12 +334,31
e the .device_group callback non-optional for drivers calling
iommu_group_get_for_dev() - the current callers all implement it anyway,
and it doesn't make sense for any future callers not to either.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 19 ---
1 file changed, 4
oup()
>> should at least maintain existing behaviour with respect to the API.
>>
>> Signed-off-by: Robin Murphy
>> ---
>> drivers/iommu/msm_iommu.c | 15 ++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/msm
On 24/07/17 18:16, Alex Williamson wrote:
> On Thu, 20 Jul 2017 12:17:12 +0100
> Robin Murphy wrote:
>
>> On 20/07/17 10:10, Will Deacon wrote:
>>> On Thu, Jul 20, 2017 at 09:32:00AM +0530, Anup Patel wrote:
>>>> On Wed, Jul 19, 2017 at 5:23 PM, Will Deacon
On 25/07/17 18:11, Lorenzo Pieralisi wrote:
> On Tue, Jul 25, 2017 at 12:17:31PM +0100, Shameer Kolothum wrote:
>> The helper function retrieves ITS address regions through IORT
>> device <-> ITS mappings and reserves it so that these regions
>> will not be translated by IOMMU and will be excluded
On 31/05/17 18:52, Robin Murphy wrote:
> When a PCI device has DMA quirks, we need to ensure that an upstream
> IOMMU knows about all possible aliases, since the presence of a DMA
> quirk does not preclude the device still also emitting transactions
> (e.g. MSIs) on its 'real
On 26/07/17 10:59, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> Replace custom code with generic helper to retrieve driver data.
>
> Signed-off-by: Honghui Zhang
> ---
> drivers/memory/mtk-smi.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> dif
On 27/07/17 10:13, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>> Sent: Wednesday, July 26, 2017 10:52 AM
>> To: Robin Murphy
>> Cc: Shameerali Kolothum Thodi; marc.zyng
On 10/10/18 11:29, Andrew Murray wrote:
Replace license text with SDPX header
Acked-by: Robin Murphy
Signed-off-by: Andrew Murray
---
drivers/iommu/arm-smmu-v3.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu
On 10/10/18 11:29, Andrew Murray wrote:
Simplify the code by removing an unnecessary wrapper function.
This was left behind by commit 2f657add07a8
("iommu/arm-smmu-v3: Specialise CMD_SYNC handling")
Oops, sorry about that ;)
Reviewed-by: Robin Murphy
Signed-off-by: And
p operation, since whatever we do here is transparent to
our caller and not bound by any segment-length restrictions on the list
itself.
Speaking of efficiency, there's really very little point in duplicating
the checks that iommu_map() is going to do anyway, so those get cleared
up in the process
On 08/10/18 09:02, Christoph Hellwig wrote:
This comments describes an aspect of the map_sg interface that isn't
even exploited by swiotlb.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/k
On 08/10/18 09:02, Christoph Hellwig wrote:
I agree there isn't really a good reason for external code to ever be
poking at this, despite it being helpful for arch code trying to hack
around awful coherency issues ;)
Reviewed-by: Robin Murphy
Signed-off-by: Christoph He
evelopment sometimes.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 26d3af52956f..69bf305ee5f8 100644
--- a/
ut have at least found the branch to boot-test OK:
Reviewed-by: Robin Murphy
- return swiotlb_dma_mapping_error(hwdev, addr);
+ return dma_direct_mapping_error(hwdev, addr);
return 0;
}
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma
On 08/10/18 09:02, Christoph Hellwig wrote:
Now that the generic swiotlb code supports non-coherent DMA we can switch
to it for arm64. For that we need to refactor the existing
alloc/free/mmap/pgprot helpers to be used as the architecture hooks,
and implement the standard arch_sync_dma_for_{devi
On 12/10/18 20:41, Bjorn Helgaas wrote:
s/iommu/IOMMU/ in subject
On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote:
Using the iommu-map binding, endpoints in a given PCI domain can be
managed by different IOMMUs. Some virtual machines may allow a subset of
endpoints to bypa
Hi Hanna,
On 15/10/18 13:00, han...@marvell.com wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit
to ARM SMMUv2 registers.
This patch split the writeq/readq to two accesses of writel/readl.
Note that separate writes/reads to 2 is not problem regards t
On 15/10/18 13:00, han...@marvell.com wrote:
From: Hanna Hawa
Add specific compatible string for Marvell usage due errata of
accessing 64bit registers of ARM SMMU, in AP806.
AP806 SOC use the generic ARM-MMU500, and there's no specific
implementation of Marvell, this compatible is used for err
On 15/10/18 09:36, Zhen Lei wrote:
ITS translation register map:
0x-0x003C Reserved
0x0040 GITS_TRANSLATER
0x0044-0xFFFC Reserved
The standard GITS_TRANSLATER register in ITS is only 4 bytes, but Hisilicon
expands the next 4 bytes to carry some IMPDEF information. That means, 8
On 15/10/18 18:21, Will Deacon wrote:
On Mon, Oct 15, 2018 at 04:36:16PM +0800, Zhen Lei wrote:
ITS translation register map:
0x-0x003C Reserved
0x0040 GITS_TRANSLATER
0x0044-0xFFFC Reserved
The standard GITS_TRANSLATER register in ITS is only 4 bytes, but Hisilicon
expands the
ly add an extra byteswap initially,
such that it then writes back the big-endian format directly.
Fixes: 37de98f8f1cf ("iommu/arm-smmu-v3: Use CMD_SYNC completion MSI")
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Now that both sync methods are more or less the same shape, we can save
some code and levels of indirection by rolling them up together again,
with just a couple of simple conditionals to discriminate the MSI and
queue-polling specifics.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3
al backoff,
and returns to its original implementation.
Signed-off-by: Robin Murphy
---
v5:
- Rework to incorporate the back-to-back sync elision.
- Refactor the generation count slightly to preemptively help with
the HiSilicon MSI workaround.
- Split the cleanup into a separate patch f
On 17/10/18 18:07, Will Deacon wrote:
On Tue, Oct 16, 2018 at 12:31:07PM +0100, Robin Murphy wrote:
When we insert the sync sequence number into the CMD_SYNC.MSIData field,
we do so in CPU-native byte order, before writing out the whole command
as explicitly little-endian dwords. Thus on big
ly add an extra byteswap initially,
such that it then writes back the big-endian format directly.
Fixes: 37de98f8f1cf ("iommu/arm-smmu-v3: Use CMD_SYNC completion MSI")
Signed-off-by: Robin Murphy
---
v2: Actually fix the right thing, and comment it.
drivers/iommu/arm-smmu-v3.c | 8 ++
On 17/10/18 16:14, Michael S. Tsirkin wrote:
On Mon, Oct 15, 2018 at 08:46:41PM +0100, Jean-philippe Brucker wrote:
[Replying with my personal address because we're having SMTP issues]
On 15/10/2018 11:52, Michael S. Tsirkin wrote:
On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
Hi John,
On 17/10/18 15:38, John Garry wrote:
On 17/10/2018 14:56, Robin Murphy wrote:
Now that both sync methods are more or less the same shape, we can save
some code and levels of indirection by rolling them up together again,
with just a couple of simple conditionals to discriminate the
On 18/10/18 11:55, John Garry wrote:
[...]
@@ -976,18 +1019,19 @@ static int __arm_smmu_cmdq_issue_sync(struct
arm_smmu_device *smmu)
{
u64 cmd[CMDQ_ENT_DWORDS];
unsigned long flags;
- bool wfe = !!(smmu->features & ARM_SMMU_FEAT_SEV);
struct arm_smmu_cmdq_ent ent = { .opcode
On 16/10/18 09:25, Hanna Hawa wrote:
Hi Robin,
On 10/15/2018 04:00 PM, Robin Murphy wrote:
Hi Hanna,
On 15/10/18 13:00, han...@marvell.com wrote:
From: Hanna Hawa
Due to erratum #582743, the Marvell Armada-AP806 can't access 64bit
to ARM SMMUv2 registers.
This patch split the writeq/
, though,
Reviewed-by: Robin Murphy
for_each_sg(sgl, sg, nelems, i)
- unmap_single(hwdev, sg->dma_address, sg_dma_len(sg), dir,
+ swiotlb_unmap_page(hwdev, sg->dma_address, sg_dma_len(sg), dir,
that led to excessive bouncing).
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 34 --
1 file changed, 12 insertions(+), 22 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 15335f3
d saves a couple of lines), but it's no biggie.
Reviewed-by: Robin Murphy
- return DIRECT_MAPPING_ERROR;
+ return dma_addr;
}
/*
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
allocation failed - the only thing this
will do is to eat up bounce buffers that would be more useful to serve
streaming mappings.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 6 +--
include/linux/swiotlb.h | 5 --
kernel/dma/swiotlb.c
On 22/10/2018 07:53, Tian, Kevin wrote:
From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
Sent: Saturday, October 20, 2018 2:12 AM
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1].
nmap short of duplicating the whole 3-line arch_sync_*() block,
which just makes for a different readability problem. As you mentioned
on patch #7, I guess this really is just one of those things which has
no nice solution, so cosmetics aside,
Reviewed-by: Robin Murphy
FWIW, below is my
is
now a complete misnomer.
Other than that, and the aforementioned fixing of arch_dma_free(), it
seems OK and has survived at least some light testing:
Reviewed-by: Robin Murphy
Thanks,
Robin.
{
- struct scatterlist *sg;
- int i;
-
- if (!is_device_dma_coher
Hi Eric,
On 2018-09-18 3:24 pm, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a range provided by the user.
This does not work in nested mode.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocate
On 2018-10-24 7:44 pm, Auger Eric wrote:
Hi Robin,
On 10/24/18 8:02 PM, Robin Murphy wrote:
Hi Eric,
On 2018-09-18 3:24 pm, Eric Auger wrote:
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a range provided by the user.
This does not work in nested mode.
If
On 2018-10-26 9:04 am, Christoph Hellwig wrote:
On Mon, Oct 22, 2018 at 06:11:04PM +0100, Robin Murphy wrote:
+if (!dev_is_dma_coherent(dev) &&
+ (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
Nit: other parts of the file are already using the "!(...)" style r
aligned by 8 bytes, so no problem is met now.
It's good to explicitly add a workaround. Let's enclose the "sync_count"
into a union and companion with a new member "padding" of type u64.
There is no functional change.
Reviewed-by: Robin Murphy
Signed-o
On 31/10/2018 20:03, Nicolin Chen wrote:
The addresses within a single page are always contiguous, so it's
not so necessary to allocate one single page from CMA area. Since
the CMA area has a limited predefined size of space, it might run
out of space in some heavy use case, where there might be
struct arm_v7s_io_pgtable *data)
Nit: it seems to work out a little cleaner if we pass the io_pgtable_cfg
to these helpers directly, rather than re-deriving it from data each time.
Otherwise, though,
Reviewed-by: Robin Murphy
> {
> + return paddr &am
@@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int
> lvl,
> else
> mask = ARM_V7S_LVL_MASK(lvl);
>
> - return pte & mask;
> + paddr = pte & mask;
> + if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
I don't think we nee
On 01/11/2018 18:04, Nicolin Chen wrote:
Hi Robin,
Thanks for the comments.
On Thu, Nov 01, 2018 at 02:07:55PM +, Robin Murphy wrote:
On 31/10/2018 20:03, Nicolin Chen wrote:
The addresses within a single page are always contiguous, so it's
not so necessary to allocate one single
On 01/11/2018 21:35, Nicolin Chen wrote:
The __GFP_ZERO will be passed down to the generic page allocation
routine which zeros everything page by page. This is safe to be a
generic way but not efficient for iommu allocation that organizes
contiguous pages using scatterlist.
So this changes drops
pe Brucker
Signed-off-by: Robin Murphy
---
Sorry about that... I guess I only have test setups that either have
dma-ranges or where a 32-bit bus mask goes unnoticed :(
The Octeon and SMMU issues sound like they're purely down to this, and
it's probably related to at least one of John&
On 05/11/2018 14:58, Christoph Hellwig wrote:
On Fri, Nov 02, 2018 at 04:36:13PM -0700, Nicolin Chen wrote:
What if the pages came from highmem? I know that doesn't happen on arm64
today, but the point of this code *is* to be generic, and other users will
arrive eventually.
Hmm, so it probably
On 02/11/2018 23:36, Nicolin Chen wrote:
On Fri, Nov 02, 2018 at 04:54:07PM +, Robin Murphy wrote:
On 01/11/2018 21:35, Nicolin Chen wrote:
The __GFP_ZERO will be passed down to the generic page allocation
routine which zeros everything page by page. This is safe to be a
generic way but
Hi Geert,
On 2018-11-06 7:44 pm, Geert Uytterhoeven wrote:
Hi Christoph et al,
On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
wrote:
Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
Parent: 7d21ee4c719f00896767ce19c4c01a56374c2ced
Refname:refs/heads/master
Web:
On 2018-11-07 12:08 pm, Richter, Robert wrote:
On 07.11.18 11:31:50, Robert Richter wrote:
On 06.11.18 11:54:15, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the
On 2018-11-07 8:03 am, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the firmware. However, it seems
iewed-by: Robin Murphy
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index c4114b92652eb0c9..a8b2c649c1d1f1b9 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/dr
On 2018-11-07 4:03 pm, Joerg Roedel wrote:
On Wed, Nov 07, 2018 at 04:50:40PM +0100, Geert Uytterhoeven wrote:
It only got triggered by the combination of commits 6c2fb2ea76361da9
("of/device: Set bus DMA mask as appropriate") and b4ebe6063204da58
("dma-direct: implement complete bus_dma_mask ha
On 2018-11-07 3:52 pm, Rob Herring wrote:
On Wed, Nov 07, 2018 at 12:56:49PM +, Robin Murphy wrote:
On 2018-11-07 8:03 am, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
pe Brucker
Tested-by: Aaro Koskinen
Tested-by: John Stultz
Tested-by: Geert Uytterhoeven
Tested-by: Robert Richter
Signed-off-by: Robin Murphy
---
v2: Add comment, collect tested-by tags
drivers/of/device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/
On 08/11/2018 07:31, Yong Wu wrote:
Hi Robin,
After the commit ad67f5a6545f ("arm64: replace ZONE_DMA with
ZONE_DMA32"), we don't have ZONE_DMA in aarch64, but
__arm_v7s_alloc_table[1] use the GFP_DMA to expect the physical address
of pagetable should be 32bit.
Right now we meet a issue that th
On 09/11/2018 08:46, Christoph Hellwig wrote:
[...]
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 1167ff0416cf..cfb422e17049 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -55,8 +55,6 @@
#include "amd_iommu_types.h"
#include "irq_remapping
On 09/11/2018 07:49, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 05:27:14PM -0800, John Stultz wrote:
But at that point if I just re-apply "swiotlb: use swiotlb_map_page in
swiotlb_map_sg_attrs", I reproduce the hangs.
Any suggestions for how to further debug what might be going wrong
woul
On 2018-11-15 11:50 am, Will Deacon wrote:
On Fri, Nov 09, 2018 at 08:52:38AM +0100, Christoph Hellwig wrote:
Can I get a quick review from the arm64 folks? I think it should
be fine there as it basically is a code move, but an additional pair
or two of eyes always helps to weed out bugs.
I r
On 19/11/2018 14:18, Ramon Fried wrote:
On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt
wrote:
On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote:
-* Because 32-bit DMA masks are so common we expect every architecture
-* to be able to satisfy them - either by not s
On 09/11/2018 16:37, Robin Murphy wrote:
On 09/11/2018 07:49, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 05:27:14PM -0800, John Stultz wrote:
But at that point if I just re-apply "swiotlb: use swiotlb_map_page in
swiotlb_map_sg_attrs", I reproduce the hangs.
Any suggestions
This is what I have so far, which at least resolves the most ovbious
problems. I still haven't got very far with the USB corruption issue
I see on Juno with -rc1, but I'm yet to confirm whether that's actually
attributable to the SWIOTLB changes or something else entirely.
Robin.
target.
Fixes: dff8d6c1ed58 ("swiotlb: remove the overflow buffer")]
Reported-by: John Stultz
Signed-off-by: Robin Murphy
---
include/linux/dma-direct.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index bd
Fixes: a4a4330db46a ("swiotlb: add support for non-coherent DMA")
Signed-off-by: Robin Murphy
---
kernel/dma/swiotlb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 5731daa09a32..045930e32c0e 100644
--- a/kerne
On 20/11/2018 13:42, John Garry wrote:
From: Ganapatrao Kulkarni
Change function __iommu_dma_alloc_pages() to allocate memory/pages
for DMA from respective device NUMA node.
Signed-off-by: Ganapatrao Kulkarni
[JPG: Modifed to use kvzalloc() and fixed indentation]
Signed-off-by: John Garry
-
On 20/11/2018 14:49, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 20, 2018 at 02:09:52PM +, Robin Murphy wrote:
With the overflow buffer removed, we no longer have a unique address
which is guaranteed not to be a valid DMA target to use as an error
token. The DIRECT_MAPPING_ERROR value of 0
Fixes: a4a4330db46a ("swiotlb: add support for non-coherent DMA")
Tested-by: John Stultz
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v2: Collect tags
kernel/dma/swiotlb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb
-likely-valid DMA target.
Fixes: dff8d6c1ed58 ("swiotlb: remove the overflow buffer")
Reported-by: John Stultz
Tested-by: John Stultz
Acked-by: Konrad Rzeszutek Wilk
Reviewed-by: Christoph Hellwig
Signed-off-by: Robin Murphy
---
v2: Add parentheses, tweak commit message, collect tags
/UAS territory).
No objection from me if Konrad wants to pick this up instead depending
on timing.
Robin.
Robin Murphy (2):
dma-direct: Make DIRECT_MAPPING_ERROR viable for SWIOTLB
swiotlb: Skip cache maintenance on map error
include/linux/dma-direct.h | 2 +-
kernel/dma/swiotlb.c | 3 ++-
On 21/11/2018 17:38, Christopher Lameter wrote:
On Wed, 21 Nov 2018, Will Deacon wrote:
+#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32
SLAB_CACHE_DMA32??? WTH is going on here? We are trying to get rid of
the dma slab array.
See the previous two patches in this series. If there's alread
On 2018-11-21 9:38 pm, Matthew Wilcox wrote:
On Wed, Nov 21, 2018 at 06:20:02PM +, Christopher Lameter wrote:
On Sun, 11 Nov 2018, Nicolas Boichat wrote:
This is a follow-up to the discussion in [1], to make sure that the page
tables allocated by iommu/io-pgtable-arm-v7s are contained with
On 22/11/2018 17:09, Linus Torvalds wrote:
On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
wrote:
I'm afraid that won't work very well - 32 bit platforms with 64-bit
addresses (LPAE) would have dma_addr_t as a 64-bit value, which
wouldn't fit into an unsigned long.
Good point. So we
On 15/11/2018 15:49, 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 | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git
Hi Will,
On 2018-11-23 6:27 pm, Will Deacon wrote:
Hi John,
On Tue, Nov 20, 2018 at 10:25:16AM +0100, Christoph Hellwig wrote:
On Mon, Nov 19, 2018 at 03:22:13PM -0800, John Stultz wrote:
+ sg->dma_address = dma_addr;
sg_dma_len(sg) = sg->length;
}
I
On 26/11/2018 06:44, Souptick Joarder wrote:
On Sat, Nov 24, 2018 at 3:04 AM Matthew Wilcox wrote:
On Fri, Nov 23, 2018 at 05:23:06PM +, Robin Murphy wrote:
On 15/11/2018 15:49, Souptick Joarder wrote:
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed
On 27/11/2018 07:37, Christoph Hellwig wrote:
On Thu, Nov 15, 2018 at 12:58:04PM -0800, Robin Murphy wrote:
On 2018-11-15 11:50 am, Will Deacon wrote:
On Fri, Nov 09, 2018 at 08:52:38AM +0100, Christoph Hellwig wrote:
Can I get a quick review from the arm64 folks? I think it should
be fine
ntly to remain backwards compatible with existing use cases.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Will Deacon
Cc: Joerg Roedel
Cc: Robin Murphy
Cc: Nate Watterson
Cc: linux-arm-ker...@lists.infradead.
currently to remain backwards compatible with existing use cases.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
With the title fixed up,
Acked
On 26/11/2018 22:31, Paul Gortmaker wrote:
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config IPMMU_VMSA
drivers/iommu/Kconfig:bool "Renesas VMSA-compatible IPMMU"
...meaning that it currently is not being built as a module by anyone.
Lets remov
On 28/11/2018 16:24, Stephen Boyd wrote:
Quoting Vivek Gautam (2018-11-27 02:11:41)
@@ -1966,6 +1970,23 @@ static const struct of_device_id arm_smmu_of_match[] = {
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
+static void arm_smmu_fill_clk_data(struct arm_smmu_device *smmu,
+
On 28/11/2018 15:24, Paul Gortmaker wrote:
[Re: [PATCH 8/9] iommu: arm-smmu: make it explicitly non-modular] On 28/11/2018
(Wed 12:42) Robin Murphy wrote:
Hi Paul,
On 26/11/2018 22:31, Paul Gortmaker wrote:
[...]
We add a moduleparam.h include since the file does actually declare
some
On 30/11/2018 08:42, Christoph Hellwig wrote:
On Thu, Nov 29, 2018 at 10:54:56PM -0500, Qian Cai wrote:
/* allow architectures to override this if absolutely required */
#ifndef PREALLOC_DMA_DEBUG_ENTRIES
+/* amount of DMA mappings on this driver is huge. */
+#ifdef HNS_ENET
+#define PREALLO
this case and fail the
entire allocation if so".
Again, the diff itself makes sense, so given an accurate commit message,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 12
1 file changed, 12 insertions(+)
diff --git a/kernel
pping of lowmem as it is about
highmem. Regardless, the diff looks OK to me.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 3 +++
kernel/dma/direct.c| 32 ++--
2 files changed, 25 insertions(+), 10 dele
_pool_virt_to_phys(atomic_pool, val);
+
+ *ret_page = phys_to_page(phys);
Looks like phys_to_page() isn't particularly portable, so we probably
want an explicit pfn_to_page(__phys_to_pfn(phys)) here. Otherwise, the
fundamental refactoring looks OK.
Reviewed-by: R
grammar
fixes in some places but not others,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
Acked-by: Laura Abbott
---
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/csky/Kconfig| 1 +
arch/xtensa/Kconfig | 1 +
kernel/dma/Kconfig | 4 ++
kernel/dma
hat typo in 3 months' time.
Otherwise,
Reviewed-by: Robin Murphy
+
/* create a coherent mapping */
ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
@@ -227,7 +231,10 @@ void *arch_dma_alloc(struct
On 05/11/2018 12:19, Christoph Hellwig wrote:
By using __dma_direct_alloc_pages we can deal entirely with struct page
instead of having to derive a kernel virtual address.
Simple enough :)
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/remap.c | 14
On 30/11/2018 17:54, Qian Cai wrote:
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
Hi Rob,
On 01/12/2018 16:53, Rob Clark wrote:
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#
allocation size.
Signed-off-by: Robin Murphy
---
Tagging this one as RFC since people might think it's silly.
kernel/dma/debug.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c
index 46cc075aec99..c4759dab0f8c 100
ed by moving printks around, and could be split out if
desired; I kept #4 separate as a possible nice-to-have depending on
what people think.
Robin.
Robin Murphy (4):
dma-debug: Use pr_fmt()
dma-debug: Refactor dma_debug_entry allocation
dma-debug: Dynamically expand the dma_debug_entry
Make prealloc_memory() 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() quite a bit.
Signed-off-by: Robin Murphy
---
kernel/dma/debug.c | 95
cases that the
preallocated entries are insufficient, which is arguably the least
surprising and most useful behaviour.
Signed-off-by: Robin Murphy
---
kernel/dma/debug.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/debug.c b/kernel/dm
Use pr_fmt() to generate the "DMA-API: " prefix consistently. This
results in it being added to a couple of pr_*() messages which were
missing it before, and for the err_printk() calls moves it to the actual
start of the message instead of somewhere in the middle.
Signed-off-by: Ro
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 dma_debug_entry pool of
65536 entries, with the result that merely probing such a
On 04/12/2018 11:01, Vivek Gautam wrote:
Qualcomm SoCs have an additional level of cache called as
System cache, aka. Last level cache (LLC). This cache sits right
before the DDR, and is tightly coupled with the memory controller.
The cache is available to all the clients present in the SoC syste
On 04/12/2018 14:17, Christoph Hellwig wrote:
On Tue, Dec 04, 2018 at 01:11:37PM +, Robin Murphy wrote:
In fact, having got this far in, what I'd quite like to do is to get rid of
dma_debug_resize_entries() such that we never need to free things at all,
since then we could allocate
On 04/12/2018 14:27, Christoph Hellwig wrote:
On Mon, Dec 03, 2018 at 05:28:07PM +, Robin Murphy wrote:
Make prealloc_memory() 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() quite a
301 - 400 of 3517 matches
Mail list logo
