* [RFC PATCH v4 3/5] ARM: NOMMU: Introduce dma operations for noMMU
From: Vladimir Murzin @ 2017-01-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484057925-23586-1-git-send-email-vladimir.murzin@arm.com>
R/M classes of cpus can have memory covered by MPU which in turn might
configure RAM as Normal i.e. bufferable and cacheable. It breaks
dma_alloc_coherent() and friends, since data can stuck in caches now
or be buffered.
This patch factors out DMA support for NOMMU configuration into
separate entity which provides dedicated dma_ops. We have to handle
there several cases:
- configurations with MMU/MPU setup
- configurations without MMU/MPU setup
- special case for M-class, since caches and MPU there are optional
In general we rely on default DMA area for coherent allocations or/and
per-device memory reserves suitable for coherent DMA, so if such
regions are set coherent allocations go from there.
In case MPU/MPU was not setup we fallback to normal page allocator for
DMA memory allocation.
In case we run M-class cpus, for configuration without cache support
(like Cortex-M3/M4) dma operations are forced to be coherent and wired
with dma-noop (such decision is made based on cacheid global
variable); however, if caches are detected there and no DMA coherent
region is given (either default or per-device), dma is disallowed even
MPU is not set - it is because M-class implement system memory map
which defines part of address space as Normal memory.
Reported-by: Alexandre Torgue <alexandre.torgue@st.com>
Reported-by: Andras Szemzo <sza@esh.hu>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/include/asm/dma-mapping.h | 3 +-
arch/arm/mm/Makefile | 5 +-
arch/arm/mm/dma-mapping-nommu.c | 252 +++++++++++++++++++++++++++++++++++++
3 files changed, 256 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mm/dma-mapping-nommu.c
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bf02dbd..559faad 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -20,7 +20,8 @@ static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
{
if (dev && dev->archdata.dma_ops)
return dev->archdata.dma_ops;
- return &arm_dma_ops;
+
+ return IS_ENABLED(CONFIG_MMU) ? &arm_dma_ops : &dma_noop_ops;
}
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 2ac7988..5796357 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -2,9 +2,8 @@
# Makefile for the linux arm-specific parts of the memory manager.
#
-obj-y := dma-mapping.o extable.o fault.o init.o \
- iomap.o
-
+obj-y := extable.o fault.o init.o iomap.o
+obj-y += dma-mapping$(MMUEXT).o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
new file mode 100644
index 0000000..76f00c9
--- /dev/null
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -0,0 +1,252 @@
+/*
+ * Based on linux/arch/arm/mm/dma-mapping.c
+ *
+ * Copyright (C) 2000-2004 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/export.h>
+#include <linux/mm.h>
+#include <linux/dma-mapping.h>
+#include <linux/scatterlist.h>
+
+#include <asm/cachetype.h>
+#include <asm/cacheflush.h>
+#include <asm/outercache.h>
+#include <asm/cp15.h>
+
+#include "dma.h"
+
+/*
+ * dma_noop_ops is used if
+ * - MMU/MPU is off
+ * - cpu is v7m w/o cache support
+ * - device is coherent
+ * otherwise arm_nommu_dma_ops is used.
+ *
+ * arm_nommu_dma_ops rely on consistent DMA memory (please, refer to
+ * [1] on how to declare such memory).
+ *
+ * [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+ */
+
+static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp,
+ unsigned long attrs)
+
+{
+ struct dma_map_ops *ops = &dma_noop_ops;
+
+ /*
+ * We are here because:
+ * - no consistent DMA region has been defined, so we can't
+ * continue.
+ * - there is no space left in consistent DMA region, so we
+ * only can fallback to generic allocator if we are
+ * advertised that consistency is not required.
+ */
+
+ if (attrs & DMA_ATTR_NON_CONSISTENT)
+ return ops->alloc(dev, size, dma_handle, gfp, attrs);
+
+ WARN_ON_ONCE(1);
+ return NULL;
+}
+
+static void arm_nommu_dma_free(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_addr,
+ unsigned long attrs)
+{
+ struct dma_map_ops *ops = &dma_noop_ops;
+
+ if (attrs & DMA_ATTR_NON_CONSISTENT)
+ ops->free(dev, size, cpu_addr, dma_addr, attrs);
+
+ WARN_ON_ONCE(1);
+ return;
+}
+
+static int arm_nommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+ struct dma_map_ops *ops = &dma_noop_ops;
+ int ret;
+
+ if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
+ return ret;
+
+ if (attrs & DMA_ATTR_NON_CONSISTENT)
+ return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+
+ WARN_ON_ONCE(1);
+ return -ENXIO;
+}
+
+static void __dma_page_cpu_to_dev(phys_addr_t paddr, size_t size,
+ enum dma_data_direction dir)
+{
+ dmac_map_area(__va(paddr), size, dir);
+
+ if (dir == DMA_FROM_DEVICE)
+ outer_inv_range(paddr, paddr + size);
+ else
+ outer_clean_range(paddr, paddr + size);
+}
+
+static void __dma_page_dev_to_cpu(phys_addr_t paddr, size_t size,
+ enum dma_data_direction dir)
+{
+ if (dir != DMA_TO_DEVICE) {
+ outer_inv_range(paddr, paddr + size);
+ dmac_unmap_area(__va(paddr), size, dir);
+ }
+}
+
+static dma_addr_t arm_nommu_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ dma_addr_t handle = page_to_phys(page) + offset;
+
+ __dma_page_cpu_to_dev(handle, size, dir);
+
+ return handle;
+}
+
+static void arm_nommu_dma_unmap_page(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ __dma_page_dev_to_cpu(handle, size, dir);
+}
+
+
+static int arm_nommu_dma_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ int i;
+ struct scatterlist *sg;
+
+ for_each_sg(sgl, sg, nents, i) {
+ sg_dma_address(sg) = sg_phys(sg);
+ sg_dma_len(sg) = sg->length;
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+ }
+
+ return nents;
+}
+
+static void arm_nommu_dma_unmap_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_single_for_device(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_single_for_cpu(struct device *dev,
+ dma_addr_t handle, size_t size, enum dma_data_direction dir)
+{
+ __dma_page_cpu_to_dev(handle, size, dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_cpu_to_dev(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+static void arm_nommu_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir)
+{
+ struct scatterlist *sg;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ __dma_page_dev_to_cpu(sg_dma_address(sg), sg_dma_len(sg), dir);
+}
+
+struct dma_map_ops arm_nommu_dma_ops = {
+ .alloc = arm_nommu_dma_alloc,
+ .free = arm_nommu_dma_free,
+ .mmap = arm_nommu_dma_mmap,
+ .map_page = arm_nommu_dma_map_page,
+ .unmap_page = arm_nommu_dma_unmap_page,
+ .map_sg = arm_nommu_dma_map_sg,
+ .unmap_sg = arm_nommu_dma_unmap_sg,
+ .sync_single_for_device = arm_nommu_dma_sync_single_for_device,
+ .sync_single_for_cpu = arm_nommu_dma_sync_single_for_cpu,
+ .sync_sg_for_device = arm_nommu_dma_sync_sg_for_device,
+ .sync_sg_for_cpu = arm_nommu_dma_sync_sg_for_cpu,
+};
+EXPORT_SYMBOL(arm_nommu_dma_ops);
+
+static struct dma_map_ops *arm_nommu_get_dma_map_ops(bool coherent)
+{
+ return coherent ? &dma_noop_ops : &arm_nommu_dma_ops;
+}
+
+void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+ const struct iommu_ops *iommu, bool coherent)
+{
+ struct dma_map_ops *dma_ops;
+
+ if (IS_ENABLED(CONFIG_CPU_V7M)) {
+ /*
+ * Cache support for v7m is optional, so can be treated as
+ * coherent if no cache has been detected. Note that it is not
+ * enough to check if MPU is in use or not since in absense of
+ * MPU system memory map is used.
+ */
+ dev->archdata.dma_coherent = (cacheid) ? coherent : true;
+ } else {
+ /*
+ * Assume coherent DMA in case MMU/MPU has not been set up.
+ */
+ dev->archdata.dma_coherent = (get_cr() & CR_M) ? coherent : true;
+ }
+
+ dma_ops = arm_nommu_get_dma_map_ops(dev->archdata.dma_coherent);
+
+ set_dma_ops(dev, dma_ops);
+}
+
+void arch_teardown_dma_ops(struct device *dev)
+{
+}
+
+int dma_supported(struct device *dev, u64 mask)
+{
+ return 1;
+}
+
+EXPORT_SYMBOL(dma_supported);
+
+#define PREALLOC_DMA_DEBUG_ENTRIES 4096
+
+static int __init dma_debug_do_init(void)
+{
+ dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
+ return 0;
+}
+core_initcall(dma_debug_do_init);
--
2.0.0
^ permalink raw reply related
* [RFC PATCH v4 4/5] ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
From: Vladimir Murzin @ 2017-01-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484057925-23586-1-git-send-email-vladimir.murzin@arm.com>
Now, we have dedicated non-cacheable region for consistent DMA
operations. However, that region can still be marked as bufferable by
MPU, so it'd be safer to have barriers by default.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 0b79f12..64a1465c 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1029,7 +1029,7 @@ config ARM_L1_CACHE_SHIFT
config ARM_DMA_MEM_BUFFERABLE
bool "Use non-cacheable memory for DMA" if (CPU_V6 || CPU_V6K) && !CPU_V7
- default y if CPU_V6 || CPU_V6K || CPU_V7
+ default y if CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
help
Historically, the kernel has used strongly ordered mappings to
provide DMA coherent memory. With the advent of ARMv7, mapping
--
2.0.0
^ permalink raw reply related
* [RFC PATCH v4 5/5] ARM: dma-mapping: Remove traces of NOMMU code
From: Vladimir Murzin @ 2017-01-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484057925-23586-1-git-send-email-vladimir.murzin@arm.com>
DMA operations for NOMMU case have been just factored out into
separate compilation unit, so don't keep dead code.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm/mm/dma-mapping.c | 26 ++------------------------
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..d8a755b 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -344,8 +344,6 @@ static void __dma_free_buffer(struct page *page, size_t size)
}
}
-#ifdef CONFIG_MMU
-
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
const void *caller, bool want_vaddr,
@@ -646,22 +644,6 @@ static inline pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
return prot;
}
-#define nommu() 0
-
-#else /* !CONFIG_MMU */
-
-#define nommu() 1
-
-#define __get_dma_pgprot(attrs, prot) __pgprot(0)
-#define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv) NULL
-#define __alloc_from_pool(size, ret_page) NULL
-#define __alloc_from_contiguous(dev, size, prot, ret, c, wv, coherent_flag) NULL
-#define __free_from_pool(cpu_addr, size) do { } while (0)
-#define __free_from_contiguous(dev, page, cpu_addr, size, wv) do { } while (0)
-#define __dma_free_remap(cpu_addr, size) do { } while (0)
-
-#endif /* CONFIG_MMU */
-
static void *__alloc_simple_buffer(struct device *dev, size_t size, gfp_t gfp,
struct page **ret_page)
{
@@ -803,7 +785,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
if (cma)
buf->allocator = &cma_allocator;
- else if (nommu() || is_coherent)
+ else if (is_coherent)
buf->allocator = &simple_allocator;
else if (allowblock)
buf->allocator = &remap_allocator;
@@ -852,8 +834,7 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
- int ret = -ENXIO;
-#ifdef CONFIG_MMU
+ int ret;
unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = dma_to_pfn(dev, dma_addr);
@@ -868,7 +849,6 @@ static int __arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
-#endif /* CONFIG_MMU */
return ret;
}
@@ -887,9 +867,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
-#ifdef CONFIG_MMU
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
-#endif /* CONFIG_MMU */
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
--
2.0.0
^ permalink raw reply related
* [PATCH 2/3 v2] iio: adc: break out common code from SPMI VADC
From: jic23 at kernel.org @ 2017-01-10 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZUk6UUN2ACXp0S1RW7k2M5t5X5N_0mJQeo_UTEa4H=9w@mail.gmail.com>
On 10.01.2017 08:54, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 8:01 PM, Jonathan Cameron <jic23@kernel.org>
> wrote:
>> On 15/12/16 22:48, Linus Walleij wrote:
>>> The SPMI VADC and the earlier XOADC share a subset of
>>> common code, so to be able to use the same code in both
>>> drivers, we break out a separate file with the common code,
>>> prefix exported functions that are no longer static with
>>> qcom_* and bake an object qcom-vadc.o that contains both
>>> files: qcom-vadc-common.o and qcom-spmi-vadc.o.
>>>
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-arm-msm at vger.kernel.org
>>> Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
>>> Cc: Andy Gross <andy.gross@linaro.org>
>>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>>> Cc: Stephen Boyd <sboyd@codeaurora.org>
>>> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Looks superficially fine, but I'm guessing will need a respin
>> as we have a fair bit of new stuff (and a couple of fixes) going
>> through this driver at the moment.
>>
>> All but the two fixes I posted a few mins ago are in my testing
>> branch and should go to Greg once I have confirmed testing on
>> those two fixes.
>
> I looked at the git and "testing"
> contains a top commit named "guessing" fixing some 64bit
> artithmetic (which looks correct) in the driver, shall I simply
> rebase on top of that and hope for the best? :)
I'm an idiot and pushed out the wrong branch. Will fix up when
I get home and push one with a sensible patch title!
(It'll be the same content though - feel free to Ack that if
you like ;)
Not my best half asleep patch writing ;)
Jonathan
>
> Yours,
> Linus Walleij
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 7/9] arm64: cpufeature: Track user visible fields
From: Catalin Marinas @ 2017-01-10 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483982912-27215-8-git-send-email-suzuki.poulose@arm.com>
On Mon, Jan 09, 2017 at 05:28:30PM +0000, Suzuki K. Poulose wrote:
> Changes since V3:
> - Mark ID_AA64ISAR0_EL1:RDM visible
[...]
> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
As I said in an earlier reply, I'd like the RDM exposing to come
together with a patch presenting the corresponding HWCAP bit. But it's
fine by me if you add the HWCAP separately from this patch, in which
case my ack still stands.
--
Catalin
^ permalink raw reply
* [PATCH v4 7/9] arm64: cpufeature: Track user visible fields
From: Suzuki K Poulose @ 2017-01-10 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110142427.GA23051@e104818-lin.cambridge.arm.com>
On 10/01/17 14:24, Catalin Marinas wrote:
> On Mon, Jan 09, 2017 at 05:28:30PM +0000, Suzuki K. Poulose wrote:
>> Changes since V3:
>> - Mark ID_AA64ISAR0_EL1:RDM visible
> [...]
>> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
>> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
>
> As I said in an earlier reply, I'd like the RDM exposing to come
> together with a patch presenting the corresponding HWCAP bit. But it's
> fine by me if you add the HWCAP separately from this patch, in which
> case my ack still stands.
Catalin,
Yes, I have a separate patch for that.
Thanks
Suzuki
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Shuah Khan @ 2017-01-10 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e4a5e53-6603-13b8-0302-dc8093978013@osg.samsung.com>
On 01/10/2017 07:16 AM, Shuah Khan wrote:
> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>> error path only when susp_clk has been set from remove and probe error
>>> paths.
>>
>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>> for NULL clock. Also your patch changes susp_clk handling while
>> leaves axius_clk handling (which also can be NULL) untouched.
>>
>> Do you actually see some runtime problem with the current code?
>>
>> If not then the patch should probably be dropped.
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R&D Institute Poland
>> Samsung Electronics
>
> Hi Bartlomiej,
>
> I am seeing the "no suspend clk specified" message in dmesg.
> After that it sets the exynos->susp_clk = NULL and starts
> calling clk_prepare_enable(exynos->susp_clk);
>
> That can't be good. If you see the logic right above this
> one for exynos->clk, it returns error and fails the probe.
> This this case it doesn't, but tries to use null susp_clk.
>
> I believe this patch is necessary.
Let me clarify this a bit further. Since we already know
susp_clk is null, with this patch we can avoid extra calls
to clk_prepare_enable() and clk_disable_unprepare().
One can say, it also adds extra checks, hence I will let you
decide one way or the other. :)
thanks,
-- Shuah
>
> thanks,
> -- Shuah
>
>>
>>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>>> ---
>>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>>> index e27899b..f97a3d7 100644
>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>> if (IS_ERR(exynos->susp_clk)) {
>>> dev_info(dev, "no suspend clk specified\n");
>>> exynos->susp_clk = NULL;
>>> - }
>>> - clk_prepare_enable(exynos->susp_clk);
>>> + } else
>>> + clk_prepare_enable(exynos->susp_clk);
>>>
>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>>> regulator_disable(exynos->vdd33);
>>> err2:
>>> clk_disable_unprepare(exynos->axius_clk);
>>> - clk_disable_unprepare(exynos->susp_clk);
>>> + if (exynos->susp_clk)
>>> + clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>> return ret;
>>> }
>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
>>> platform_device_unregister(exynos->usb3_phy);
>>>
>>> clk_disable_unprepare(exynos->axius_clk);
>>> - clk_disable_unprepare(exynos->susp_clk);
>>> + if (exynos->susp_clk)
>>> + clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>>
>>> regulator_disable(exynos->vdd33);
>>
>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Shuah Khan @ 2017-01-10 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82fb5295-6640-7e9e-a42a-4067aa88e5b4@cogentembedded.com>
On 01/10/2017 04:20 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 01/10/2017 05:21 AM, Shuah Khan wrote:
>
>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>> clock is specified. Call clk_disable_unprepare() from remove and probe
>> error path only when susp_clk has been set from remove and probe error
>> paths.
>>
>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> ---
>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index e27899b..f97a3d7 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>> if (IS_ERR(exynos->susp_clk)) {
>> dev_info(dev, "no suspend clk specified\n");
>> exynos->susp_clk = NULL;
>> - }
>> - clk_prepare_enable(exynos->susp_clk);
>> + } else
>> + clk_prepare_enable(exynos->susp_clk);
>
> CodingStyle: need {} here as well since another branch has them.
>
> [...]
>
> MBR, Sergei
>
Thanks. There is some concerns whether or not this patch is needed.
If we decide to include the patch, I will send v2 with your comment.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Christoph Hellwig @ 2017-01-10 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1988852.3nyUoruEjG@wuerfel>
On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote:
> I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of
> 32-bit architectures without swiotlb (arc, arm, some mips32), and
> there are several 64-bit architectures that do not have swiotlb
> (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc
> always use some form of IOMMU, but the other four apparently don't,
> so we would need to add swiotlb support there to remove all the
> bounce buffering in network and block layers.
mips has lots of weird swiotlb wire-up in it's board code (the swiotlb
arch glue really needs some major cleanup..), as does arm. Not
sure about the others.
Getting rid of highmem bouncing in the block layer will take some time
as various PIO-only drivers rely on it at the moment. These should
all be convertable to kmap that data, but it needs a careful audit
first. For 4.11 I'll plan to switch away from bouncing highmem by
default at least, though and maybe also convert a few PIO drivers.
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Christoph Hellwig @ 2017-01-10 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4137257.d2v87kqLLv@wuerfel>
On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> Another workaround me might need is to limit amount of concurrent DMA
> in the NVMe driver based on some platform quirk. The way that NVMe works,
> it can have very large amounts of data that is concurrently mapped into
> the device.
That's not really just NVMe - other storage and network controllers also
can DMA map giant amounts of memory. There are a couple aspects to it:
- dma coherent memoery - right now NVMe doesn't use too much of it,
but upcoming low-end NVMe controllers will soon start to require
fairl large amounts of it for the host memory buffer feature that
allows for DRAM-less controller designs. As an interesting quirk
that is memory only used by the PCIe devices, and never accessed
by the Linux host at all.
- size vs number of the dynamic mapping. We probably want the dma_ops
specify a maximum mapping size for a given device. As long as we
can make progress with a few mappings swiotlb / the iommu can just
fail mapping and the driver will propagate that to the block layer
that throttles I/O.
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07253eaa-5729-0f15-42b6-e8403f1f0412@cogentembedded.com>
On Tue, Jan 10, 2017 at 03:47:25PM +0300, Nikita Yushchenko wrote:
> With this direction, semantics of dma mask becomes even more
> questionable. I'd say dma_mask is candidate for removal (or to move to
> swiotlb's or iommu's local area)
We need the dma mask so that the device can advertise what addresses
the device supports. Many old devices only support 32-bit DMA addressing,
and some less common ones just 24-bit or other weird ones.
^ permalink raw reply
* [PATCH] ARM: imx: hide unused variable in #ifdef
From: Frank Li @ 2017-01-10 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110130154.2994705-1-arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, January 10, 2017 6:19 AM
> To: Shawn Guo <shawnguo@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>; Arnd Bergmann
> <arnd@arndb.de>; Sascha Hauer <kernel@pengutronix.de>; Fabio Estevam
> <fabio.estevam@nxp.com>; Russell King <linux@armlinux.org.uk>; Frank Li
> <frank.li@nxp.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [PATCH] ARM: imx: hide unused variable in #ifdef
>
> A bugfix added a new local variable that is only used inside of an #ifdef
> section, and unused if CONFIG_PERF_EVENTS is disabled:
>
> arch/arm/mach-imx/mmdc.c:63:25: warning: 'cpuhp_mmdc_state' defined
> but not used [-Wunused-variable]
>
> This moves the variable down inside that same ifdef.
>
> Fixes: a051f220d6b9 ("ARM/imx/mmcd: Fix broken cpu hotplug handling")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Frank Li <Frank.Li@nxp.com>
> arch/arm/mach-imx/mmdc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
> index 699157759120..c03bf28d8bbc 100644
> --- a/arch/arm/mach-imx/mmdc.c
> +++ b/arch/arm/mach-imx/mmdc.c
> @@ -60,7 +60,6 @@
>
> #define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>
> -static enum cpuhp_state cpuhp_mmdc_state; static int ddr_type;
>
> struct fsl_mmdc_devtype_data {
> @@ -82,6 +81,7 @@ static const struct of_device_id imx_mmdc_dt_ids[] = {
>
> #ifdef CONFIG_PERF_EVENTS
>
> +static enum cpuhp_state cpuhp_mmdc_state;
> static DEFINE_IDA(mmdc_ida);
>
> PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles,
> "event=0x00")
> --
> 2.9.0
^ permalink raw reply
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices
From: Andy Gross @ 2017-01-10 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110095521.14146-1-linus.walleij@linaro.org>
On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote:
> This default-enables the devices found on the APQ8060 DragonBoard
> in the qcom_defconfig:
>
> - EBI2 bus
> - SMSC911x ethernet
> - LEDs class and PM8058 LEDs driver, trigger and heartbeat
> trigger (so we get heartbeat on the board by default)
> - IIO framework, including the HRTimer trigger, KXSD9
> accelerometer, MPU3050 gyroscope, AK8975 magnetometer and
> BMP085 pressure sensor
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This brings up a point of discussion. Do we even need the qcom_defconfig any
more? Is everyone comfortable with using the multi_v7_defconfig?
Aside from size of the image, i can't think of any other reason to keep around
the separate qcom file.
Regards,
Andy
^ permalink raw reply
* [PATCH] virtio_mmio: Set DMA masks appropriately
From: Michael S. Tsirkin @ 2017-01-10 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50defbbe87d75db85a9d22f914258975d661208a.1484051089.git.robin.murphy@arm.com>
On Tue, Jan 10, 2017 at 12:26:01PM +0000, Robin Murphy wrote:
> Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
> inadvertently relying on the default 32-bit DMA mask, which leads to
> problems like rapidly exhausting SWIOTLB bounce buffers.
>
> Ensure that we set the appropriate 64-bit DMA mask whenever possible,
> with the coherent mask suitably limited for the legacy vring as per
> a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
> devices").
>
> Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
> Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/virtio/virtio_mmio.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 48bfea91dbca..b5c5d49ca598 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -59,6 +59,7 @@
> #define pr_fmt(fmt) "virtio-mmio: " fmt
>
> #include <linux/acpi.h>
> +#include <linux/dma-mapping.h>
> #include <linux/highmem.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -497,6 +498,7 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> struct virtio_mmio_device *vm_dev;
> struct resource *mem;
> unsigned long magic;
> + int rc;
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!mem)
> @@ -548,6 +550,14 @@ static int virtio_mmio_probe(struct platform_device *pdev)
> if (vm_dev->version == 1)
> writel(PAGE_SIZE, vm_dev->base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
>
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> + if (rc)
> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + else if (vm_dev->version == 1)
> + dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32 + PAGE_SHIFT));
That's a very convoluted way to do this, for version 1 you
set coherent mask to 64 then override it.
why not
if (vm_dev->version == 1) {
dma_set_mask
dma_set_coherent_mask
} else {
dma_set_mask_and_coherent
}
if (rc)
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> + if (rc)
> + dev_warn(&pdev->dev, "Failed to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n");
> +
is there a chance it actually still might work?
> platform_set_drvdata(pdev, vm_dev);
>
> return register_virtio_device(&vm_dev->vdev);
> --
> 2.10.2.dirty
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11daacde-5399-039f-80a3-01d7bd13e9e8@arm.com>
On Tue, Jan 10, 2017 at 01:25:12PM +0000, Robin Murphy wrote:
> We still need a way for drivers to communicate a device's probed
> addressing capability to SWIOTLB, so there's always going to have to be
> *some* sort of public interface. Personally, the change in semantics I'd
> like to see is to make dma_set_mask() only fail if DMA is entirely
> disallowed - in the normal case it would always succeed, but the DMA API
> implementation would be permitted to set a smaller mask than requested
> (this is effectively what the x86 IOMMU ops do already).
Yes, this sounds reasonable.
> The significant
> work that would require, though, is changing all the drivers currently
> using this sort of pattern:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* put device into 64-bit mode */
> else if (!dma_set_mask(dev, DMA_BIT_MASK(32))
> /* put device into 32-bit mode */
> else
> /* error */
While we have this pattern in a lot of places it's already rather
pointless on most architectures as the first dma_set_mask call
won't ever fail for the most common dma_ops implementations.
> to something like this:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* error */
> if (dma_get_mask(dev) > DMA_BIT_MASK(32))
> /* put device into 64-bit mode */
> else
> /* put device into 32-bit mode */
>
> Which would be a pretty major job.
I don't think it's too bad. Also for many modern devices there is no
need to put the device into a specific mode. It's mostly a historic
issue from the PCI/PCI-X days with the less efficient DAC addressing
scheme.
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-10 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <237ca4dc-07ce-0104-27f2-5437b7c7718e@linaro.org>
On Tue, Jan 10, 2017 at 09:39:39PM +0800, Hanjun Guo wrote:
[...]
> >What you can do is create a wrapper, say iort_node_map_platform_id()
> >(whose signature is equivalent to iort_node_map_rid() minus rid_in)
> >that carries out the two steps outlined above.
> >
> >To do that I suggest the following:
> >
> >(1) I send a patch to "fix" iort_node_get_id() (ie index issue you
> > reported)
>
> I prepared two simple patches, one is for fix the indentation and
> the other is adding the missing kernel-doc comment, how about
> sending the out for 4.10-rcx?
For me it is fine depending on how Rafael wants to handle them,
ie if he can batch those with the eg iort_node_get_id() fix I have
just sent:
https://patchwork.kernel.org/patch/9507041/
> >(2) We remove type_mask handling from iort_node_get_id()
>
> iort_node_get_id() for now only supports id single mappings,
> Do we need to extend it for multi id mappings? seems Sinan's
> platform have such cases.
I am not really sure I understand what you mean here.
> >(3) We create iort_node_map_platform_id() that (pseudo-code, I can
> > write the patch if it is clearer):
> >
> >struct acpi_iort_node *iort_node_map_platform_id(u8 type_mask, int index,
> > ...)
> >{
> > u32 id, id_out;
> > struct acpi_iort_node *parent = iort_node_get_id(&id, index);
> >
> > if (!parent)
> > return NULL;
> >
> > /* we should probably rename iort_node_map_rid() too */
> > if (!(IORT_TYPE_MASK(parent->type) & type_mask)
> > parent = iort_node_map_rid(parent, id, &id_out, type_mask);
> >
> > return parent;
> >}
> >
> >(4) we update current iort_node_get_id() users and move them over
> > to iort_node_map_platform_id()
>
> I think we need to prepare one patch for the above steps, or it
> have functional changes for iort_node_get_id(), for example we
> removed the type_mask handling from iort_node_get_id() and it
> will break the case for SMMU if we only have requester id entries.
If the question is "should we apply this change as a single logical
patch" the answer is yes, it looks a simple one to me (basically
it implies writing the function above and update the iort_node_get_id()
existing callers with it). Does this answer your question ?
Thanks !
Lorenzo
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Christoph Hellwig @ 2017-01-10 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6116278.nQQUSuo3l4@wuerfel>
On Tue, Jan 10, 2017 at 02:42:23PM +0100, Arnd Bergmann wrote:
> It's a much rarer problem for the IOMMU case though, because it only
> impacts devices that are restricted to addressing of less than 32-bits.
>
> If you have an IOMMU enabled, the dma-mapping interface does not care
> if the device can do wider than 32 bit addressing, as it will never
> hand out IOVAs above 0xffffffff.
That's absolutely not the case. IOMMUs can and do generate addresses
larger than 32-bit. Also various platforms have modes where an IOMMU
can be used when <= 32-bit addresses are used and bypassed if full 64-bit
addressing is supported and I/O isolation is not explicitly requested.
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-10 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110144453.GA27156@lst.de>
On Tuesday, January 10, 2017 3:44:53 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 11:47:42AM +0100, Arnd Bergmann wrote:
> > I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of
> > 32-bit architectures without swiotlb (arc, arm, some mips32), and
> > there are several 64-bit architectures that do not have swiotlb
> > (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc
> > always use some form of IOMMU, but the other four apparently don't,
> > so we would need to add swiotlb support there to remove all the
> > bounce buffering in network and block layers.
>
> mips has lots of weird swiotlb wire-up in it's board code (the swiotlb
> arch glue really needs some major cleanup..),
My reading of the MIPS code was that only the 64-bit platforms use it,
but there are a number of 32-bit platforms that have 64-bit physical
addresses and don't.
> as does arm. Not sure about the others.
32-bit ARM doesn't actually use SWIOTLB at all, despite selecting it
in Kconfig. I think Xen uses it for its own purposes, but nothing
else does.
Most ARM platforms can't actually have RAM beyond 4GB, and the ones
that do have it tend to also come with an IOMMU, but I remember
at least BCM53xx actually needing swiotlb on some chip revisions
that are widely used and that cannot DMA to the second memory bank
from PCI (!).
Arnd
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-10 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110144839.GB27156@lst.de>
On Tuesday, January 10, 2017 3:48:39 PM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:01:05PM +0100, Arnd Bergmann wrote:
> > Another workaround me might need is to limit amount of concurrent DMA
> > in the NVMe driver based on some platform quirk. The way that NVMe works,
> > it can have very large amounts of data that is concurrently mapped into
> > the device.
>
> That's not really just NVMe - other storage and network controllers also
> can DMA map giant amounts of memory. There are a couple aspects to it:
>
> - dma coherent memoery - right now NVMe doesn't use too much of it,
> but upcoming low-end NVMe controllers will soon start to require
> fairl large amounts of it for the host memory buffer feature that
> allows for DRAM-less controller designs. As an interesting quirk
> that is memory only used by the PCIe devices, and never accessed
> by the Linux host at all.
Right, that is going to become interesting, as some platforms are
very limited with their coherent allocations.
> - size vs number of the dynamic mapping. We probably want the dma_ops
> specify a maximum mapping size for a given device. As long as we
> can make progress with a few mappings swiotlb / the iommu can just
> fail mapping and the driver will propagate that to the block layer
> that throttles I/O.
Good idea.
Arnd
^ permalink raw reply
* [PATCH v2] arm64: do not set dma masks that device connection can't handle
From: Arnd Bergmann @ 2017-01-10 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5c5cd4fd-4854-a2dd-10b6-9cc98e63a85c@arm.com>
On Tuesday, January 10, 2017 2:16:57 PM CET Robin Murphy wrote:
> On 10/01/17 13:42, Arnd Bergmann wrote:
> > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote:
> >> On 10/01/17 12:47, Nikita Yushchenko wrote:
> >>>> The point here is that an IOMMU doesn't solve your issue, and the
> >>>> IOMMU-backed DMA ops need the same treatment. In light of that, it really
> >>>> feels to me like the DMA masks should be restricted in of_dma_configure
> >>>> so that the parent mask is taken into account there, rather than hook
> >>>> into each set of DMA ops to intercept set_dma_mask. We'd still need to
> >>>> do something to stop dma_set_mask widening the mask if it was restricted
> >>>> by of_dma_configure, but I think Robin (cc'd) was playing with that.
> >>>
> >>> What issue "IOMMU doesn't solve"?
> >>>
> >>> Issue I'm trying to address is - inconsistency within swiotlb
> >>> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then
> >>> mask is used to decide if bounce buffers are needed or not. This
> >>> inconsistency causes NVMe+R-Car cobmo not working (and breaking memory
> >>> instead).
> >>
> >> The fundamental underlying problem is the "any wide mask is silently
> >> accepted" part, and that applies equally to IOMMU ops as well.
> >
> > It's a much rarer problem for the IOMMU case though, because it only
> > impacts devices that are restricted to addressing of less than 32-bits.
> >
> > If you have an IOMMU enabled, the dma-mapping interface does not care
> > if the device can do wider than 32 bit addressing, as it will never
> > hand out IOVAs above 0xffffffff.
>
> I can assure you that it will - we constrain allocations to the
> intersection of the IOMMU domain aperture (normally the IOMMU's physical
> input address width) and the given device's DMA mask. If both of those
> are >32 bits then >32-bit IOVAs will fall out. For the arm64/common
> implementation I have prototyped a copy of the x86 optimisation which
> always first tries to get 32-bit IOVAs for PCI devices, but even then it
> can start returning higher addresses if the 32-bit space fills up.
Ok, got it. I have to admit that most of my knowledge about the internals
of IOMMUs is from PowerPC of a few years ago, which couldn't do this at
all. I agree that we need to do the same thing on swiotlb and iommu then.
> >> The thread Will linked to describes that equivalent version of your
> >> problem - the IOMMU gives the device 48-bit addresses which get
> >> erroneously truncated because it doesn't know that only 42 bits are
> >> actually wired up. That situation still requires the device's DMA mask
> >> to correctly describe its addressing capability just as yours does.
> >
> > That problem should only impact virtual machines which have a guest
> > bus address space covering more than 42 bits of physical RAM, whereas
> > the problem we have with swiotlb is for the dma-mapping interface.
> >
> I actually have a third variation of this problem involving a PCI root
> complex which *could* drive full-width (40-bit) addresses, but won't,
> due to the way its PCI<->AXI interface is programmed. That would require
> even more complicated dma-ranges handling to describe the windows of
> valid physical addresses which it *will* pass, so I'm not pressing the
> issue - let's just get the basic DMA mask case fixed first.
Can you describe this a little more? We should at least try to not
make it harder to solve the next problem while solving this one,
so I'd like to understand the exact limitation you are hitting there.
Arnd
^ permalink raw reply
* [PATCH v6 0/2] Support for Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484054314-6244-1-git-send-email-peda@axentia.se>
On 10/01/2017 at 14:18:32 +0100, Peter Rosin wrote :
> Hi!
>
> changes v5 -> v6
> - drop the &main clock-frequency
> - add some text to the commit messages
> - make config additions modules
>
> changes v4 -> v5
> - comment from Rob about the memory node made me look closer and
> the memory size is actually updated by the bootloader, and that
> hid the fact that the entry was always faulty. This version
> specifies the correct memory size from the start, which is 64MB.
> - ack from Rob
>
> changes v3 -> v4
> - rename files arch/arm/boot/dts/axentia-* to .../at91-*
> - remove bootargs from at91-tse850-3.dts
> - depend on the atmel ssc to register as a sound dai by itself
> - bump copyright years
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed I would
> like to have the dts and the defconfig also upstreamed.
>
> The atmel-ssc/sound-dai change depends on a change that has been
> sitting in the ASoC tree since mid-december, and I have been waiting
> for it to hit linux-next before sending this, but it seems to take
> longer than I anticipated. So, since I do not want this to in
> turn miss the next merge window because of that wait I therefore
> request that this is taken now even though it doesn't really work
> w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
> builds cleanly even w/o those ASoC changes. That effectively means
> that noone besides me should notice the inconsistency (I currently
> have all affected devices under my control).
>
> Cheers,
> peda
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
>
> Peter Rosin (2):
> ARM: dts: at91: add devicetree for the Axentia TSE-850
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> arch/arm/configs/sama5_defconfig | 7 +-
> 6 files changed, 357 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
Both applied, thanks!
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [kvm-unit-tests PATCH v7 04/11] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-10 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-5-alex.bennee@linaro.org>
Alex Benn?e <alex.bennee@linaro.org> writes:
> So we can have portable formatting of uint32_t types.
>
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> ---
> lib/libcflat.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/libcflat.h b/lib/libcflat.h
> index bdcc561..6dab5be 100644
> --- a/lib/libcflat.h
> +++ b/lib/libcflat.h
> @@ -55,12 +55,17 @@ typedef _Bool bool;
> #define true 1
>
> #if __SIZEOF_LONG__ == 8
> +# define __PRI32_PREFIX
> # define __PRI64_PREFIX "l"
> # define __PRIPTR_PREFIX "l"
> #else
> +# define __PRI32_PREFIX "l"
OK this is bogus, but the failure is because of where we get uint32_t
from (hint using arm32 compiler on a arm64 system) so I got:
lib/pci.c:71:9: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}' [-Werro\
r=format=]
Which makes me think we should be more careful about including system
headers in kvm-unit-tests (done in 75e777a0).
--
Alex Benn?e
^ permalink raw reply
* [kvm-unit-tests PATCH v7 04/11] libcflat: add PRI(dux)32 format types
From: Alex Bennée @ 2017-01-10 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r34b2b3a.fsf@linaro.org>
Alex Benn?e <alex.bennee@linaro.org> writes:
> Alex Benn?e <alex.bennee@linaro.org> writes:
>
>> So we can have portable formatting of uint32_t types.
>>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> lib/libcflat.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/lib/libcflat.h b/lib/libcflat.h
>> index bdcc561..6dab5be 100644
>> --- a/lib/libcflat.h
>> +++ b/lib/libcflat.h
>> @@ -55,12 +55,17 @@ typedef _Bool bool;
>> #define true 1
>>
>> #if __SIZEOF_LONG__ == 8
>> +# define __PRI32_PREFIX
>> # define __PRI64_PREFIX "l"
>> # define __PRIPTR_PREFIX "l"
>> #else
>> +# define __PRI32_PREFIX "l"
>
> OK this is bogus, but the failure is because of where we get uint32_t
> from (hint using arm32 compiler on a arm64 system) so I got:
>
> lib/pci.c:71:9: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t {aka long unsigned int}' [-Werro\
> r=format=]
>
> Which makes me think we should be more careful about including system
> headers in kvm-unit-tests (done in 75e777a0).
Hmm it turns out my compiler is d.r.t as far as it is concerned:
# 34 "/usr/lib/gcc/arm-none-eabi/5.4.1/include/stdint-gcc.h" 3 4
typedef signed char int8_t;
typedef short int int16_t;
typedef long int int32_t;
typedef long long int int64_t;
typedef unsigned char uint8_t;
typedef short unsigned int uint16_t;
typedef long unsigned int uint32_t;
--
Alex Benn?e
^ permalink raw reply
* [RESEND 3/3] ARM: davinci_all_defconfig: enable iio and ADS7950
From: David Lechner @ 2017-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <03501962-eb4a-6936-15dd-ed59c73f9cd9@ti.com>
On 01/10/2017 03:27 AM, Sekhar Nori wrote:
> On Monday 09 January 2017 09:41 PM, David Lechner wrote:
>> This enables the iio subsystem and the TI ADS7950 driver. This is used by
>> LEGO MINDSTORMS EV3, which has an ADS7957 chip.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> arch/arm/configs/davinci_all_defconfig | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
>> index 2b1967a..a899876 100644
>> --- a/arch/arm/configs/davinci_all_defconfig
>> +++ b/arch/arm/configs/davinci_all_defconfig
>> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
>> CONFIG_MEMORY=y
>> CONFIG_TI_AEMIF=m
>> CONFIG_DA8XX_DDRCTL=y
>> +CONFIG_IIO=m
>> +CONFIG_IIO_BUFFER_CB=m
>> +CONFIG_IIO_SW_DEVICE=m
>> +CONFIG_IIO_SW_TRIGGER=m
>> +CONFIG_TI_ADS7950=m
>> +CONFIG_IIO_HRTIMER_TRIGGER=m
>> +CONFIG_IIO_SYSFS_TRIGGER=m
>
> Hmm, there are some other comments I gave on the previous version I
> don't see addressed. Can you please fix those or respond to those comments?
Oops, I missed the other comments. I will fix it.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 1/1] MMC: meson: avoid possible NULL dereference
From: Ulf Hansson @ 2017-01-10 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m237gwcec4.fsf@baylibre.com>
On 6 January 2017 at 18:01, Kevin Hilman <khilman@baylibre.com> wrote:
> Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
>
>> No actual segmentation faults were observed but the coding is
>> at least inconsistent.
>>
>> irqreturn_t meson_mmc_irq():
>>
>> We should not dereference host before checking it.
>>
>> meson_mmc_irq_thread():
>>
>> If cmd or mrq are NULL we should not dereference them after
>> writing a warning.
>>
>> Fixes: 51c5d8447bd7 MMC: meson: initial support for GX platforms
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
> Acked-by: Kevin Hilman <khilman@baylibre.com>
>
> Ulf, I assume you can pick this up directly for v4.10-rc?
Thanks, applied for fixes!
Kind regards
Uffe
>
> Thanks,
>
> Kevin
>
>> ---
>> drivers/mmc/host/meson-gx-mmc.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>> index b352760c041e..09739352834c 100644
>> --- a/drivers/mmc/host/meson-gx-mmc.c
>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>> @@ -578,13 +578,15 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
>> {
>> struct meson_host *host = dev_id;
>> struct mmc_request *mrq;
>> - struct mmc_command *cmd = host->cmd;
>> + struct mmc_command *cmd;
>> u32 irq_en, status, raw_status;
>> irqreturn_t ret = IRQ_HANDLED;
>>
>> if (WARN_ON(!host))
>> return IRQ_NONE;
>>
>> + cmd = host->cmd;
>> +
>> mrq = host->mrq;
>>
>> if (WARN_ON(!mrq))
>> @@ -670,10 +672,10 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
>> int ret = IRQ_HANDLED;
>>
>> if (WARN_ON(!mrq))
>> - ret = IRQ_NONE;
>> + return IRQ_NONE;
>>
>> if (WARN_ON(!cmd))
>> - ret = IRQ_NONE;
>> + return IRQ_NONE;
>>
>> data = cmd->data;
>> if (data) {
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox