Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 4/6] dma-mapping: remove arch_dma_mmap_pgprot
From: Christoph Hellwig @ 2019-08-16  7:07 UTC (permalink / raw)
  To: iommu
  Cc: Shawn Anastasio, Will Deacon, linux-m68k, Guan Xuetao,
	linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
	Geert Uytterhoeven, Catalin Marinas, James Hogan, Robin Murphy,
	linux-arm-kernel
In-Reply-To: <20190816070754.15653-1-hch@lst.de>

arch_dma_mmap_pgprot is used for two things:

 1) to override the "normal" uncached page attributes for mapping
    memory coherent to devices that can't snoop the CPU caches
 2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
    arm systems

Replace one with the pgprot_dmacoherent macro that is already provided
by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
handling to common code with an explicit arch opt-in.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm/Kconfig                   |  1 +
 arch/arm/mm/Kconfig                |  1 -
 arch/arm/mm/dma-mapping.c          |  6 ------
 arch/arm64/Kconfig                 |  1 -
 arch/arm64/include/asm/pgtable.h   |  4 ++++
 arch/arm64/mm/dma-mapping.c        |  6 ------
 arch/m68k/Kconfig                  |  1 -
 arch/m68k/include/asm/pgtable_mm.h |  3 +++
 arch/m68k/kernel/dma.c             |  3 +--
 include/linux/dma-noncoherent.h    | 13 +++++++++++--
 kernel/dma/Kconfig                 | 14 +++++++++++---
 kernel/dma/mapping.c               |  8 +++++---
 12 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..e172fba1e8fd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,7 @@ config ARM
 	select ARCH_HAS_BINFMT_FLAT
 	select ARCH_HAS_DEBUG_VIRTUAL if MMU
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
+	select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KEEPINITRD
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index c54cd7ed90ba..0609c9e2191b 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -665,7 +665,6 @@ config ARM_LPAE
 	select PHYS_ADDR_T_64BIT
 	select SWIOTLB
 	select ARCH_HAS_DMA_COHERENT_TO_PFN
-	select ARCH_HAS_DMA_MMAP_PGPROT
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
 	select ARCH_HAS_SYNC_DMA_FOR_CPU
 	help
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d42557ee69c2..d27b12f61737 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2402,12 +2402,6 @@ long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
 	return dma_to_pfn(dev, dma_addr);
 }
 
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
-		unsigned long attrs)
-{
-	return __get_dma_pgprot(attrs, prot);
-}
-
 void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		gfp_t gfp, unsigned long attrs)
 {
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3adcec05b1f6..dab9dda34206 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -13,7 +13,6 @@ config ARM64
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_DMA_COHERENT_TO_PFN
-	select ARCH_HAS_DMA_MMAP_PGPROT
 	select ARCH_HAS_DMA_PREP_COHERENT
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..6700371227d1 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -435,6 +435,10 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
 #define pgprot_device(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
+#define pgprot_dmacoherent(prot) \
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, \
+			PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
+
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bd2b039f43a6..676efcda51e6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -11,12 +11,6 @@
 
 #include <asm/cacheflush.h>
 
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
-		unsigned long attrs)
-{
-	return pgprot_writecombine(prot);
-}
-
 void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
 		size_t size, enum dma_data_direction dir)
 {
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index c518d695c376..a9e564306d3e 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -4,7 +4,6 @@ config M68K
 	default y
 	select ARCH_32BIT_OFF_T
 	select ARCH_HAS_BINFMT_FLAT
-	select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
 	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
 	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
diff --git a/arch/m68k/include/asm/pgtable_mm.h b/arch/m68k/include/asm/pgtable_mm.h
index fe3ddd73a0cc..fde4534b974f 100644
--- a/arch/m68k/include/asm/pgtable_mm.h
+++ b/arch/m68k/include/asm/pgtable_mm.h
@@ -169,6 +169,9 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
 	    ? (__pgprot((pgprot_val(prot) & _CACHEMASK040) | _PAGE_NOCACHE_S))	\
 	    : (prot)))
 
+pgprot_t pgprot_dmacoherent(pgprot_t prot);
+#define pgprot_dmacoherent(prot)	pgprot_dmacoherent(prot)
+
 #endif /* CONFIG_COLDFIRE */
 #include <asm-generic/pgtable.h>
 #endif /* !__ASSEMBLY__ */
diff --git a/arch/m68k/kernel/dma.c b/arch/m68k/kernel/dma.c
index 30cd59caf037..35064150e348 100644
--- a/arch/m68k/kernel/dma.c
+++ b/arch/m68k/kernel/dma.c
@@ -23,8 +23,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
 	cache_push(page_to_phys(page), size);
 }
 
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
-		unsigned long attrs)
+pgprot_t pgprot_dmacoherent(pgprot_t prot)
 {
 	if (CPU_IS_040_OR_060) {
 		pgprot_val(prot) &= ~_PAGE_CACHE040;
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 0bff3d7fac92..dd3de6d88fc0 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -3,6 +3,7 @@
 #define _LINUX_DMA_NONCOHERENT_H 1
 
 #include <linux/dma-mapping.h>
+#include <asm/pgtable.h>
 
 #ifdef CONFIG_ARCH_HAS_DMA_COHERENCE_H
 #include <asm/dma-coherence.h>
@@ -42,10 +43,18 @@ void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
 		dma_addr_t dma_addr, unsigned long attrs);
 long arch_dma_coherent_to_pfn(struct device *dev, void *cpu_addr,
 		dma_addr_t dma_addr);
-pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
-		unsigned long attrs);
 
 #ifdef CONFIG_MMU
+/*
+ * Page protection so that devices that can't snoop CPU caches can use the
+ * memory coherently.  We default to pgprot_noncached which is usually used
+ * for ioremap as a safe bet, but architectures can override this with less
+ * strict semantics if possible.
+ */
+#ifndef pgprot_dmacoherent
+#define pgprot_dmacoherent(prot)	pgprot_noncached(prot)
+#endif
+
 pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs);
 #else
 static inline pgprot_t dma_pgprot(struct device *dev, pgprot_t prot,
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 9decbba255fc..49148c207563 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -20,6 +20,17 @@ config ARCH_HAS_DMA_COHERENCE_H
 config ARCH_HAS_DMA_SET_MASK
 	bool
 
+#
+# Select this option if the architecture needs special handling for
+# DMA_ATTR_WRITE_COMBINE.  Normally the "uncached" mapping should be
+# what people thing of when saying write combine, but on old arm
+# platforms the write combine semantics are not well defined and thus
+# not enabled by default.  You probably do not want to enable this for
+# any new port.
+#
+config ARCH_HAS_DMA_WRITE_COMBINE
+	bool
+
 config DMA_DECLARE_COHERENT
 	bool
 
@@ -45,9 +56,6 @@ config ARCH_HAS_DMA_PREP_COHERENT
 config ARCH_HAS_DMA_COHERENT_TO_PFN
 	bool
 
-config ARCH_HAS_DMA_MMAP_PGPROT
-	bool
-
 config ARCH_HAS_FORCE_DMA_UNENCRYPTED
 	bool
 
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b0038ca3aa92..1b96616c9f20 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -161,9 +161,11 @@ pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
 	    (IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
              (attrs & DMA_ATTR_NON_CONSISTENT)))
 		return prot;
-	if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_MMAP_PGPROT))
-		return arch_dma_mmap_pgprot(dev, prot, attrs);
-	return pgprot_noncached(prot);
+#ifdef CONFIG_ARCH_HAS_DMA_WRITE_COMBINE
+	if (attrs & DMA_ATTR_WRITE_COMBINE)
+		return pgprot_writecombine(prot);
+#endif
+	return pgprot_dmacoherent(prot);
 }
 #endif /* CONFIG_MMU */
 
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 5/6] dma-mapping: make dma_atomic_pool_init self-contained
From: Christoph Hellwig @ 2019-08-16  7:07 UTC (permalink / raw)
  To: iommu
  Cc: Shawn Anastasio, Will Deacon, linux-m68k, Guan Xuetao,
	linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
	Geert Uytterhoeven, Catalin Marinas, James Hogan, Robin Murphy,
	linux-arm-kernel
In-Reply-To: <20190816070754.15653-1-hch@lst.de>

The memory allocated for the atomic pool needs to have the same
mapping attributes that we use for remapping, so use
pgprot_dmacoherent instead of open coding it.  Also deduct a
suitable zone to allocate the memory from based on the presence
of the DMA zones.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arc/mm/dma.c           |  6 ------
 arch/arm64/mm/dma-mapping.c |  6 ------
 arch/csky/mm/dma-mapping.c  |  6 ------
 arch/nds32/kernel/dma.c     |  6 ------
 include/linux/dma-mapping.h |  1 -
 kernel/dma/remap.c          | 17 ++++++++++++++---
 6 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 62c210e7ee4c..ff4a5752f8cc 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -104,9 +104,3 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 	dev_info(dev, "use %sncoherent DMA ops\n",
 		 dev->dma_coherent ? "" : "non");
 }
-
-static int __init atomic_pool_init(void)
-{
-	return dma_atomic_pool_init(GFP_KERNEL, pgprot_noncached(PAGE_KERNEL));
-}
-postcore_initcall(atomic_pool_init);
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 676efcda51e6..a1d05f669f67 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -28,12 +28,6 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
 	__dma_flush_area(page_address(page), size);
 }
 
-static int __init arm64_dma_init(void)
-{
-	return dma_atomic_pool_init(GFP_DMA32, __pgprot(PROT_NORMAL_NC));
-}
-arch_initcall(arm64_dma_init);
-
 #ifdef CONFIG_IOMMU_DMA
 void arch_teardown_dma_ops(struct device *dev)
 {
diff --git a/arch/csky/mm/dma-mapping.c b/arch/csky/mm/dma-mapping.c
index 80783bb71c5c..602a60d47a94 100644
--- a/arch/csky/mm/dma-mapping.c
+++ b/arch/csky/mm/dma-mapping.c
@@ -14,12 +14,6 @@
 #include <linux/version.h>
 #include <asm/cache.h>
 
-static int __init atomic_pool_init(void)
-{
-	return dma_atomic_pool_init(GFP_KERNEL, pgprot_noncached(PAGE_KERNEL));
-}
-postcore_initcall(atomic_pool_init);
-
 void arch_dma_prep_coherent(struct page *page, size_t size)
 {
 	if (PageHighMem(page)) {
diff --git a/arch/nds32/kernel/dma.c b/arch/nds32/kernel/dma.c
index 490e3720d694..4206d4b6c8ce 100644
--- a/arch/nds32/kernel/dma.c
+++ b/arch/nds32/kernel/dma.c
@@ -80,9 +80,3 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
 {
 	cache_op(page_to_phys(page), size, cpu_dma_wbinval_range);
 }
-
-static int __init atomic_pool_init(void)
-{
-	return dma_atomic_pool_init(GFP_KERNEL, pgprot_noncached(PAGE_KERNEL));
-}
-postcore_initcall(atomic_pool_init);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..48ebe8295987 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -624,7 +624,6 @@ void *dma_common_pages_remap(struct page **pages, size_t size,
 			const void *caller);
 void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags);
 
-int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot);
 bool dma_in_atomic_pool(void *start, size_t size);
 void *dma_alloc_from_pool(size_t size, struct page **ret_page, gfp_t flags);
 bool dma_free_from_pool(void *start, size_t size);
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c
index ffe78f0b2fe4..838123f79639 100644
--- a/kernel/dma/remap.c
+++ b/kernel/dma/remap.c
@@ -105,7 +105,16 @@ static int __init early_coherent_pool(char *p)
 }
 early_param("coherent_pool", early_coherent_pool);
 
-int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
+static gfp_t dma_atomic_pool_gfp(void)
+{
+	if (IS_ENABLED(CONFIG_ZONE_DMA))
+		return GFP_DMA;
+	if (IS_ENABLED(CONFIG_ZONE_DMA32))
+		return GFP_DMA32;
+	return GFP_KERNEL;
+}
+
+static int __init dma_atomic_pool_init(void)
 {
 	unsigned int pool_size_order = get_order(atomic_pool_size);
 	unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
@@ -117,7 +126,7 @@ int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
 		page = dma_alloc_from_contiguous(NULL, nr_pages,
 						 pool_size_order, false);
 	else
-		page = alloc_pages(gfp, pool_size_order);
+		page = alloc_pages(dma_atomic_pool_gfp(), pool_size_order);
 	if (!page)
 		goto out;
 
@@ -128,7 +137,8 @@ int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
 		goto free_page;
 
 	addr = dma_common_contiguous_remap(page, atomic_pool_size, VM_USERMAP,
-					   prot, __builtin_return_address(0));
+					   pgprot_dmacoherent(PAGE_KERNEL),
+					   __builtin_return_address(0));
 	if (!addr)
 		goto destroy_genpool;
 
@@ -155,6 +165,7 @@ int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
 		atomic_pool_size / 1024);
 	return -ENOMEM;
 }
+postcore_initcall(dma_atomic_pool_init);
 
 bool dma_in_atomic_pool(void *start, size_t size)
 {
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v9 08/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
From: Yong Wu @ 2019-08-16  7:22 UTC (permalink / raw)
  To: Will Deacon
  Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
	srv_heupstream, chao.hao, Joerg Roedel, linux-kernel, Evan Green,
	Tomasz Figa, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
	ming-fan.chen, anan.sun, Robin Murphy, Matthias Kaehlcke,
	linux-arm-kernel
In-Reply-To: <20190815115021.7pbv5s2qbgsuitvh@willie-the-truck>

On Thu, 2019-08-15 at 12:50 +0100, Will Deacon wrote:
> Ok, I think speaking to Robin helped me a bit with this...
> 
> On Thu, Aug 15, 2019 at 06:18:38PM +0800, Yong Wu wrote:
> > On Thu, 2019-08-15 at 10:51 +0100, Will Deacon wrote:
> > > On Thu, Aug 15, 2019 at 04:47:49PM +0800, Yong Wu wrote:
> > > > On Wed, 2019-08-14 at 15:41 +0100, Will Deacon wrote:
> > > > > On Sat, Aug 10, 2019 at 03:58:08PM +0800, Yong Wu wrote:
> > > > > > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> > > > > > 
> > > > > > In the mt2712 and mt8173, it's called "4GB mode", the physical address
> > > > > > is from 0x4000_0000 to 0x1_3fff_ffff, but from EMI point of view, it
> > > > > > is remapped to high address from 0x1_0000_0000 to 0x1_ffff_ffff, the
> > > > > > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > > > > > for all PTEs which means to enable bit32 of physical address. Here is
> > > > > > the detailed remap relationship in the "4GB mode":
> > > > > > CPU PA         ->    HW PA
> > > > > > 0x4000_0000          0x1_4000_0000 (Add bit32)
> > > > > > 0x8000_0000          0x1_8000_0000 ...
> > > > > > 0xc000_0000          0x1_c000_0000 ...
> > > > > > 0x1_0000_0000        0x1_0000_0000 (No change)
> 
> [...]
> 
> > > > > The way I would like this quirk to work is that the io-pgtable code
> > > > > basically sets bit 9 in the pte when bit 32 is set in the physical address,
> > > > > and sets bit 4 in the pte when bit 33 is set in the physical address. It
> > > > > would then do the opposite when converting a pte to a physical address.
> > > > > 
> > > > > That way, your driver can call the page table code directly with the high
> > > > > addresses and we don't have to do any manual offsetting or range checking
> > > > > in the page table code.
> > > > 
> > > > In this case, the mt8183 can work successfully while the "4gb
> > > > mode"(mt8173/mt2712) can not.
> > > > 
> > > > In the "4gb mode", As the remap relationship above, we should always add
> > > > bit32 in pte as we did in [2]. and need add bit32 in the
> > > > "iova_to_phys"(Not always add.). That means the "4gb mode" has a special
> > > > flow:
> > > > a. Always add bit32 in paddr_to_iopte.
> > > > b. Add bit32 only when PA < 0x40000000 in iopte_to_paddr.
> > > 
> > > I think this is probably at the heart of my misunderstanding. What is so
> > > special about PAs (is this HW PA or CPU PA?) below 0x40000000? Is this RAM
> > > or something else?
> > 
> > SRAM and HW register that IOMMU can not access.
> 
> Ok, so redrawing your table from above, I think we can say something like:
> 
> 
> CPU Physical address
> ====================
> 
> 0G	1G	2G	3G	4G	5G
> |---A---|---B---|---C---|---D---|---E---|
> +--I/O--+------------Memory-------------+
> 
> 
> IOMMU output physical address
> =============================
> 
> 				4G	5G	6G	7G	8G
> 				|---E---|---B---|---C---|---D---|
> 				+------------Memory-------------+
> 
> 
> Do you agree? 

Quite right.


> If so, what happens to region 'A' (the I/O region) in the
> IOMMU output physical address space. Is it accessible?

No. IOMMU can not access region 'A' above.

> 
> Anyway, I think it's the job of the driver to convert between the two
> address spaces, so that:
> 
>   - On ->map(), bit 32 of the CPU physical address is set before calling
>     into the iopgtable code
> 
>   - The result from ->iova_to_phys() should be the result from the
>     iopgtable code, but with the top bit cleared for addresses over
>     5G.
> 
> This assumes that:
> 
>   1. We're ok setting bit 9 in the ptes mapping region 'E'.
>   2. The IOMMU page-table walker uses CPU physical addresses
> 
> Are those true?

Yes. Then this patch would be close to the one[1] I sent in v8.

Do I need to split this patch into 2 ones?:
a).the pagetable code that support 34bit PA when MTK quirk is enabled.
It only has the symmetric code handle BIT32/BIT33. Besides, I will add
CONFIG_PHYS_ADDR_T_64BIT in the iopte_to_addr as commented before.

b) MTK code that apply the special "4gb mode" flow. And the "oas" will
always is 34 bit since v7s has already supported our case.

[1]http://lists.infradead.org/pipermail/linux-mediatek/2019-June/020991.html

> 
> Thanks,
> 
> Will



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Christoph Hellwig @ 2019-08-16  7:07 UTC (permalink / raw)
  To: iommu
  Cc: Shawn Anastasio, Will Deacon, linux-m68k, Guan Xuetao,
	linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
	Geert Uytterhoeven, Catalin Marinas, James Hogan, Robin Murphy,
	linux-arm-kernel
In-Reply-To: <20190816070754.15653-1-hch@lst.de>

Based on an email from Will Deacon.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm64/include/asm/pgtable.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 6700371227d1..6ff221d9a631 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
 #define pgprot_device(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
+/*
+ * DMA allocations for non-coherent devices use what the Arm architecture calls
+ * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
+ * and merging of writes.  This is different from "Strongly Ordered" memory
+ * which is intended for MMIO and thus forbids speculation, preserves access
+ * size, requires strict alignment and also forces write responses to come from
+ * the endpoint.
+ */
 #define pgprot_dmacoherent(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, \
 			PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Geert Uytterhoeven @ 2019-08-16  7:39 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Gavin Li, Shawn Guo, Fabio Estevam, Linux-Arch, Michal Simek,
	Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
	Sascha Hauer, linux-m68k, Minas Harutyunyan, Bin Liu, Linux ARM,
	Laurentiu Tudor, Geoff Levand, Greg Kroah-Hartman, USB list,
	Linux Kernel Mailing List, Linux IOMMU, Pengutronix Kernel Team,
	linuxppc-dev
In-Reply-To: <20190816062435.881-7-hch@lst.de>

Hi Christoph,

On Fri, Aug 16, 2019 at 8:30 AM Christoph Hellwig <hch@lst.de> wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_device so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default, replacing similar functionality in m68k and
> powerpc.  The arch_setup_pdev_archdata hooks is now unused and removed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  arch/m68k/kernel/dma.c               |  9 -------

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

>  arch/sh/boards/mach-ecovec24/setup.c |  2 --
>  arch/sh/boards/mach-migor/setup.c    |  1 -

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
given "[PATCH 0/2] Remove calls to empty arch_setup_pdev_archdata()"
https://lore.kernel.org/linux-renesas-soc/1526641611-2769-1-git-send-email-geert+renesas@glider.be/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 4/6] dma-mapping: remove arch_dma_mmap_pgprot
From: Geert Uytterhoeven @ 2019-08-16  7:43 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Shawn Anastasio, linux-m68k, Will Deacon, linuxppc-dev,
	Linux Kernel Mailing List, Linux IOMMU, Paul Burton,
	Catalin Marinas, James Hogan, Russell King, linux-mips,
	Guan Xuetao, Linux ARM, Robin Murphy
In-Reply-To: <20190816070754.15653-5-hch@lst.de>

On Fri, Aug 16, 2019 at 9:19 AM Christoph Hellwig <hch@lst.de> wrote:
> arch_dma_mmap_pgprot is used for two things:
>
>  1) to override the "normal" uncached page attributes for mapping
>     memory coherent to devices that can't snoop the CPU caches
>  2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
>     arm systems
>
> Replace one with the pgprot_dmacoherent macro that is already provided
> by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
> handling to common code with an explicit arch opt-in.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

>  arch/m68k/Kconfig                  |  1 -
>  arch/m68k/include/asm/pgtable_mm.h |  3 +++
>  arch/m68k/kernel/dma.c             |  3 +--

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/3] arm64: allwinner: h6: add I2C nodes
From: Maxime Ripard @ 2019-08-16  7:50 UTC (permalink / raw)
  To: Bhushan Shah
  Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
	linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
	linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816064710.18280-3-bshah@kde.org>


[-- Attachment #1.1: Type: text/plain, Size: 1530 bytes --]

On Fri, Aug 16, 2019 at 12:17:09PM +0530, Bhushan Shah wrote:
> Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
> nodes.
>
> Suggested-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Bhushan Shah <bshah@kde.org>
> ---
> Changes in v2:
>   - Add the SoC specific compatible string instead of re-using a31 one.
>
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 +++++++++++++++++++-
>  1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index bcecca17d61d..a1a329926540 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -329,6 +329,21 @@
>  				function = "hdmi";
>  			};
>
> +			i2c0_pins: i2c0-pins {
> +				pins = "PD25", "PD26";
> +				function = "i2c0";
> +			};
> +
> +			i2c1_pins: i2c1-pins {
> +				pins = "PH5", "PH6";
> +				function = "i2c1";
> +			};
> +
> +			i2c2_pins: i2c2-pins {
> +				pins = "PD23", "PD24";
> +				function = "i2c2";
> +			};
> +
>  			mmc0_pins: mmc0-pins {
>  				pins = "PF0", "PF1", "PF2", "PF3",
>  				       "PF4", "PF5";
> @@ -464,6 +479,45 @@
>  			status = "disabled";
>  		};
>
> +		i2c0: i2c@5002000 {
> +			compatible = "allwinner,sun50i-h6-i2c";

This isn't going to work if you don't patch the driver to add the
compatible. And this isn't what you described in the binding patch.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 3/3] arm64: allwinner: h6: add i2c0 node in PineH64
From: Maxime Ripard @ 2019-08-16  7:52 UTC (permalink / raw)
  To: Bhushan Shah
  Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
	linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
	linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816064710.18280-4-bshah@kde.org>


[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]

65;5603;1c
On Fri, Aug 16, 2019 at 12:17:10PM +0530, Bhushan Shah wrote:
> i2c0 bus is exposed by PI-2 BUS in the PineH64, model B.
>
> Signed-off-by: Bhushan Shah <bshah@kde.org>
> ---
> Changes in v2:
>   - Don't enable the i2c0 node in PineH64 by default
>
>  arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index 684d1daa3081..97d9b7c63fb3 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -160,6 +160,15 @@
>  	vcc-pg-supply = <&reg_aldo1>;
>  };
>
> +/* This i2c interface is exposed on PI-2 BUS, Pin 3 (I2C_SDA) and 5 (I2C_SCL) */
> +&i2c0 {
> +	status = "disabled";
> +};

This property is set to disabled in the DTSI already

> +&i2c0_pins {
> +	bias-pull-up;
> +};
> +

And this should be in the same overlay than the one that sets status
to okay.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] arm64: do_csum: implement accelerated scalar version
From: Shaokun Zhang @ 2019-08-16  8:15 UTC (permalink / raw)
  To: Will Deacon
  Cc: Ard Biesheuvel, netdev, ilias.apalodimas, huanglingyan (A),
	Robin Murphy, linux-arm-kernel, steve.capper
In-Reply-To: <20190815164609.GI2015@fuggles.cambridge.arm.com>

Hi Will,

On 2019/8/16 0:46, Will Deacon wrote:
> On Thu, May 16, 2019 at 11:14:35AM +0800, Zhangshaokun wrote:
>> On 2019/5/15 17:47, Will Deacon wrote:
>>> On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
>>>> On 12/04/2019 10:52, Will Deacon wrote:
>>>>> I'm waiting for Robin to come back with numbers for a C implementation.
>>>>>
>>>>> Robin -- did you get anywhere with that?
>>>>
>>>> Still not what I would call finished, but where I've got so far (besides an
>>>> increasingly elaborate test rig) is as below - it still wants some unrolling
>>>> in the middle to really fly (and actual testing on BE), but the worst-case
>>>> performance already equals or just beats this asm version on Cortex-A53 with
>>>> GCC 7 (by virtue of being alignment-insensitive and branchless except for
>>>> the loop). Unfortunately, the advantage of C code being instrumentable does
>>>> also come around to bite me...
>>>
>>> Is there any interest from anybody in spinning a proper patch out of this?
>>> Shaokun?
>>
>> HiSilicon's Kunpeng920(Hi1620) benefits from do_csum optimization, if Ard and
>> Robin are ok, Lingyan or I can try to do it.
>> Of course, if any guy posts the patch, we are happy to test it.
>> Any will be ok.
> 
> I don't mind who posts it, but Robin is super busy with SMMU stuff at the
> moment so it probably makes more sense for you or Lingyan to do it.

Thanks for restarting this topic, I or Lingyan will do it soon.

Thanks,
Shaokun

> 
> Will
> 
> .
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Sakari Ailus @ 2019-08-16  8:15 UTC (permalink / raw)
  To: Hugues Fruchet
  Cc: Yannick Fertre, Alexandre Torgue, Mickael GUENE, linux-kernel,
	Philippe CORNU, Hans Verkuil, Benjamin Gaignard,
	Mauro Carvalho Chehab, linux-stm32, linux-arm-kernel, linux-media
In-Reply-To: <1565790533-10043-3-git-send-email-hugues.fruchet@st.com>

Hi Hugues,

On Wed, Aug 14, 2019 at 03:48:51PM +0200, Hugues Fruchet wrote:
> Add a trace of the set of supported fourcc/mbus_code which
> intersect between DCMI and source sub-device.
> 
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
>  drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index b462f71..18acecf 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
>  			/* Code supported, have we got this fourcc yet? */
>  			for (j = 0; j < num_fmts; j++)
>  				if (sd_fmts[j]->fourcc ==
> -						dcmi_formats[i].fourcc)
> +						dcmi_formats[i].fourcc) {
>  					/* Already available */
> +					dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
> +						(char *)&sd_fmts[j]->fourcc,
> +						mbus_code.code);
>  					break;
> -			if (j == num_fmts)
> +				}
> +			if (j == num_fmts) {
>  				/* New */
>  				sd_fmts[num_fmts++] = dcmi_formats + i;
> +				dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",

Over 80 characters per line.

> +					(char *)&sd_fmts[num_fmts - 1]->fourcc,
> +					sd_fmts[num_fmts - 1]->mbus_code);
> +			}
>  		}
>  		mbus_code.index++;
>  	}

-- 
Regards,

Sakari Ailus
sakari.ailus@linux.intel.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 3/3] arm64: allwinner: h6: add i2c0 node in PineH64
From: Bhushan Shah @ 2019-08-16  8:21 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
	Bhushan Shah, linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
	linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816075211.xaq54q2cdniwjpp3@flea>


[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]

On Fri, Aug 16, 2019 at 09:52:11AM +0200, Maxime Ripard wrote:
> > +/* This i2c interface is exposed on PI-2 BUS, Pin 3 (I2C_SDA) and 5 (I2C_SCL) */
> > +&i2c0 {
> > +	status = "disabled";
> > +};
> 
> This property is set to disabled in the DTSI already

I added this node here with disabled status due to comment from wens in
previous revision, main reason being that serves as reference/pointer to
people looking at how to enable i2c0.

I can remove it if you prefer.


-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/3] arm64: allwinner: h6: add I2C nodes
From: Bhushan Shah @ 2019-08-16  8:23 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
	Bhushan Shah, linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
	linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816075031.zw4bjunn4hfoaq3e@flea>


[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]

On Fri, Aug 16, 2019 at 09:50:31AM +0200, Maxime Ripard wrote:
> On Fri, Aug 16, 2019 at 12:17:09PM +0530, Bhushan Shah wrote:
> > Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
> > nodes.
> >
> > Suggested-by: Icenowy Zheng <icenowy@aosc.io>
> > Signed-off-by: Bhushan Shah <bshah@kde.org>
> > ---
> > Changes in v2:
> >   - Add the SoC specific compatible string instead of re-using a31 one.
> >
> >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 +++++++++++++++++++-
> >  1 file changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index bcecca17d61d..a1a329926540 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -329,6 +329,21 @@
> >  				function = "hdmi";
> >  			};
> >
> > +			i2c0_pins: i2c0-pins {
> > +				pins = "PD25", "PD26";
> > +				function = "i2c0";
> > +			};
> > +
> > +			i2c1_pins: i2c1-pins {
> > +				pins = "PH5", "PH6";
> > +				function = "i2c1";
> > +			};
> > +
> > +			i2c2_pins: i2c2-pins {
> > +				pins = "PD23", "PD24";
> > +				function = "i2c2";
> > +			};
> > +
> >  			mmc0_pins: mmc0-pins {
> >  				pins = "PF0", "PF1", "PF2", "PF3",
> >  				       "PF4", "PF5";
> > @@ -464,6 +479,45 @@
> >  			status = "disabled";
> >  		};
> >
> > +		i2c0: i2c@5002000 {
> > +			compatible = "allwinner,sun50i-h6-i2c";
> 
> This isn't going to work if you don't patch the driver to add the
> compatible. And this isn't what you described in the binding patch.

oops, I will correct this in next patch series. Sorry.

> 
> Maxime
> 
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Aaro Koskinen @ 2019-08-16  8:34 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Bartlomiej Zolnierkiewicz, Tony Lindgren, Greg Kroah-Hartman,
	Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
	Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a3k_HOGqzMGjtc+7NSaK0Bsa_vxxRFLzY8aP6ev4wa9iA@mail.gmail.com>

Hi,

On Wed, Aug 14, 2019 at 12:36:40PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [190813 19:34]:
> > > -#define OMAP1_IO_OFFSET                0x01000000      /* Virtual IO
> > > = 0xfefb0000 */
> > > +#define OMAP1_IO_OFFSET                0x00fb0000      /* Virtual IO
> > > = 0xff000000 */
> > >  #define OMAP1_IO_ADDRESS(pa)   IOMEM((pa) - OMAP1_IO_OFFSET)
> >
> > Oh OK yeah sounds like that's the issue.
> >
> > > There may be additional locations that hardcode the virtual address.
> >
> > Those should be in mach-omap1/io.c, and I recall innovator had some
> > hardcoded fpga address that should also be checked.
> 
> I see four boards with hardcoded I/O addresses, but they are all below
> the PCI I/O virtual address range, and are not affected by that change.
> 
> For the innovator FPGA access, this was ok, it uses the correct address
> in the OMAP1_IO_OFFSET range.

I tried testing this on OSK board. If I boot with earlyprintk disabled,
it boots OK and everything works (also CF card) with your playground
commit 5723b6686943.

However with earlyprintk it seems to hang as soon as kernel tries to print
something. So something goes wrong with early DEBUG_LL mapping code when
CONFIG_DEBUG_UART_VIRT=0xff000000 is used?

A.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Wei Xu @ 2019-08-16  8:41 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Salil Mehta, jinying, Tangkunshan, John Garry,
	linux-kernel@vger.kernel.org, Shameerali Kolothum Thodi, Linuxarm,
	open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
	Liguozhu (Kenneth), Zhangyi ac,
	linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <CACRpkdbi21mV5quTmur6egb6FJMFrD-Lg1EUKtk+HejyWjzmUA@mail.gmail.com>

Hi Linus,

On 2019/8/14 17:04, Linus Walleij wrote:
> Hi Wei,
>
> thanks for your patch!
>
> This doesn't apply for my "devel" branch, can you rebase
> on this:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>
> We have moved some ACPI headers around recently.

Thanks to review!
I just sent out the v2 based on that.

> On Mon, Aug 12, 2019 at 1:28 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
>> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
>> attached to the pl061 acpi node to register interruption.
> Makes sense.
>
>> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
> I doubt this is a regression since I haven't seen anyone use this
> gpiochip with ACPI before.
>
> Please rename the patch "gpio: pl061: Add ACPI support" unless
> you can convince me it worked without changes before.

In the v2, I attached the log on QEMU v3.0.0 and Linux kernel v5.2.0-rc7 
and
the pl061 driver can register ACPI interruption.
Based on that, I did not rename the patch but I am OK to rename it if 
you have
any doubt.

> Please include some ACPI people on review of this. From
> MAINTAINERS:
> ACPI
> M:      "Rafael J. Wysocki" <rjw@rjwysocki.net>
> M:      Len Brown <lenb@kernel.org>
> L:      linux-acpi@vger.kernel.org
>
> I would also include Andy Shevchenko and Mika Westerberg for
> the GPIO aspects.
Copied to all of them in the v2.
Thanks!

Best Regards,
Wei

> Thanks!
> Linus Walleij
>
> .
>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 0/2] Enable the I2C nodes for Allwinner H6 CPU
From: Bhushan Shah @ 2019-08-16  8:43 UTC (permalink / raw)
  To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
	Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
	linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816064710.18280-1-bshah@kde.org>

This patch series adds device-tree nodes for i2c nodes in the H6 dtsi,
and enables it for the Pine H64.

Changes in v2:
  - Add the SoC specific compatible string instead of re-using a31 one.
  - Don't enable the i2c0 node in PineH64 by default

Changes in v3:
  - Fix compatible for i2c in sun50i-h6.dtsi
  - drop changes in the PineH64 dts completely

