On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/ar
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
On 2023-11-16 4:17 am, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote:
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obvi
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously far, far too much for a stable
fix, but then it's also not the refactoring we want for the future
either, si
On 2023-04-28 10:27, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*()
with Linux' regular I/O functions. Remove all ifdef cases for the
various architectures.
Most of the supported architectures use __raw_() I/O functions or treat
framebuffer memory
On 31/03/2023 3:00 pm, Arnd Bergmann wrote:
On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote:
On 2023-03-27 13:13, Arnd Bergmann wrote:
[ HELP NEEDED: can anyone confirm that it is a correct assumption
on arm that a cache-coherent device writing to a page always results
in it being
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use th
aring 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 "WT
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
On 27/11/2018 14:36, Eugeniy Paltsev wrote:
Hi,
While playing with perf tool on ARMv7 and ARCv2 processors and profiling the
same application I got interesting results. Even if we got pretty
similar total
execution time and instructions number the number of branches on ARC is about
three times m
f low-level dma-debug internals
*only* called by a couple of IOMMU drivers, but that can wait for
another day.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
lib/dma-debug.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 075253c
On 27/04/18 16:53, Christoph Hellwig wrote:
There is no arch specific code required for dma-debug, so there is no
need to opt into the support either.
Makes sense, and a purely negative diffstat is always pleasing :)
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
.../io
On 24/04/18 15:02, Christoph Hellwig wrote:
Just keep a single variable with a descriptive name instead of two
with confusing names.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
lib/dma-debug.c | 20
1 file changed, 4 insertions(+), 16 deletions
as a core_initcall, which for many
architectures means much earlier, and provides dma-debug functionality
earlier in the boot process. This should be safe as it only relies
on the memory allocator already being available.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm/m
Hi Christoph,
Nice cleanup! Looks good overall, just a couple of nits.
On 20/04/18 09:02, Christoph Hellwig wrote:
[...]
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 7f5cdc1e6b29..712a897174e4 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -41,6 +41,11 @@
#define HASH_FN_SHIFT
On 10/04/18 16:25, Laurent Dufour wrote:
Remove the additional define HAVE_PTE_SPECIAL and rely directly on
CONFIG_ARCH_HAS_PTE_SPECIAL.
There is no functional change introduced by this patch
Signed-off-by: Laurent Dufour
---
mm/memory.c | 23 ++-
1 file changed, 10 inse
On 09/03/18 14:02, Andrey Konovalov wrote:
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel (like the mm subsystem), the untagged_addr
macro should be defined for all archit
Hi Andrey,
On 09/03/18 14:01, Andrey Konovalov wrote:
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the ker
On 10/01/18 15:32, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 11:49:34AM +, Robin Murphy wrote:
+#ifdef CONFIG_ZONE_DMA
+ if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
+ return 0;
+#else
+ /*
+* Because 32-bit DMA masks are so common we expect ev
On 10/01/18 15:30, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 12:06:22PM +, Robin Murphy wrote:
On 10/01/18 08:00, Christoph Hellwig wrote:
To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA
On 10/01/18 15:26, Christoph Hellwig wrote:
On Wed, Jan 10, 2018 at 02:56:01PM +, Robin Murphy wrote:
I took a look at these, and it seems their phys_to_dma() usage is doing the
thing which we subsequently formalised as dma_map_resource(). I've had a
crack at a quick patch to updat
On 10/01/18 08:00, Christoph Hellwig wrote:
phys_to_dma, dma_to_phys and dma_capable are helpers published by
architecture code for use of swiotlb and xen-swiotlb only. Drivers are
not supposed to use these directly, but use the DMA API instead.
Move these to a new asm/dma-direct.h helper, incl
On 10/01/18 08:00, Christoph Hellwig wrote:
To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA-aware, right? Great, that's
what we want on arm64 too :)
Reviewed-by: Robin Murphy
Signed-o
On 10/01/18 08:00, Christoph Hellwig wrote:
[...]
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 9f28b2fa329e..88bcb1a8211d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -518,6 +518,13 @@ static inline void *dma_alloc_attrs(struct devi
hardware which
probably associates with host systems packing equivalently small amounts
of RAM.
Otherwise though,
Reviewed-by: Robin Murphy
Robin.
+#endif
+ return 1;
+}
+
static int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
r
On 10/01/18 08:00, Christoph Hellwig wrote:
The generic version now takes dma_pfn_offset into account, so there is no
more need for an architecture override.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm64/include/asm/dma-mapping.h | 9 -
1 file changed
On 10/01/18 08:00, Christoph Hellwig wrote:
This makes sure the generic version can be used with architectures /
devices that have a DMA offset in the direct mapping.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1
}
- if (dma_get_attr(DMA_ATTR_ALLOC_SINGLE_PAGES, attrs))
+ if (attrs & DMA_ATTR_ALLOC_SINGLE_PAGES)
alloc_sizes = min_size;
count = PAGE_ALIGN(size) >> PAGE_SHIFT;
[...]
These all look appropriate to me; thanks!
For arm64
29 matches
Mail list logo