Bhushan Shah (2):
  dt-bindings: i2c: mv64xxx: Add compatible for the H6 i2c node.
  arm64: allwinner: h6: add I2C nodes

 .../bindings/i2c/marvell,mv64xxx-i2c.yaml     |  3 +
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 60 ++++++++++++++++++-
 2 files changed, 62 insertions(+), 1 deletion(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 1/2] dt-bindings: i2c: mv64xxx: Add compatible for the H6 i2c node.
From: Bhushan Shah @ 2019-08-16  8:43 UTC (permalink / raw)
  To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
	Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
	linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816084309.27440-1-bshah@kde.org>

Allwinner H6 have a mv64xxx i2c interface available to be used.

Signed-off-by: Bhushan Shah <bshah@kde.org>
---

 Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
index 001f2b7abad0..c779000515d6 100644
--- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
@@ -26,6 +26,9 @@ properties:
       - items:
           - const: allwinner,sun50i-a64-i2c
           - const: allwinner,sun6i-a31-i2c
+      - items:
+          - const: allwinner,sun50i-h6-i2c
+          - const: allwinner,sun6i-a31-i2c
 
       - const: marvell,mv64xxx-i2c
       - const: marvell,mv78230-i2c
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v3 2/2] arm64: allwinner: h6: add I2C nodes
From: Bhushan Shah @ 2019-08-16  8:43 UTC (permalink / raw)
  To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
	Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
	linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816084309.27440-1-bshah@kde.org>

Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
nodes.

Suggested-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Bhushan Shah <bshah@kde.org>
---
Changes in v3:
  - fix compatible for the i2c
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 60 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index db71807255ef..5dc174715311 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -332,6 +332,21 @@
 				function = "hdmi";
 			};
 
+			i2c0_pins: i2c0-pins {
+				pins = "PD25", "PD26";
+				function = "i2c0";
+			};
+
+			i2c1_pins: i2c1-pins {
+				pins = "PH5", "PH6";
+				function = "i2c1";
+			};
+
+			i2c2_pins: i2c2-pins {
+				pins = "PD23", "PD24";
+				function = "i2c2";
+			};
+
 			mmc0_pins: mmc0-pins {
 				pins = "PF0", "PF1", "PF2", "PF3",
 				       "PF4", "PF5";
@@ -467,6 +482,48 @@
 			status = "disabled";
 		};
 
+		i2c0: i2c@5002000 {
+			compatible = "allwinner,sun50i-h6-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C0>;
+			resets = <&ccu RST_BUS_I2C0>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c0_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c1: i2c@5002400 {
+			compatible = "allwinner,sun50i-h6-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002400 0x400>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C1>;
+			resets = <&ccu RST_BUS_I2C1>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c1_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c2: i2c@5002800 {
+			compatible = "allwinner,sun50i-h6-i2c",
+				     "allwinner,sun6i-a31-i2c";
+			reg = <0x05002800 0x400>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_I2C2>;
+			resets = <&ccu RST_BUS_I2C2>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&i2c2_pins>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		emac: ethernet@5020000 {
 			compatible = "allwinner,sun50i-h6-emac",
 				     "allwinner,sun50i-a64-emac";
@@ -798,7 +855,8 @@
 		};
 
 		r_i2c: i2c@7081400 {
-			compatible = "allwinner,sun6i-a31-i2c";
+			compatible = "allwinner,sun50i-h6-i2c",
+				     "allwinner,sun6i-a31-i2c";
 			reg = <0x07081400 0x400>;
 			interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&r_ccu CLK_R_APB2_I2C>;
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Wei Xu @ 2019-08-16  9:05 UTC (permalink / raw)
  To: xuwei5, linux-gpio, linux-kernel, linux-arm-kernel, linus.walleij,
	rjw, lenb, mika.westerberg, andy.shevchenko
  Cc: salil.mehta, jinying, tangkunshan, john.garry, linuxarm,
	shameerali.kolothum.thodi, huangdaode, jonathan.cameron, liguozhu,
	zhangyi.ac, shiju.jose

Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.

Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.

Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
and found pl061 interruption is missed in the /proc/interrupts:
1.
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic  \
-bios QEMU_EFI.fd  \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"

2. cat /proc/interrupts in the guest console:

	estuary:/$ cat /proc/interrupts
		   CPU0
	2:         3228     GICv3  27 Level     arch_timer
	4:           15     GICv3  33 Level     uart-pl011
	42:           0     GICv3  23 Level     arm-pmu
	IPI0:         0       Rescheduling interrupts
	IPI1:         0       Function call interrupts
	IPI2:         0       CPU stop interrupts
	IPI3:         0       CPU stop (for crash dump) interrupts
	IPI4:         0       Timer broadcast interrupts
	IPI5:         0       IRQ work interrupts
	IPI6:         0       CPU wake-up interrupts
	Err:          0

But on QEMU v3.0.0 and Linux kernel v5.2.0-rc7, pl061 interruption is
there as below:

	estuary:/$ cat /proc/interrupts
		   CPU0
	  2:       2648     GICv3  27 Level     arch_timer
	  4:         12     GICv3  33 Level     uart-pl011
	 42:          0     GICv3  23 Level     arm-pmu
	 43:          0  ARMH0061:00   3 Edge      ACPI:Event
	IPI0:         0       Rescheduling interrupts
	IPI1:         0       Function call interrupts
	IPI2:         0       CPU stop interrupts
	IPI3:         0       CPU stop (for crash dump) interrupts
	IPI4:         0       Timer broadcast interrupts
	IPI5:         0       IRQ work interrupts
	IPI6:         0       CPU wake-up interrupts
	Err:          0

And the whole dmesg log on Linux kernel v5.2.0-rc7 is as below:

	[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
	[    0.000000] Linux version 5.2.0-rc7 (joyx@Turing-Arch-b) (gcc version 4.9.1 20140505 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)) #61 SMP PREEMPT Fri Aug 16 11:54:31 CST 2019
	[    0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')
	[    0.000000] printk: bootconsole [pl11] enabled
	[    0.000000] efi: Getting EFI parameters from FDT:
	[    0.000000] efi: EFI v2.70 by EDK II
	[    0.000000] efi:  SMBIOS 3.0=0x7f8e0000  MEMATTR=0x7d60f018  ACPI 2.0=0x7c270000  MEMRESERVE=0x7c503018
	[    0.000000] cma: Reserved 32 MiB at 0x000000007a000000
	[    0.000000] ACPI: Early table checksum verification disabled
	[    0.000000] ACPI: RSDP 0x000000007C270000 000024 (v02 BOCHS )
	[    0.000000] ACPI: XSDT 0x000000007C260000 000054 (v01 BOCHS  BXPCFACP 00000001      01000013)
	[    0.000000] ACPI: FACP 0x000000007C220000 00010C (v05 BOCHS  BXPCFACP 00000001 BXPC 00000001)
	[    0.000000] ACPI: DSDT 0x000000007C230000 00482C (v02 BOCHS  BXPCDSDT 00000001 BXPC 00000001)
	[    0.000000] ACPI: APIC 0x000000007C210000 0000A0 (v03 BOCHS  BXPCAPIC 00000001 BXPC 00000001)
	[    0.000000] ACPI: GTDT 0x000000007C200000 000060 (v02 BOCHS  BXPCGTDT 00000001 BXPC 00000001)v
	[    0.000000] ACPI: MCFG 0x000000007C1F0000 00003C (v01 BOCHS  BXPCMCFG 00000001 BXPC 00000001)
	[    0.000000] ACPI: SPCR 0x000000007C1E0000 000050 (v02 BOCHS  BXPCSPCR 00000001 BXPC 00000001)
	[    0.000000] ACPI: SRAT 0x000000007C1D0000 00006A (v03 BOCHS  BXPCSRAT 00000001 BXPC 00000001)
	[    0.000000] ACPI: SPCR: console: pl011,mmio,0x9000000,9600
	[    0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x40000000-0x7fffffff]
	[    0.000000] NUMA: NODE_DATA [mem 0x7fdfb840-0x7fdfcfff]
	[    0.000000] Zone ranges:
	[    0.000000]   DMA32    [mem 0x0000000040000000-0x000000007fffffff]
	[    0.000000]   Normal   empty
	[    0.000000] Movable zone start for each node
	[    0.000000] Early memory node ranges
	[    0.000000]   node   0: [mem 0x0000000040000000-0x000000007c27ffff]
	[    0.000000]   node   0: [mem 0x000000007c280000-0x000000007c4fffff]
	[    0.000000]   node   0: [mem 0x000000007c500000-0x000000007f7dffff]
	[    0.000000]   node   0: [mem 0x000000007f7e0000-0x000000007f86ffff]
	[    0.000000]   node   0: [mem 0x000000007f870000-0x000000007f87ffff]
	[    0.000000]   node   0: [mem 0x000000007f880000-0x000000007f99ffff]
	[    0.000000]   node   0: [mem 0x000000007f9a0000-0x000000007fffffff]
	[    0.000000] Zeroed struct page in unavailable ranges: 416 pages
	[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
	[    0.000000] On node 0 totalpages: 262144
	[    0.000000]   DMA32 zone: 4096 pages used for memmap
	[    0.000000]   DMA32 zone: 0 pages reserved
	[    0.000000]   DMA32 zone: 262144 pages, LIFO batch:63
	[    0.000000] psci: probing for conduit method from ACPI.
	[    0.000000] psci: PSCIv0.2 detected in firmware.
	[    0.000000] psci: Using standard PSCI v0.2 function IDs
	[    0.000000] psci: Trusted OS migration not required
	[    0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x0 -> Node 0
	[    0.000000] percpu: Embedded 23 pages/cpu s56768 r8192 d29248 u94208
	[    0.000000] pcpu-alloc: s56768 r8192 d29248 u94208 alloc=23*4096
	[    0.000000] pcpu-alloc: [0] 0
	[    0.000000] Detected PIPT I-cache on CPU0
	[    0.000000] CPU features: detected: ARM erratum 832075
	[    0.000000] CPU features: detected: GIC system register CPU interface
	[    0.000000] CPU features: detected: ARM erratum 834220
	[    0.000000] CPU features: detected: EL2 vector hardening
	[    0.000000] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
	[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258048
	[    0.000000] Policy zone: DMA32
	[    0.000000] Kernel command line: console=ttyAMA0 acpi=force earlycon=pl011,0x9000000 initrd=initrd
	[    0.000000] Memory: 848128K/1048576K available (11132K kernel code, 1766K rwdata, 5924K rodata, 1344K init, 447K bss, 167680K reserved, 32768K cma-reserved)
	[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
	[    0.000000] rcu: Preemptible hierarchical RCU implementation.
	[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
	[    0.000000]  Tasks RCU enabled.
	[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
	[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
	[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
	[    0.000000] GICv3: Distributor has no Range Selector support
	[    0.000000] GICv3: no VLPI support, no direct LPI support
	[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x00000000080a0000
	[    0.000000] random: get_random_bytes called from start_kernel+0x2b4/0x470 with crng_init=0
	[    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
	[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
	[    0.000092] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
	[    0.007507] Console: colour dummy device 80x25
	[    0.009048] ACPI: Core revision 20190509
	[    0.013315] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
	[    0.014388] pid_max: default: 32768 minimum: 301
	[    0.015596] LSM: Security Framework initializing
	[    0.125480] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
	[    0.126961] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
	[    0.127543] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
	[    0.127927] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
	[    0.139974] *** VALIDATE proc ***
	[    0.144385] *** VALIDATE cgroup1 ***
	[    0.144602] *** VALIDATE cgroup2 ***
	[    0.156728] ACPI PPTT: No PPTT table found, CPU and cache topology may be inaccurate
	[    0.185506] ASID allocator initialised with 32768 entries
	[    0.193054] rcu: Hierarchical SRCU implementation.
	[    0.204036] Remapping and enabling EFI services.
	[    0.213563] smp: Bringing up secondary CPUs ...
	[    0.213898] smp: Brought up 1 node, 1 CPU
	[    0.214131] SMP: Total of 1 processors activated.
	[    0.214418] CPU features: detected: 32-bit EL0 Support
	[    0.214766] CPU features: detected: CRC32 instructions
	[    0.223253] CPU: All CPU(s) started at EL1
	[    0.223634] alternatives: patching kernel code
	[    0.244639] devtmpfs: initialized
	[    0.256434] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
	[    0.257056] futex hash table entries: 256 (order: 2, 16384 bytes)
	[    0.263282] pinctrl core: initialized pinctrl subsystem
	[    0.276553] SMBIOS 3.0.0 present.
	[    0.276921] DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
	[    0.284007] NET: Registered protocol family 16
	[    0.286721] audit: initializing netlink subsys (disabled)
	[    0.291045] audit: type=2000 audit(0.268:1): state=initialized audit_enabled=0 res=1
	[    0.295580] cpuidle: using governor menu
	[    0.297330] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
	[    0.304834] DMA: preallocated 256 KiB pool for atomic allocations
	[    0.308014] ACPI: bus type PCI registered
	[    0.308308] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
	[    0.310517] Serial: AMBA PL011 UART driver
	[    0.354362] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
	[    0.354735] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
	[    0.355104] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
	[    0.355445] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
	[    0.382352] cryptd: max_cpu_qlen set to 1000
	[    0.408375] ACPI: Added _OSI(Module Device)
	[    0.408641] ACPI: Added _OSI(Processor Device)
	[    0.408873] ACPI: Added _OSI(3.0 _SCP Extensions)
	[    0.409122] ACPI: Added _OSI(Processor Aggregator Device)
	[    0.409476] ACPI: Added _OSI(Linux-Dell-Video)
	[    0.410058] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
	[    0.410334] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
	[    0.491373] ACPI: 1 ACPI AML tables successfully acquired and loaded
	[    0.506610] ACPI: Interpreter enabled
	[    0.506855] ACPI: Using GIC for interrupt routing
	[    0.507529] ACPI: MCFG table detected, 1 entries
	[    0.562419] ARMH0011:00: ttyAMA0 at MMIO 0x9000000 (irq = 4, base_baud = 0) is a SBSA
	[    0.635348] printk: console [ttyAMA0] enabled
	[    0.671533] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
	[    0.672857] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
	[    0.680379] acpi PNP0A08:00: _OSC: platform does not support [LTR]
	[    0.683111] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]
	[    0.688777] acpi PNP0A08:00: ECAM area [mem 0x4010000000-0x401fffffff] reserved by PNP0C02:00
	[    0.689904] acpi PNP0A08:00: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
	[    0.691879] Remapped I/O 0x000000003eff0000 to [io  0x0000-0xffff window]
	[    0.695715] PCI host bridge to bus 0000:00
	[    0.696261] pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
	[    0.697055] pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
	[    0.697735] pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
	[    0.698606] pci_bus 0000:00: root bus resource [bus 00-ff]
	[    0.700266] pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
	[    0.706988] ACPI: PCI Interrupt Link [GSI0] (IRQs *35)
	[    0.707965] ACPI: PCI Interrupt Link [GSI1] (IRQs *36)
	[    0.708661] ACPI: PCI Interrupt Link [GSI2] (IRQs *37)
	[    0.709336] ACPI: PCI Interrupt Link [GSI3] (IRQs *38)
	[    0.721505] vgaarb: loaded
	[    0.723261] SCSI subsystem initialized
	[    0.725065] libata version 3.00 loaded.
	[    0.726270] ACPI: bus type USB registered
	[    0.727346] usbcore: registered new interface driver usbfs
	[    0.728223] usbcore: registered new interface driver hub
	[    0.729326] usbcore: registered new device driver usb
	[    0.732056] pps_core: LinuxPPS API ver. 1 registered
	[    0.732580] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
	[    0.733803] PTP clock support registered
	[    0.734781] EDAC MC: Ver: 3.0.0
	[    0.739155] Registered efivars operations
	[    0.752186] FPGA manager framework
	[    0.753453] Advanced Linux Sound Architecture Driver Initialized.
	[    0.767808] clocksource: Switched to clocksource arch_sys_counter
	[    0.769435] VFS: Disk quotas dquot_6.6.0
	[    0.770090] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
	[    0.772939] *** VALIDATE hugetlbfs ***
	[    0.775509] pnp: PnP ACPI init
	[    0.779262] system 00:00: [mem 0x4010000000-0x401fffffff window] could not be reserved
	[    0.780474] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
	[    0.780648] pnp: PnP ACPI: found 1 devices
	[    0.814296] NET: Registered protocol family 2
	[    0.820604] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes)
	[    0.821551] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
	[    0.822567] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
	[    0.823490] TCP: Hash tables configured (established 8192 bind 8192)
	[    0.826650] UDP hash table entries: 512 (order: 2, 16384 bytes)
	[    0.827508] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
	[    0.829971] NET: Registered protocol family 1
	[    0.846727] RPC: Registered named UNIX socket transport module.
	[    0.847379] RPC: Registered udp transport module.
	[    0.848334] RPC: Registered tcp transport module.
	[    0.848818] RPC: Registered tcp NFSv4.1 backchannel transport module.
	[    0.849786] PCI: CLS 0 bytes, default 64
	[    0.853671] Unpacking initramfs...
	[    6.993882] Freeing initrd memory: 123392K
	[    6.996833] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 1 counters available
	[    6.997772] kvm [1]: HYP mode not available
	[    7.699500] Initialise system trusted keyrings
	[    7.701698] workingset: timestamp_bits=44 max_order=18 bucket_order=0
	[    7.734096] squashfs: version 4.0 (2009/01/31) Phillip Lougher
	[    7.742467] NFS: Registering the id_resolver key type
	[    7.743404] Key type id_resolver registered
	[    7.744455] Key type id_legacy registered
	[    7.745321] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
	[    7.747602] 9p: Installing v9fs 9p2000 file system support
	[    7.778884] Key type asymmetric registered
	[    7.779383] Asymmetric key parser 'x509' registered
	[    7.780548] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
	[    7.781375] io scheduler mq-deadline registered
	[    7.781899] io scheduler kyber registered
	[    7.809878] pl061_gpio ARMH0061:00: PL061 GPIO chip @0x0000000009030000 registered
	[    7.820983] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
	[    7.822495] ACPI: Power Button [PWRB]
	[    7.829682] EINJ: EINJ table not found.
	[    7.893411] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
	[    7.902202] SuperH (H)SCI(F) driver initialized
	[    7.904102] msm_serial: driver initialized
	[    7.908209] cacheinfo: Unable to detect cache hierarchy for CPU 0
	[    7.940712] loop: module loaded
	[    7.957364] libphy: Fixed MDIO Bus: probed
	[    7.959166] tun: Universal TUN/TAP device driver, 1.6
	[    7.962432] thunder_xcv, ver 1.0
	[    7.962986] thunder_bgx, ver 1.0
	[    7.963542] nicpf, ver 1.0
	[    7.965950] hclge is initializing
	[    7.966402] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
	[    7.967095] hns3: Copyright (c) 2017 Huawei Corporation.
	[    7.968228] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
	[    7.968792] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
	[    7.969591] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
	[    7.970258] igb: Copyright (c) 2007-2014 Intel Corporation.
	[    7.971023] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
	[    7.971977] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
	[    7.973720] sky2: driver version 1.30
	[    7.976724] VFIO - User Level meta-driver version: 0.3
	[    7.988959] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
	[    7.989976] ehci-pci: EHCI PCI platform driver
	[    7.991065] ehci-platform: EHCI generic platform driver
	[    7.992716] ehci-orion: EHCI orion driver
	[    7.993799] ehci-exynos: EHCI EXYNOS driver
	[    7.994893] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
	[    7.995615] ohci-pci: OHCI PCI platform driver
	[    7.996497] ohci-platform: OHCI generic platform driver
	[    7.997352] ohci-exynos: OHCI EXYNOS driver
	[    7.999395] usbcore: registered new interface driver usb-storage
	[    8.013108] rtc-efi rtc-efi: registered as rtc0
	[    8.016099] i2c /dev entries driver
	[    8.031422] sdhci: Secure Digital Host Controller Interface driver
	[    8.032163] sdhci: Copyright(c) Pierre Ossman
	[    8.034139] Synopsys Designware Multimedia Card Interface Driver
	[    8.037333] sdhci-pltfm: SDHCI platform and OF driver helper
	[    8.042220] ledtrig-cpu: registered to indicate activity on CPUs
	[    8.049014] usbcore: registered new interface driver usbhid
	[    8.049565] usbhid: USB HID core driver
	[    8.062947] NET: Registered protocol family 17
	[    8.065201] 9pnet: Installing 9P2000 support
	[    8.065961] Key type dns_resolver registered
	[    8.069421] registered taskstats version 1
	[    8.069864] Loading compiled-in X.509 certificates
	[    8.075662] rtc-efi rtc-efi: setting system clock to 2019-08-16T07:48:26 UTC (1565941706)
	[    8.079525] ALSA device list:
	[    8.080167]   No soundcards found.
	[    8.478229] Freeing unused kernel memory: 1344K
	[    8.480677] Run /init as init process
	[    9.767007] random: sshd: uninitialized urandom read (32 bytes read)
	estuary:/$

Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---

v1- > v2:
* rebased on https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
 drivers/gpio/gpio-pl061.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
  *
  * Data sheet: ARM DDI 0190B, September 2000
  */
+#include <linux/acpi.h>
 #include <linux/spinlock.h>
 #include <linux/errno.h>
 #include <linux/init.h>
@@ -24,6 +25,9 @@
 #include <linux/pinctrl/consumer.h>
 #include <linux/pm.h>
 
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
 #define GPIODIR 0x400
 #define GPIOIS  0x404
 #define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
 	if (ret)
 		return ret;
 
+	if (has_acpi_companion(dev))
+		acpi_gpiochip_request_interrupts(&pl061->gc);
+
 	amba_set_drvdata(adev, pl061);
 	dev_info(dev, "PL061 GPIO chip registered\n");
 
-- 
2.8.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-16  9:35 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
	robh+dt, linux-arm-kernel
In-Reply-To: <20190814133322.dawzv3ityakxtqs4@flea>

On Wed, Aug 14, 2019 at 03:33:22PM +0200, Maxime Ripard wrote:
> On Wed, Aug 14, 2019 at 03:17:41PM +0200, Corentin Labbe wrote:
> > On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> > > On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > >
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > >  arch/arm64/boot/dts/allwinner/Makefile        |  1 +
> > > >  .../sun50i-h6-pine-h64-modelA-eval.dts        | 26 +++++++++++++++++++
> > > >  2 files changed, 27 insertions(+)
> > > >  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > > index f6db0611cb85..9a02166cbf72 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > > >  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > > >  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > > >  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > new file mode 100644
> > > > index 000000000000..d8ff02747efe
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > @@ -0,0 +1,26 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > > +/*
> > > > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > + */
> > > > +
> > > > +#include "sun50i-h6-pine-h64.dts"
> > > > +
> > > > +/ {
> > > > +	model = "Pine H64 model A evaluation board";
> > > > +	compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > > > +
> > > > +	reg_gmac_3v3: gmac-3v3 {
> > > > +		compatible = "regulator-fixed";
> > > > +		regulator-name = "vcc-gmac-3v3";
> > > > +		regulator-min-microvolt = <3300000>;
> > > > +		regulator-max-microvolt = <3300000>;
> > > > +		startup-delay-us = <100000>;
> > > > +		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > > > +		enable-active-high;
> > > > +	};
> > > > +
> > > > +};
> > > > +
> > > > +&emac {
> > > > +	phy-supply = <&reg_gmac_3v3>;
> > > > +};
> > >
> > > I might be missing some context here, but I'm pretty sure that the
> > > initial intent of the pine h64 DTS was to support the model A all
> > > along.
> > >
> >
> > The regulator changed between modelA and B.
> > See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
> 
> I'm not sure what your point is, but mine is that everything about the
> model A should be in sun50i-h6-pine-h64.dts.
> 

model A and B are different enough for distinct dtb, (see sub-thread on HDMI difference for an other difference than PHY regulator)
And clearly, the current dtb is for model B.

So do you mean that we need to create a new dtb for model B ? (and hack the current back to model A ?)

Regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-16  9:37 UTC (permalink / raw)
  To: Claudiu Beznea, Thierry Reding
  Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-1-uwe@kleine-koenig.org>

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
 drivers/pwm/pwm-atmel.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 42fe7bc043a8..1ddb93db9627 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -7,6 +7,16 @@
  *
  * Reference manual for "atmel,at91sam9rl-pwm":
  *   http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
+ *
+ * Limitations:
+ * - Periods start with the inactive level.
+ * - Hardware has to be stopped in general to update settings.
+ *
+ * Software bugs/possible improvements:
+ * - When atmel_pwm_apply() is called with state->enabled=false a change in
+ *   state->polarity isn't honored.
+ * - Instead of sleeping to wait for a completed period, the interrupt
+ *   functionality could be used.
  */
 
 #include <linux/clk.h>
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 01/10] PCI: designware-ep: Add multiple PFs support for DWC
From: Andrew Murray @ 2019-08-16  9:44 UTC (permalink / raw)
  To: Xiaowei Bao
  Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
	arnd@arndb.de, gregkh@linuxfoundation.org, jingoohan1@gmail.com,
	Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	kishon@ti.com, M.h. Lian, devicetree@vger.kernel.org,
	gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB3299396885AC4B54B9E8D0AEF5AF0@AM5PR04MB3299.eurprd04.prod.outlook.com>

On Fri, Aug 16, 2019 at 02:55:41AM +0000, Xiaowei Bao wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月15日 19:32
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: jingoohan1@gmail.com; gustavo.pimentel@synopsys.com;
> > bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> > M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> > Roy Zang <roy.zang@nxp.com>; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH 01/10] PCI: designware-ep: Add multiple PFs support for
> > DWC
> > 
> > On Thu, Aug 15, 2019 at 04:37:07PM +0800, Xiaowei Bao wrote:
> > > Add multiple PFs support for DWC, different PF have different config
> > > space, we use pf-offset property which get from the DTS to access the
> > > different pF config space.
> > 
> > Thanks for the patch. I haven't seen a cover letter for this series, is there one
> > missing?
> Maybe I miss, I will add you to review next time, thanks a lot for your comments.
> > 
> > 
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > >  drivers/pci/controller/dwc/pcie-designware-ep.c |  97
> > +++++++++++++---------
> > >  drivers/pci/controller/dwc/pcie-designware.c    | 105
> > ++++++++++++++++++++++--
> > >  drivers/pci/controller/dwc/pcie-designware.h    |  10 ++-
> > >  include/linux/pci-epc.h                         |   1 +
> > >  4 files changed, 164 insertions(+), 49 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 2bf5a35..75e2955 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -19,12 +19,14 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > >  	pci_epc_linkup(epc);
> > >  }
> > >
> > > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> > bar,
> > > -				   int flags)
> > > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > > +				   enum pci_barno bar, int flags)
> > >  {
> > >  	u32 reg;
> > > +	struct pci_epc *epc = pci->ep.epc;
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >
> > > -	reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > +	reg = pf_base + PCI_BASE_ADDRESS_0 + (4 * bar);
> > 
> > I think I'd rather see this arithmetic (and the one for determining pf_base)
> > inside a macro or inline header function. This would make this code more
> > readable and reduce the chances of an error by avoiding duplication of code.
> > 
> > For example look at cdns_pcie_ep_fn_writeb and
> > ROCKCHIP_PCIE_EP_FUNC_BASE for examples of other EP drivers that do
> > this.
> Agree, this looks fine, thanks a lot for your comments, I will use this way to access
> the registers in next version patch.
> > 
> > 
> > >  	dw_pcie_dbi_ro_wr_en(pci);
> > >  	dw_pcie_writel_dbi2(pci, reg, 0x0);
> > >  	dw_pcie_writel_dbi(pci, reg, 0x0);
> > > @@ -37,7 +39,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie
> > > *pci, enum pci_barno bar,
> > >
> > >  void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)  {
> > > -	__dw_pcie_ep_reset_bar(pci, bar, 0);
> > > +	u8 func_no, funcs;
> > > +
> > > +	funcs = pci->ep.epc->max_functions;
> > > +
> > > +	for (func_no = 0; func_no < funcs; func_no++)
> > > +		__dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
> > >  }
> > >
> > >  static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
> > > @@ -78,28 +85,29 @@ static int dw_pcie_ep_write_header(struct pci_epc
> > > *epc, u8 func_no,  {
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >
> > >  	dw_pcie_dbi_ro_wr_en(pci);
> > > -	dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
> > > -	dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
> > > -	dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> > > -	dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
> > > -	dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
> > > +	dw_pcie_writew_dbi(pci, pf_base + PCI_VENDOR_ID, hdr->vendorid);
> > > +	dw_pcie_writew_dbi(pci, pf_base + PCI_DEVICE_ID, hdr->deviceid);
> > > +	dw_pcie_writeb_dbi(pci, pf_base + PCI_REVISION_ID, hdr->revid);
> > > +	dw_pcie_writeb_dbi(pci, pf_base + PCI_CLASS_PROG, hdr->progif_code);
> > > +	dw_pcie_writew_dbi(pci, pf_base + PCI_CLASS_DEVICE,
> > >  			   hdr->subclass_code | hdr->baseclass_code << 8);
> > > -	dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
> > > +	dw_pcie_writeb_dbi(pci, pf_base + PCI_CACHE_LINE_SIZE,
> > >  			   hdr->cache_line_size);
> > > -	dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
> > > +	dw_pcie_writew_dbi(pci, pf_base + PCI_SUBSYSTEM_VENDOR_ID,
> > >  			   hdr->subsys_vendor_id);
> > > -	dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
> > > -	dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
> > > +	dw_pcie_writew_dbi(pci, pf_base + PCI_SUBSYSTEM_ID,
> > hdr->subsys_id);
> > > +	dw_pcie_writeb_dbi(pci, pf_base + PCI_INTERRUPT_PIN,
> > >  			   hdr->interrupt_pin);
> > >  	dw_pcie_dbi_ro_wr_dis(pci);
> > >
> > >  	return 0;
> > >  }
> > >
> > > -static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum
> > pci_barno bar,
> > > -				  dma_addr_t cpu_addr,
> > > +static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > > +				  enum pci_barno bar, dma_addr_t cpu_addr,
> > >  				  enum dw_pcie_as_type as_type)
> > >  {
> > >  	int ret;
> > > @@ -112,7 +120,7 @@ static int dw_pcie_ep_inbound_atu(struct
> > dw_pcie_ep *ep, enum pci_barno bar,
> > >  		return -EINVAL;
> > >  	}
> > >
> > > -	ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
> > > +	ret = dw_pcie_prog_inbound_atu(pci, func_no, free_win, bar,
> > > +cpu_addr,
> > >  				       as_type);
> > >  	if (ret < 0) {
> > >  		dev_err(pci->dev, "Failed to program IB window\n"); @@ -125,7
> > > +133,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
> > enum pci_barno bar,
> > >  	return 0;
> > >  }
> > >
> > > -static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t
> > > phys_addr,
> > > +static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > > +				   phys_addr_t phys_addr,
> > >  				   u64 pci_addr, size_t size)
> > >  {
> > >  	u32 free_win;
> > > @@ -137,8 +146,8 @@ static int dw_pcie_ep_outbound_atu(struct
> > dw_pcie_ep *ep, phys_addr_t phys_addr,
> > >  		return -EINVAL;
> > >  	}
> > >
> > > -	dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
> > > -				  phys_addr, pci_addr, size);
> > > +	dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win,
> > PCIE_ATU_TYPE_MEM,
> > > +				     phys_addr, pci_addr, size);
> > >
> > >  	set_bit(free_win, ep->ob_window_map);
> > >  	ep->outbound_addr[free_win] = phys_addr; @@ -154,7 +163,7 @@
> > static
> > > void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no,
> > >  	enum pci_barno bar = epf_bar->barno;
> > >  	u32 atu_index = ep->bar_to_atu[bar];
> > >
> > > -	__dw_pcie_ep_reset_bar(pci, bar, epf_bar->flags);
> > > +	__dw_pcie_ep_reset_bar(pci, func_no, bar, epf_bar->flags);
> > >
> > >  	dw_pcie_disable_atu(pci, atu_index, DW_PCIE_REGION_INBOUND);
> > >  	clear_bit(atu_index, ep->ib_window_map); @@ -170,14 +179,16 @@
> > > static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
> > >  	size_t size = epf_bar->size;
> > >  	int flags = epf_bar->flags;
> > >  	enum dw_pcie_as_type as_type;
> > > -	u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > > +	u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar) + pf_base;
> > >
> > >  	if (!(flags & PCI_BASE_ADDRESS_SPACE))
> > >  		as_type = DW_PCIE_AS_MEM;
> > >  	else
> > >  		as_type = DW_PCIE_AS_IO;
> > >
> > > -	ret = dw_pcie_ep_inbound_atu(ep, bar, epf_bar->phys_addr, as_type);
> > > +	ret = dw_pcie_ep_inbound_atu(ep, func_no, bar,
> > > +				     epf_bar->phys_addr, as_type);
> > >  	if (ret)
> > >  		return ret;
> > >
> > > @@ -235,7 +246,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc
> > *epc, u8 func_no,
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >
> > > -	ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> > > +	ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > >  	if (ret) {
> > >  		dev_err(pci->dev, "Failed to enable address\n");
> > >  		return ret;
> > > @@ -248,12 +259,13 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> > > *epc, u8 func_no)  {
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u32 val, reg;
> > >
> > >  	if (!ep->msi_cap)
> > >  		return -EINVAL;
> > >
> > > -	reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > +	reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > >  	val = dw_pcie_readw_dbi(pci, reg);
> > >  	if (!(val & PCI_MSI_FLAGS_ENABLE))
> > >  		return -EINVAL;
> > > @@ -267,12 +279,13 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> > > *epc, u8 func_no, u8 interrupts)  {
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u32 val, reg;
> > >
> > >  	if (!ep->msi_cap)
> > >  		return -EINVAL;
> > >
> > > -	reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > +	reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > >  	val = dw_pcie_readw_dbi(pci, reg);
> > >  	val &= ~PCI_MSI_FLAGS_QMASK;
> > >  	val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -287,12 +300,13
> > > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)  {
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u32 val, reg;
> > >
> > >  	if (!ep->msix_cap)
> > >  		return -EINVAL;
> > >
> > > -	reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > +	reg = ep->msix_cap + pf_base + PCI_MSIX_FLAGS;
> > >  	val = dw_pcie_readw_dbi(pci, reg);
> > >  	if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > >  		return -EINVAL;
> > > @@ -306,12 +320,13 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> > > *epc, u8 func_no, u16 interrupts)  {
> > >  	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u32 val, reg;
> > >
> > >  	if (!ep->msix_cap)
> > >  		return -EINVAL;
> > >
> > > -	reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > +	reg = ep->msix_cap + pf_base + PCI_MSIX_FLAGS;
> > >  	val = dw_pcie_readw_dbi(pci, reg);
> > >  	val &= ~PCI_MSIX_FLAGS_QSIZE;
> > >  	val |= interrupts;
> > > @@ -400,6 +415,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> > *ep, u8 func_no,
> > >  	unsigned int aligned_offset;
> > >  	u16 msg_ctrl, msg_data;
> > >  	u32 msg_addr_lower, msg_addr_upper, reg;
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u64 msg_addr;
> > >  	bool has_upper;
> > >  	int ret;
> > > @@ -408,19 +424,19 @@ int dw_pcie_ep_raise_msi_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > >  		return -EINVAL;
> > >
> > >  	/* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > > -	reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > +	reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > >  	msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > >  	has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > > -	reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> > > +	reg = ep->msi_cap + pf_base + PCI_MSI_ADDRESS_LO;
> > >  	msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > >  	if (has_upper) {
> > > -		reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> > > +		reg = ep->msi_cap + pf_base + PCI_MSI_ADDRESS_HI;
> > >  		msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > > -		reg = ep->msi_cap + PCI_MSI_DATA_64;
> > > +		reg = ep->msi_cap + pf_base + PCI_MSI_DATA_64;
> > >  		msg_data = dw_pcie_readw_dbi(pci, reg);
> > >  	} else {
> > >  		msg_addr_upper = 0;
> > > -		reg = ep->msi_cap + PCI_MSI_DATA_32;
> > > +		reg = ep->msi_cap + pf_base + PCI_MSI_DATA_32;
> > >  		msg_data = dw_pcie_readw_dbi(pci, reg);
> > >  	}
> > >  	aligned_offset = msg_addr_lower & (epc->mem->page_size - 1); @@
> > > -439,7 +455,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > > u8 func_no,  }
> > >
> > >  int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > -			     u16 interrupt_num)
> > > +			      u16 interrupt_num)
> > >  {
> > >  	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >  	struct pci_epc *epc = ep->epc;
> > > @@ -447,16 +463,17 @@ int dw_pcie_ep_raise_msix_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > >  	u32 bar_addr_upper, bar_addr_lower;
> > >  	u32 msg_addr_upper, msg_addr_lower;
> > >  	u32 reg, msg_data, vec_ctrl;
> > > +	u32 pf_base = func_no * epc->pf_offset;
> > >  	u64 tbl_addr, msg_addr, reg_u64;
> > >  	void __iomem *msix_tbl;
> > >  	int ret;
> > >
> > > -	reg = ep->msix_cap + PCI_MSIX_TABLE;
> > > +	reg = ep->msix_cap + pf_base + PCI_MSIX_TABLE;
> > >  	tbl_offset = dw_pcie_readl_dbi(pci, reg);
> > >  	bir = (tbl_offset & PCI_MSIX_TABLE_BIR);
> > >  	tbl_offset &= PCI_MSIX_TABLE_OFFSET;
> > >
> > > -	reg = PCI_BASE_ADDRESS_0 + (4 * bir);
> > > +	reg = PCI_BASE_ADDRESS_0 + pf_base + (4 * bir);
> > >  	bar_addr_upper = 0;
> > >  	bar_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > >  	reg_u64 = (bar_addr_lower & PCI_BASE_ADDRESS_MEM_TYPE_MASK);
> > @@
> > > -592,13 +609,17 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > >  	ep->epc = epc;
> > >  	epc_set_drvdata(epc, ep);
> > >
> > > -	if (ep->ops->ep_init)
> > > -		ep->ops->ep_init(ep);
> > > -
> > >  	ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
> > >  	if (ret < 0)
> > >  		epc->max_functions = 1;
> > >
> > > +	ret = of_property_read_u32(np, "pf-offset", &epc->pf_offset);
> > > +	if (ret < 0)
> > > +		epc->pf_offset = 0;
> > 
> > Bad things will likely happen if max_functions > 1 and pf-offset isn't set.
> > I think the driver should bail in this situation. It would be very easy for
> > someone to misconfigure this.
> Yes, you are right, but if the max-functions have defined in DTS, require the pf-offset
> must define in DTS, I am not sure the correct value of pf-offsetfor other platforms, 
> so I think the max-functions and pf-offset should not have the dependence.

Yes you're correct. I hadn't really thought about this beyond layerscape. It's
also possible that other hardware could support multiple PFs without relying on
an offset and perhaps employ some other mechanism to access different
functions. So whilst this property can be optional for the majority of dwc
controllers - it must be set and cannot be zero for layerscape.

Perhaps inside ls_pcie_ep_init, you can set max_functions to 1 if pf_offset is
0 and print a WARN to explain why? (Or ls_pcie_ep_init returns failure and
dw_pcie_ep_init checks it and bails).

The assumption is being made here that future dw controllers may also use
pf_offset (is this likely?) - otherwise why is this in pcie-designware-ep.c and
not pci-layerscape-ep.c and why is this value not just hard-coded for lp?


> even though I didn't define pf-offset when I defined max-functions, the pf-offset is 0, 
> the DWC ep driver can continue run the progress of INIT but not return, of course, 
> thus the PF1 will not work, I don't know which way is better.
> > 
> > 
> > > +
> > > +	if (ep->ops->ep_init)
> > > +		ep->ops->ep_init(ep);
> > > +
> > >  	ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
> > >  				 ep->page_size);
> > >  	if (ret < 0) {
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index 7d25102..c99cee4 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -158,6 +158,43 @@ static void dw_pcie_writel_ob_unroll(struct
> > dw_pcie *pci, u32 index, u32 reg,
> > >  	dw_pcie_writel_atu(pci, offset + reg, val);  }
> > >
> > > +static void dw_pcie_prog_ep_outbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > +						int index, int type,
> > > +						u64 cpu_addr, u64 pci_addr,
> > > +						u32 size)
> > > +{
> > > +	u32 retries, val;
> > > +
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
> > > +				 lower_32_bits(cpu_addr));
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
> > > +				 upper_32_bits(cpu_addr));
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LIMIT,
> > > +				 lower_32_bits(cpu_addr + size - 1));
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
> > > +				 lower_32_bits(pci_addr));
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> > > +				 upper_32_bits(pci_addr));
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > > +				 type | PCIE_ATU_FUNC_NUM(func_no));
> > 
> > With the exception of this line, the rest of this function is identical to
> > dw_pcie_prog_outbound_atu_unroll.
> Yes, I can integrate the same code, but I think we'd better use the different outbound 
> window set function between RC and EP, because the RC don't need the func_num parameter.



> > 
> > > +	dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > +				 PCIE_ATU_ENABLE);
> > > +
> > > +	/*
> > > +	 * Make sure ATU enable takes effect before any subsequent config
> > > +	 * and I/O accesses.
> > > +	 */
> > > +	for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> > > +		val = dw_pcie_readl_ob_unroll(pci, index,
> > > +					      PCIE_ATU_UNR_REGION_CTRL2);
> > > +		if (val & PCIE_ATU_ENABLE)
> > > +			return;
> > > +
> > > +		mdelay(LINK_WAIT_IATU);
> > > +	}
> > > +	dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > > +
> > >  static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int
> > index,
> > >  					     int type, u64 cpu_addr,
> > >  					     u64 pci_addr, u32 size)
> > > @@ -194,6 +231,51 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > >  	dev_err(pci->dev, "Outbound iATU is not being enabled\n");  }
> > >
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > +				  int type, u64 cpu_addr, u64 pci_addr,
> > > +				  u32 size)
> > > +{
> > > +	u32 retries, val;
> > > +
> > > +	if (pci->ops->cpu_addr_fixup)
> > > +		cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> > > +
> > > +	if (pci->iatu_unroll_enabled) {
> > > +		dw_pcie_prog_ep_outbound_atu_unroll(pci, func_no, index, type,
> > > +						    cpu_addr, pci_addr, size);
> > > +		return;
> > > +	}
> > > +
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> > > +			   PCIE_ATU_REGION_OUTBOUND | index);
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE,
> > > +			   lower_32_bits(cpu_addr));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE,
> > > +			   upper_32_bits(cpu_addr));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT,
> > > +			   lower_32_bits(cpu_addr + size - 1));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET,
> > > +			   lower_32_bits(pci_addr));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET,
> > > +			   upper_32_bits(pci_addr));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> > > +			   PCIE_ATU_FUNC_NUM(func_no));
> > 
> > The same here, this is identical to dw_pcie_prog_outbound_atu with the
> > exception of this line.
> > 
> > Is there a way you can avoid all of this duplicated code?
> As above, I can integrate the same code, but I keep to think the different outbound 
> Window set function should be used between RC and EP.

Or, is it possible to keep and use the existing functions, but use them
differently, e.g:


@@ -137,8 +146,8 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t phys_addr,
                return -EINVAL;
        }

-       dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
-                                 phys_addr, pci_addr, size);
+       dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM_FUNC(func_no),
+                                    phys_addr, pci_addr, size);

        set_bit(free_win, ep->ob_window_map);
        ep->outbound_addr[free_win] = phys_addr;


Supported with:

#define PCIE_ATU_TYPE_MEM               0x0
#define PCIE_ATU_TYPE_MEM_FUNC(func_no) (PCIE_ATU_TYPE_MEM | PCIE_ATU_FUNC_NUM(func_no))


This is just a suggestion, but I'm keen to avoid code duplication.

> > 
> > Thanks,
> > 
> > Andrew Murray
> > 
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> > > +
> > > +	/*
> > > +	 * Make sure ATU enable takes effect before any subsequent config
> > > +	 * and I/O accesses.
> > > +	 */
> > > +	for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> > > +		val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> > > +		if (val & PCIE_ATU_ENABLE)
> > > +			return;
> > > +
> > > +		mdelay(LINK_WAIT_IATU);
> > > +	}
> > > +	dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > > +
> > >  void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > >  			       u64 cpu_addr, u64 pci_addr, u32 size)  { @@ -252,8
> > +334,8
> > > @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, u32 index,
> > u32 reg,
> > >  	dw_pcie_writel_atu(pci, offset + reg, val);  }
> > >
> > > -static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> > > -					   int bar, u64 cpu_addr,
> > > +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > +					   int index, int bar, u64 cpu_addr,
> > >  					   enum dw_pcie_as_type as_type)  {
> > >  	int type;
> > > @@ -275,8 +357,10 @@ static int dw_pcie_prog_inbound_atu_unroll(struct
> > dw_pcie *pci, int index,
> > >  		return -EINVAL;
> > >  	}
> > >
> > > -	dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > type);
> > > +	dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > type |
> > > +				 PCIE_ATU_FUNC_NUM(func_no));
> > >  	dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > +				 PCIE_ATU_FUNC_NUM_MATCH_EN |
> > >  				 PCIE_ATU_ENABLE |
> > >  				 PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > >
> > > @@ -297,14 +381,15 @@ static int
> > dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> > >  	return -EBUSY;
> > >  }
> > >
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > -			     u64 cpu_addr, enum dw_pcie_as_type as_type)
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > +			     int bar, u64 cpu_addr,
> > > +			     enum dw_pcie_as_type as_type)
> > >  {
> > >  	int type;
> > >  	u32 retries, val;
> > >
> > >  	if (pci->iatu_unroll_enabled)
> > > -		return dw_pcie_prog_inbound_atu_unroll(pci, index, bar,
> > > +		return dw_pcie_prog_inbound_atu_unroll(pci, func_no, index, bar,
> > >  						       cpu_addr, as_type);
> > >
> > >  	dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> > PCIE_ATU_REGION_INBOUND |
> > > @@ -323,9 +408,11 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie
> > *pci, int index, int bar,
> > >  		return -EINVAL;
> > >  	}
> > >
> > > -	dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type);
> > > -	dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE
> > > -			   | PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> > > +			   PCIE_ATU_FUNC_NUM(func_no));
> > > +	dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE |
> > > +			   PCIE_ATU_FUNC_NUM_MATCH_EN |
> > > +			   PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > >
> > >  	/*
> > >  	 * Make sure ATU enable takes effect before any subsequent config
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index ffed084..2b291e8 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -71,9 +71,11 @@
> > >  #define PCIE_ATU_TYPE_IO		0x2
> > >  #define PCIE_ATU_TYPE_CFG0		0x4
> > >  #define PCIE_ATU_TYPE_CFG1		0x5
> > > +#define PCIE_ATU_FUNC_NUM(pf)           (pf << 20)
> > >  #define PCIE_ATU_CR2			0x908
> > >  #define PCIE_ATU_ENABLE			BIT(31)
> > >  #define PCIE_ATU_BAR_MODE_ENABLE	BIT(30)
> > > +#define PCIE_ATU_FUNC_NUM_MATCH_EN      BIT(19)
> > >  #define PCIE_ATU_LOWER_BASE		0x90C
> > >  #define PCIE_ATU_UPPER_BASE		0x910
> > >  #define PCIE_ATU_LIMIT			0x914
> > > @@ -265,8 +267,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> > >  			       int type, u64 cpu_addr, u64 pci_addr,
> > >  			       u32 size);
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > -			     u64 cpu_addr, enum dw_pcie_as_type as_type);
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > +				  int type, u64 cpu_addr, u64 pci_addr,
> > > +				  u32 size);
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > +			     int bar, u64 cpu_addr,
> > > +			     enum dw_pcie_as_type as_type);
> > >  void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> > >  			 enum dw_pcie_region_type type);
> > >  void dw_pcie_setup(struct dw_pcie *pci); diff --git
> > > a/include/linux/pci-epc.h b/include/linux/pci-epc.h index
> > > f641bad..fc2feee 100644
> > > --- a/include/linux/pci-epc.h
> > > +++ b/include/linux/pci-epc.h
> > > @@ -96,6 +96,7 @@ struct pci_epc {
> > >  	const struct pci_epc_ops	*ops;
> > >  	struct pci_epc_mem		*mem;
> > >  	u8				max_functions;
> > > +	u32				pf_offset;

Also pf_offset is an implementation detail needed only by the driver to
calculate where the PF is - it doesn't seem right that we share this with the
EP controller framework (whereas max_functions is used as a bounds check
for func_no in the framework calls).

I'd suggest that pf_offset is moved to a dwc structure, perhaps dw_pcie_ep?

Thanks,

Andrew Murray

> > >  	struct config_group		*group;
> > >  	/* spinlock to protect against concurrent access of EP controller */
> > >  	spinlock_t			lock;
> > > --
> > > 2.9.5
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&amp;data=02%
> > 7C0
> > >
> > 1%7Cxiaowei.bao%40nxp.com%7C0e39168f6f144db6840308d721742040%7
> > C686ea1d
> > >
> > 3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637014654998524452&amp;sd
> > ata=bP7eh
> > > cjlGXCMVFE2b4f12Q6fGV7lQ%2F5i9qIi9FoPlbI%3D&amp;reserved=0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v5 02/18] dt-bindings: thermal: add binding document for h6 thermal controller
From: Maxime Ripard @ 2019-08-16  9:47 UTC (permalink / raw)
  To: Frank Lee
  Cc: Mark Rutland, devicetree, Linux PM, Greg Kroah-Hartman,
	Daniel Lezcano, Linux Kernel Mailing List, Eduardo Valentin,
	Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
	Mauro Carvalho Chehab, rui.zhang, David Miller, Linux ARM
In-Reply-To: <CAEExFWswLiFknVpBEKF9c5yoFvvA4np-ivWYkQLcteYoM8qjfg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3885 bytes --]

On Tue, Aug 13, 2019 at 07:40:44AM +0800, Frank Lee wrote:
> On Mon, Aug 12, 2019 at 4:56 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Aug 10, 2019 at 05:28:13AM +0000, Yangtao Li wrote:
> > > This patch adds binding document for allwinner h6 thermal controller.
> > >
> > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > ---
> > >  .../bindings/thermal/sun8i-thermal.yaml       | 79 +++++++++++++++++++
> > >  1 file changed, 79 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > > new file mode 100644
> > > index 000000000000..e0973199ba3c
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> >
> > We've used so far for the schemas the first compatible to introduce
> > that controller as the filename, we should be consistent here. In that
> > case that would be allwinner,sun8i-a23-ths.yaml
> >
> > > @@ -0,0 +1,79 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/thermal/sun8i-thermal.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Allwinner SUN8I Thermal Controller Device Tree Bindings
> > > +
> > > +maintainers:
> > > +  - Yangtao Li <tiny.windzz@gmail.com>
> > > +
> > > +description: |-
> > > +  This describes the device tree binding for the Allwinner thermal
> > > +  controller which measures the on-SoC temperatures.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - allwinner,sun50i-h6-ths
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  interrupts:
> > > +    maxItems: 1
> > > +
> > > +  resets:
> > > +    maxItems: 1
> > > +
> > > +  clocks:
> > > +    maxItems: 1
> > > +
> > > +  clock-names:
> > > +    const: bus
> > > +
> > > +  "#thermal-sensor-cells":
> > > +    const: 1
> > > +
> > > +  nvmem-cells:
> >
> > You need a maxItems here too
> >
> > > +    description: ths calibrate data
> >
> > What about something like this:
> >
> > Calibration data for the thermal sensor
> >
> > > +
> > > +  nvmem-cell-names:
> > > +    const: calib
> >
> > I'm not sure we need a abbreviation here, calibration would be more
> > explicit
> >
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - reset
> > > +  - clocks
> > > +  - clock-names
> > > +  - interrupts
> > > +  - "#thermal-sensor-cells"
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    ths: ths@5070400 {
> > > +        compatible = "allwinner,sun50i-h6-ths";
> > > +        reg = <0x05070400 0x100>;
> > > +        clocks = <&ccu CLK_BUS_THS>;
> > > +        clock-names = "bus";
> > > +        resets = <&ccu RST_BUS_THS>;
> > > +        interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> >
> > Those examples won't compile.
>
> Emmm, I have some questions about this.
> I added this information and it can be compiled.

With your patch applied,

$ ARCH=arm DT_SCHEMA_FILES=Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml make -j4 dt_binding_check
  CHKDT   Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
  DTC     Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dt.yaml
Error: Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dts:20.28-29 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.lib:299: Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dt.yaml] Error 1
make[1]: *** [/home/max/Work/src/linux/Makefile:1286: dt_binding_check] Error 2
make: *** [/home/max/Work/src/linux/Makefile:179: sub-make] Error 2

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Jernej Škrabec @ 2019-08-16  9:50 UTC (permalink / raw)
  To: linux-sunxi, peron.clem
  Cc: Mark Rutland, devicetree, linux-kernel, Maxime Ripard,
	Chen-Yu Tsai, Rob Herring, clabbe.montjoie, linux-arm-kernel
In-Reply-To: <CAJiuCcfASQriPLMuwuDCn9bU=_8q4jL+KkPo8NmMrrYpOqy2qA@mail.gmail.com>

Dne sreda, 14. avgust 2019 ob 15:28:53 CEST je Clément Péron napisal(a):
> Hi,
> 
> On Wed, 14 Aug 2019 at 15:20, Corentin Labbe <clabbe.montjoie@gmail.com> 
wrote:
> > On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe 
napisal(a):
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > > 
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > > 
> > > I have Model A board which also needs ddc-en-gpios property for HDMI
> > > connector in order for HDMI to work correctly. Otherwise it will just
> > > use 1024x768 resolution. Can you confirm that?
> 
> Schematics Rev A:
> http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
> 
> Rev B:
> http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pd
> f
> 
> There is a DDC_EN on REV A not on REV B
> 
> Regards,
> Clément
> 
> > > Best regards,
> > > Jernej
> > 
> > Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
> > 
> > Could you send me a patch against my future v2 and I could test
> > with/without.

I don't have access to my Model A board currently, but this should suffice:

&connector {
	ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
};

Best regards,
Jernej

> > 
> > Regards
> > 
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Re
> > d.





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH V6 4/4] arm64: dts: imx8mm: Enable cpu-idle driver
From: Daniel Lezcano @ 2019-08-16  9:59 UTC (permalink / raw)
  To: Anson Huang, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
	festevam, tglx, leonard.crestez, daniel.baluta, ping.bai, jun.li,
	l.stach, abel.vesa, ccaione, andrew.smirnov, angus, agx,
	devicetree, linux-arm-kernel, linux-kernel
  Cc: Linux-imx
In-Reply-To: <1565915925-21009-4-git-send-email-Anson.Huang@nxp.com>

On 16/08/2019 02:38, Anson Huang wrote:
> Enable i.MX8MM cpu-idle using generic ARM cpu-idle driver, 2 states
> are supported, details as below:
> 
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
> WFI
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
> 3973
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/name
> cpu-pd-wait
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
> 6647
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>

Hi Anson,

I've applied the patches 1-3 but this one does not apply.

You can either respin it against tip/timers/core and take it through
Shawn's tree. If the later, you can add my Acked-by.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* RE: [PATCH V6 4/4] arm64: dts: imx8mm: Enable cpu-idle driver
From: Anson Huang @ 2019-08-16 10:08 UTC (permalink / raw)
  To: Daniel Lezcano, robh+dt@kernel.org, mark.rutland@arm.com,
	shawnguo@kernel.org, s.hauer@pengutronix.de,
	kernel@pengutronix.de, festevam@gmail.com, tglx@linutronix.de,
	Leonard Crestez, Daniel Baluta, Jacky Bai, Jun Li,
	l.stach@pengutronix.de, Abel Vesa, ccaione@baylibre.com,
	andrew.smirnov@gmail.com, angus@akkea.ca, agx@sigxcpu.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
  Cc: dl-linux-imx
In-Reply-To: <e62d26b9-8c9b-644f-d2b3-485586e07e35@linaro.org>

Hi, Daniel/Shawn

> On 16/08/2019 02:38, Anson Huang wrote:
> > Enable i.MX8MM cpu-idle using generic ARM cpu-idle driver, 2 states
> > are supported, details as below:
> >
> > root@imx8mmevk:~# cat
> /sys/devices/system/cpu/cpu0/cpuidle/state0/name
> > WFI
> > root@imx8mmevk:~# cat
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
> > 3973
> > root@imx8mmevk:~# cat
> /sys/devices/system/cpu/cpu0/cpuidle/state1/name
> > cpu-pd-wait
> > root@imx8mmevk:~# cat
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
> > 6647
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> 
> Hi Anson,
> 
> I've applied the patches 1-3 but this one does not apply.

Thanks.

> 
> You can either respin it against tip/timers/core and take it through Shawn's
> tree. If the later, you can add my Acked-by.

Hi, Shawn
	Can you take this patch and add below Acked-by? It should can be applied to your tree directly.

	Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>

Thanks,
Anson


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox