2018-11-14 08:29:40

by Christoph Hellwig

[permalink] [raw]
Subject: use generic DMA mapping code in powerpc V4

Hi all,

this series switches the powerpc port to use the generic swiotlb and
noncoherent dma ops, and to use more generic code for the coherent
direct mapping, as well as removing a lot of dead code.

As this series is very large and depends on the dma-mapping tree I've
also published a git tree:

git://git.infradead.org/users/hch/misc.git powerpc-dma.4

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4

Changes since v3:
- rebase on the powerpc fixes tree
- add a new patch to actually make the baseline amigaone config
configure without warnings
- only use ZONE_DMA for 64-bit embedded CPUs, on pseries an IOMMU is
always present
- fix compile in mem.c for one configuration
- drop the full npu removal for now, will be resent separately
- a few git bisection fixes

The changes since v1 are to big to list and v2 was not posted in public.



2018-11-14 08:24:41

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 02/34] powerpc: allow NOT_COHERENT_CACHE for amigaone

AMIGAONE select NOT_COHERENT_CACHE, so we better allow it.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/Kconfig.cputype | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index f4e2c5729374..6fedbf349fce 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -412,7 +412,8 @@ config NR_CPUS

config NOT_COHERENT_CACHE
bool
- depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
+ depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || \
+ GAMECUBE_COMMON || AMIGAONE
default n if PPC_47x
default y

--
2.19.1


2018-11-14 08:24:42

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 04/34] powerpc/dma: remove the unused ISA_DMA_THRESHOLD export

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/kernel/setup_32.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 81909600013a..07f7e6aaf104 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -59,7 +59,6 @@ unsigned long ISA_DMA_THRESHOLD;
unsigned int DMA_MODE_READ;
unsigned int DMA_MODE_WRITE;

-EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);

--
2.19.1


2018-11-14 08:24:49

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 06/34] powerpc/dma: split the two __dma_alloc_coherent implementations

The implemementation for the CONFIG_NOT_COHERENT_CACHE case doesn't share
any code with the one for systems with coherent caches. Split it off
and merge it with the helpers in dma-noncoherent.c that have no other
callers.

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 5 -----
arch/powerpc/kernel/dma.c | 14 ++------------
arch/powerpc/mm/dma-noncoherent.c | 15 +++++++--------
arch/powerpc/platforms/44x/warp.c | 2 +-
4 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index f2a4a7142b1e..dacd0f93f2b2 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -39,9 +39,6 @@ extern int dma_nommu_mmap_coherent(struct device *dev,
* to ensure it is consistent.
*/
struct device;
-extern void *__dma_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *handle, gfp_t gfp);
-extern void __dma_free_coherent(size_t size, void *vaddr);
extern void __dma_sync(void *vaddr, size_t size, int direction);
extern void __dma_sync_page(struct page *page, unsigned long offset,
size_t size, int direction);
@@ -52,8 +49,6 @@ extern unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr);
* Cache coherent cores.
*/

-#define __dma_alloc_coherent(dev, gfp, size, handle) NULL
-#define __dma_free_coherent(size, addr) ((void)0)
#define __dma_sync(addr, size, rw) ((void)0)
#define __dma_sync_page(pg, off, sz, rw) ((void)0)

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 6551685a4ed0..d6deb458bb91 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -62,18 +62,12 @@ static int dma_nommu_dma_supported(struct device *dev, u64 mask)
#endif
}

+#ifndef CONFIG_NOT_COHERENT_CACHE
void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag,
unsigned long attrs)
{
void *ret;
-#ifdef CONFIG_NOT_COHERENT_CACHE
- ret = __dma_alloc_coherent(dev, size, dma_handle, flag);
- if (ret == NULL)
- return NULL;
- *dma_handle += get_dma_offset(dev);
- return ret;
-#else
struct page *page;
int node = dev_to_node(dev);
#ifdef CONFIG_FSL_SOC
@@ -110,19 +104,15 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
*dma_handle = __pa(ret) + get_dma_offset(dev);

return ret;
-#endif
}

void __dma_nommu_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
unsigned long attrs)
{
-#ifdef CONFIG_NOT_COHERENT_CACHE
- __dma_free_coherent(size, vaddr);
-#else
free_pages((unsigned long)vaddr, get_order(size));
-#endif
}
+#endif /* !CONFIG_NOT_COHERENT_CACHE */

static void *dma_nommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag,
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index b6e7b5952ab5..e955539686a4 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -29,7 +29,7 @@
#include <linux/string.h>
#include <linux/types.h>
#include <linux/highmem.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-direct.h>
#include <linux/export.h>

#include <asm/tlbflush.h>
@@ -151,8 +151,8 @@ static struct ppc_vm_region *ppc_vm_region_find(struct ppc_vm_region *head, unsi
* Allocate DMA-coherent memory space and return both the kernel remapped
* virtual and bus address for that space.
*/
-void *
-__dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp)
+void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
struct page *page;
struct ppc_vm_region *c;
@@ -223,7 +223,7 @@ __dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t
/*
* Set the "dma handle"
*/
- *handle = page_to_phys(page);
+ *dma_handle = phys_to_dma(dev, page_to_phys(page));

do {
SetPageReserved(page);
@@ -249,12 +249,12 @@ __dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t
no_page:
return NULL;
}
-EXPORT_SYMBOL(__dma_alloc_coherent);

/*
* free a page as defined by the above mapping.
*/
-void __dma_free_coherent(size_t size, void *vaddr)
+void __dma_nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_handle, unsigned long attrs)
{
struct ppc_vm_region *c;
unsigned long flags, addr;
@@ -309,7 +309,6 @@ void __dma_free_coherent(size_t size, void *vaddr)
__func__, vaddr);
dump_stack();
}
-EXPORT_SYMBOL(__dma_free_coherent);

/*
* make an area consistent.
@@ -401,7 +400,7 @@ EXPORT_SYMBOL(__dma_sync_page);

/*
* Return the PFN for a given cpu virtual address returned by
- * __dma_alloc_coherent. This is used by dma_mmap_coherent()
+ * __dma_nommu_alloc_coherent. This is used by dma_mmap_coherent()
*/
unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr)
{
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index a886c2c22097..7e4f8ca19ce8 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -47,7 +47,7 @@ static int __init warp_probe(void)
if (!of_machine_is_compatible("pika,warp"))
return 0;

- /* For __dma_alloc_coherent */
+ /* For __dma_nommu_alloc_coherent */
ISA_DMA_THRESHOLD = ~0L;

return 1;
--
2.19.1


2018-11-14 08:24:53

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 09/34] powerpc/dma: handle iommu bypass in dma_iommu_ops

Add a new iommu_bypass flag to struct dev_archdata so that the dma_iommu
implementation can handle the direct mapping transparently instead of
switiching ops around. Setting of this flag is controlled by new
pci_controller_ops method.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/device.h | 5 ++
arch/powerpc/include/asm/dma-mapping.h | 8 +++
arch/powerpc/include/asm/pci-bridge.h | 2 +
arch/powerpc/kernel/dma-iommu.c | 70 +++++++++++++++++++++++---
arch/powerpc/kernel/dma.c | 19 +++----
5 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
index 0245bfcaac32..1aa53318b4bc 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -19,6 +19,11 @@ struct iommu_table;
* drivers/macintosh/macio_asic.c
*/
struct dev_archdata {
+ /*
+ * Set to %true if the dma_iommu_ops are requested to use a direct
+ * window instead of dynamically mapping memory.
+ */
+ bool iommu_bypass : 1;
/*
* These two used to be a union. However, with the hybrid ops we need
* both so here we store both a DMA offset for direct mappings and
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index dacd0f93f2b2..824f55995a18 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -29,6 +29,14 @@ extern int dma_nommu_mmap_coherent(struct device *dev,
struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t handle,
size_t size, unsigned long attrs);
+int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction direction,
+ unsigned long attrs);
+dma_addr_t dma_nommu_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs);
+int dma_nommu_dma_supported(struct device *dev, u64 mask);
+u64 dma_nommu_get_required_mask(struct device *dev);

#ifdef CONFIG_NOT_COHERENT_CACHE
/*
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 94d449031b18..5c7a1e7ffc8a 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -19,6 +19,8 @@ struct device_node;
struct pci_controller_ops {
void (*dma_dev_setup)(struct pci_dev *pdev);
void (*dma_bus_setup)(struct pci_bus *bus);
+ bool (*iommu_bypass_supported)(struct pci_dev *pdev,
+ u64 mask);

int (*probe_mode)(struct pci_bus *bus);

diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 0613278abf9f..459be16f8334 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -6,12 +6,30 @@
* busses using the iommu infrastructure
*/

+#include <linux/dma-direct.h>
+#include <linux/pci.h>
#include <asm/iommu.h>

/*
* Generic iommu implementation
*/

+/*
+ * The coherent mask may be smaller than the real mask, check if we can
+ * really use a direct window.
+ */
+static inline bool dma_iommu_alloc_bypass(struct device *dev)
+{
+ return dev->archdata.iommu_bypass &&
+ dma_nommu_dma_supported(dev, dev->coherent_dma_mask);
+}
+
+static inline bool dma_iommu_map_bypass(struct device *dev,
+ unsigned long attrs)
+{
+ return dev->archdata.iommu_bypass;
+}
+
/* Allocates a contiguous real buffer and creates mappings over it.
* Returns the virtual address of the buffer and sets dma_handle
* to the dma address (mapping) of the first page.
@@ -20,6 +38,9 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag,
unsigned long attrs)
{
+ if (dma_iommu_alloc_bypass(dev))
+ return __dma_nommu_alloc_coherent(dev, size, dma_handle, flag,
+ attrs);
return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
dma_handle, dev->coherent_dma_mask, flag,
dev_to_node(dev));
@@ -29,7 +50,11 @@ static void dma_iommu_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
unsigned long attrs)
{
- iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
+ if (dma_iommu_alloc_bypass(dev))
+ __dma_nommu_free_coherent(dev, size, vaddr, dma_handle, attrs);
+ else
+ iommu_free_coherent(get_iommu_table_base(dev), size, vaddr,
+ dma_handle);
}

/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -42,6 +67,9 @@ static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dma_iommu_map_bypass(dev, attrs))
+ return dma_nommu_map_page(dev, page, offset, size, direction,
+ attrs);
return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
size, device_to_mask(dev), direction, attrs);
}
@@ -51,8 +79,9 @@ static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
unsigned long attrs)
{
- iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
- attrs);
+ if (!dma_iommu_map_bypass(dev, attrs))
+ iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size,
+ direction, attrs);
}


@@ -60,6 +89,8 @@ static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dma_iommu_map_bypass(dev, attrs))
+ return dma_nommu_map_sg(dev, sglist, nelems, direction, attrs);
return ppc_iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
device_to_mask(dev), direction, attrs);
}
@@ -68,10 +99,20 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
- ppc_iommu_unmap_sg(get_iommu_table_base(dev), sglist, nelems,
+ if (!dma_iommu_map_bypass(dev, attrs))
+ ppc_iommu_unmap_sg(get_iommu_table_base(dev), sglist, nelems,
direction, attrs);
}

+static bool dma_iommu_bypass_supported(struct device *dev, u64 mask)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+
+ return phb->controller_ops.iommu_bypass_supported &&
+ phb->controller_ops.iommu_bypass_supported(pdev, mask);
+}
+
/* We support DMA to/from any memory page via the iommu */
int dma_iommu_dma_supported(struct device *dev, u64 mask)
{
@@ -83,22 +124,39 @@ int dma_iommu_dma_supported(struct device *dev, u64 mask)
return 0;
}

+ if (dev_is_pci(dev) && dma_iommu_bypass_supported(dev, mask)) {
+ dev->archdata.iommu_bypass = true;
+ dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
+ return 1;
+ }
+
if (tbl->it_offset > (mask >> tbl->it_page_shift)) {
dev_info(dev, "Warning: IOMMU offset too big for device mask\n");
dev_info(dev, "mask: 0x%08llx, table offset: 0x%08lx\n",
mask, tbl->it_offset << tbl->it_page_shift);
return 0;
- } else
- return 1;
+ }
+
+ dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
+ dev->archdata.iommu_bypass = false;
+ return 1;
}

u64 dma_iommu_get_required_mask(struct device *dev)
{
struct iommu_table *tbl = get_iommu_table_base(dev);
u64 mask;
+
if (!tbl)
return 0;

+ if (dev_is_pci(dev)) {
+ u64 bypass_mask = dma_nommu_get_required_mask(dev);
+
+ if (dma_iommu_bypass_supported(dev, bypass_mask))
+ return bypass_mask;
+ }
+
mask = 1ULL < (fls_long(tbl->it_offset + tbl->it_size) - 1);
mask += mask - 1;

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 7078d72baec2..6c368b6820bb 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -40,7 +40,7 @@ static u64 __maybe_unused get_pfn_limit(struct device *dev)
return pfn;
}

-static int dma_nommu_dma_supported(struct device *dev, u64 mask)
+int dma_nommu_dma_supported(struct device *dev, u64 mask)
{
#ifdef CONFIG_PPC64
u64 limit = get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
@@ -177,9 +177,9 @@ int dma_nommu_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
vma->vm_page_prot);
}

-static int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
- int nents, enum dma_data_direction direction,
- unsigned long attrs)
+int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction direction,
+ unsigned long attrs)
{
struct scatterlist *sg;
int i;
@@ -197,7 +197,7 @@ static int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
return nents;
}

-static u64 dma_nommu_get_required_mask(struct device *dev)
+u64 dma_nommu_get_required_mask(struct device *dev)
{
u64 end, mask;

@@ -209,12 +209,9 @@ static u64 dma_nommu_get_required_mask(struct device *dev)
return mask;
}

-static inline dma_addr_t dma_nommu_map_page(struct device *dev,
- struct page *page,
- unsigned long offset,
- size_t size,
- enum dma_data_direction dir,
- unsigned long attrs)
+dma_addr_t dma_nommu_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
{
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
__dma_sync_page(page, offset, size, dir);
--
2.19.1


2018-11-14 08:25:12

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 10/34] powerpc/pseries: unwind dma_get_required_mask_pSeriesLP a bit

Call dma_get_required_mask_pSeriesLP directly instead of dma_iommu_ops
to simply the code a bit.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 06f02960b439..da5716de7f4c 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1273,7 +1273,7 @@ static u64 dma_get_required_mask_pSeriesLP(struct device *dev)
return DMA_BIT_MASK(64);
}

- return dma_iommu_ops.get_required_mask(dev);
+ return dma_iommu_get_required_mask(dev);
}

static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
--
2.19.1


2018-11-14 08:25:21

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 08/34] powerpc/dma: untangle vio_dma_mapping_ops from dma_iommu_ops

vio_dma_mapping_ops currently does a lot of indirect calls through
dma_iommu_ops, which not only make the code harder to follow but are
also expensive in the post-spectre world. Unwind the indirect calls
by calling the ppc_iommu_* or iommu_* APIs directly applicable, or
just use the dma_iommu_* methods directly where we can.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/dma-iommu.c | 2 +-
arch/powerpc/platforms/pseries/vio.c | 87 ++++++++++++----------------
3 files changed, 38 insertions(+), 52 deletions(-)

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 35db0cbc9222..75daa10f31a4 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -242,6 +242,7 @@ static inline int __init tce_iommu_bus_notifier_init(void)
}
#endif /* !CONFIG_IOMMU_API */

+u64 dma_iommu_get_required_mask(struct device *dev);
int dma_iommu_mapping_error(struct device *dev, dma_addr_t dma_addr);

#else
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 2ca6cfaebf65..0613278abf9f 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -92,7 +92,7 @@ int dma_iommu_dma_supported(struct device *dev, u64 mask)
return 1;
}

-static u64 dma_iommu_get_required_mask(struct device *dev)
+u64 dma_iommu_get_required_mask(struct device *dev)
{
struct iommu_table *tbl = get_iommu_table_base(dev);
u64 mask;
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 88f1ad1d6309..ea3a9745c812 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -492,7 +492,9 @@ static void *vio_dma_iommu_alloc_coherent(struct device *dev, size_t size,
return NULL;
}

- ret = dma_iommu_ops.alloc(dev, size, dma_handle, flag, attrs);
+ ret = iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
+ dma_handle, dev->coherent_dma_mask, flag,
+ dev_to_node(dev));
if (unlikely(ret == NULL)) {
vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
atomic_inc(&viodev->cmo.allocs_failed);
@@ -507,8 +509,7 @@ static void vio_dma_iommu_free_coherent(struct device *dev, size_t size,
{
struct vio_dev *viodev = to_vio_dev(dev);

- dma_iommu_ops.free(dev, size, vaddr, dma_handle, attrs);
-
+ iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
}

@@ -518,22 +519,22 @@ static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
unsigned long attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
- struct iommu_table *tbl;
+ struct iommu_table *tbl = get_iommu_table_base(dev);
dma_addr_t ret = IOMMU_MAPPING_ERROR;

- tbl = get_iommu_table_base(dev);
- if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)))) {
- atomic_inc(&viodev->cmo.allocs_failed);
- return ret;
- }
-
- ret = dma_iommu_ops.map_page(dev, page, offset, size, direction, attrs);
- if (unlikely(dma_mapping_error(dev, ret))) {
- vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
- atomic_inc(&viodev->cmo.allocs_failed);
- }
-
+ if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl))))
+ goto out_fail;
+ ret = iommu_map_page(dev, tbl, page, offset, size, device_to_mask(dev),
+ direction, attrs);
+ if (unlikely(ret == IOMMU_MAPPING_ERROR))
+ goto out_deallocate;
return ret;
+
+out_deallocate:
+ vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
+out_fail:
+ atomic_inc(&viodev->cmo.allocs_failed);
+ return IOMMU_MAPPING_ERROR;
}

static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
@@ -542,11 +543,9 @@ static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
unsigned long attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
- struct iommu_table *tbl;
-
- tbl = get_iommu_table_base(dev);
- dma_iommu_ops.unmap_page(dev, dma_handle, size, direction, attrs);
+ struct iommu_table *tbl = get_iommu_table_base(dev);

+ iommu_unmap_page(tbl, dma_handle, size, direction, attrs);
vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
}

@@ -555,34 +554,32 @@ static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
unsigned long attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
- struct iommu_table *tbl;
+ struct iommu_table *tbl = get_iommu_table_base(dev);
struct scatterlist *sgl;
int ret, count;
size_t alloc_size = 0;

- tbl = get_iommu_table_base(dev);
for_each_sg(sglist, sgl, nelems, count)
alloc_size += roundup(sgl->length, IOMMU_PAGE_SIZE(tbl));

- if (vio_cmo_alloc(viodev, alloc_size)) {
- atomic_inc(&viodev->cmo.allocs_failed);
- return 0;
- }
-
- ret = dma_iommu_ops.map_sg(dev, sglist, nelems, direction, attrs);
-
- if (unlikely(!ret)) {
- vio_cmo_dealloc(viodev, alloc_size);
- atomic_inc(&viodev->cmo.allocs_failed);
- return ret;
- }
+ if (vio_cmo_alloc(viodev, alloc_size))
+ goto out_fail;
+ ret = ppc_iommu_map_sg(dev, tbl, sglist, nelems, device_to_mask(dev),
+ direction, attrs);
+ if (unlikely(!ret))
+ goto out_deallocate;

for_each_sg(sglist, sgl, ret, count)
alloc_size -= roundup(sgl->dma_length, IOMMU_PAGE_SIZE(tbl));
if (alloc_size)
vio_cmo_dealloc(viodev, alloc_size);
-
return ret;
+
+out_deallocate:
+ vio_cmo_dealloc(viodev, alloc_size);
+out_fail:
+ atomic_inc(&viodev->cmo.allocs_failed);
+ return 0;
}

static void vio_dma_iommu_unmap_sg(struct device *dev,
@@ -591,30 +588,18 @@ static void vio_dma_iommu_unmap_sg(struct device *dev,
unsigned long attrs)
{
struct vio_dev *viodev = to_vio_dev(dev);
- struct iommu_table *tbl;
+ struct iommu_table *tbl = get_iommu_table_base(dev);
struct scatterlist *sgl;
size_t alloc_size = 0;
int count;

- tbl = get_iommu_table_base(dev);
for_each_sg(sglist, sgl, nelems, count)
alloc_size += roundup(sgl->dma_length, IOMMU_PAGE_SIZE(tbl));

- dma_iommu_ops.unmap_sg(dev, sglist, nelems, direction, attrs);
-
+ ppc_iommu_unmap_sg(tbl, sglist, nelems, direction, attrs);
vio_cmo_dealloc(viodev, alloc_size);
}

-static int vio_dma_iommu_dma_supported(struct device *dev, u64 mask)
-{
- return dma_iommu_ops.dma_supported(dev, mask);
-}
-
-static u64 vio_dma_get_required_mask(struct device *dev)
-{
- return dma_iommu_ops.get_required_mask(dev);
-}
-
static const struct dma_map_ops vio_dma_mapping_ops = {
.alloc = vio_dma_iommu_alloc_coherent,
.free = vio_dma_iommu_free_coherent,
@@ -623,8 +608,8 @@ static const struct dma_map_ops vio_dma_mapping_ops = {
.unmap_sg = vio_dma_iommu_unmap_sg,
.map_page = vio_dma_iommu_map_page,
.unmap_page = vio_dma_iommu_unmap_page,
- .dma_supported = vio_dma_iommu_dma_supported,
- .get_required_mask = vio_dma_get_required_mask,
+ .dma_supported = dma_iommu_mapping_error,
+ .get_required_mask = dma_iommu_get_required_mask,
.mapping_error = dma_iommu_mapping_error,
};

--
2.19.1


2018-11-14 08:25:33

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 16/34] powerpc/powernv: remove pnv_pci_ioda_pe_single_vendor

This function is completely bogus - the fact that two PCIe devices come
from the same vendor has absolutely nothing to say about the DMA
capabilities and characteristics.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 ++---------------------
1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index dd807446801e..afbb73cd3c5b 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1745,31 +1745,6 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
*/
}

-static bool pnv_pci_ioda_pe_single_vendor(struct pnv_ioda_pe *pe)
-{
- unsigned short vendor = 0;
- struct pci_dev *pdev;
-
- if (pe->device_count == 1)
- return true;
-
- /* pe->pdev should be set if it's a single device, pe->pbus if not */
- if (!pe->pbus)
- return true;
-
- list_for_each_entry(pdev, &pe->pbus->devices, bus_list) {
- if (!vendor) {
- vendor = pdev->vendor;
- continue;
- }
-
- if (pdev->vendor != vendor)
- return false;
- }
-
- return true;
-}
-
/*
* Reconfigure TVE#0 to be usable as 64-bit DMA space.
*
@@ -1870,7 +1845,8 @@ static int pnv_pci_ioda_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
*/
if (dma_mask >> 32 &&
dma_mask > (memory_hotplug_max() + (1ULL << 32)) &&
- pnv_pci_ioda_pe_single_vendor(pe) &&
+ /* pe->pdev should be set if it's a single device, pe->pbus if not */
+ (pe->device_count == 1 || !pe->pbus) &&
phb->model == PNV_PHB_MODEL_PHB3) {
/* Configure the bypass mode */
rc = pnv_pci_ioda_dma_64bit_bypass(pe);
--
2.19.1


2018-11-14 08:25:35

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 22/34] powerpc/dma: remove the iommu fallback for coherent allocations

All iommu capable platforms now always use the iommu code with the
internal bypass, so there is not need for this magic anymore.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/Kconfig | 4 ---
arch/powerpc/kernel/dma.c | 68 ++-------------------------------------
2 files changed, 2 insertions(+), 70 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cffff3613bc1..2d4a19bc8023 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,9 +119,6 @@ config GENERIC_HWEIGHT
bool
default y

-config ARCH_HAS_DMA_SET_COHERENT_MASK
- bool
-
config PPC
bool
default y
@@ -129,7 +126,6 @@ config PPC
# Please keep this list sorted alphabetically.
#
select ARCH_HAS_DEVMEM_IS_ALLOWED
- select ARCH_HAS_DMA_SET_COHERENT_MASK
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 829eb2fefc8c..f9f51fc505a1 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -114,51 +114,6 @@ void __dma_nommu_free_coherent(struct device *dev, size_t size,
}
#endif /* !CONFIG_NOT_COHERENT_CACHE */

-static void *dma_nommu_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag,
- unsigned long attrs)
-{
- struct iommu_table *iommu;
-
- /* The coherent mask may be smaller than the real mask, check if
- * we can really use the direct ops
- */
- if (dma_nommu_dma_supported(dev, dev->coherent_dma_mask))
- return __dma_nommu_alloc_coherent(dev, size, dma_handle,
- flag, attrs);
-
- /* Ok we can't ... do we have an iommu ? If not, fail */
- iommu = get_iommu_table_base(dev);
- if (!iommu)
- return NULL;
-
- /* Try to use the iommu */
- return iommu_alloc_coherent(dev, iommu, size, dma_handle,
- dev->coherent_dma_mask, flag,
- dev_to_node(dev));
-}
-
-static void dma_nommu_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- unsigned long attrs)
-{
- struct iommu_table *iommu;
-
- /* See comments in dma_nommu_alloc_coherent() */
- if (dma_nommu_dma_supported(dev, dev->coherent_dma_mask))
- return __dma_nommu_free_coherent(dev, size, vaddr, dma_handle,
- attrs);
- /* Maybe we used an iommu ... */
- iommu = get_iommu_table_base(dev);
-
- /* If we hit that we should have never allocated in the first
- * place so how come we are freeing ?
- */
- if (WARN_ON(!iommu))
- return;
- iommu_free_coherent(iommu, size, vaddr, dma_handle);
-}
-
int dma_nommu_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
@@ -240,8 +195,8 @@ static inline void dma_nommu_sync_single(struct device *dev,
#endif

const struct dma_map_ops dma_nommu_ops = {
- .alloc = dma_nommu_alloc_coherent,
- .free = dma_nommu_free_coherent,
+ .alloc = __dma_nommu_alloc_coherent,
+ .free = __dma_nommu_free_coherent,
.mmap = dma_nommu_mmap_coherent,
.map_sg = dma_nommu_map_sg,
.dma_supported = dma_nommu_dma_supported,
@@ -255,25 +210,6 @@ const struct dma_map_ops dma_nommu_ops = {
};
EXPORT_SYMBOL(dma_nommu_ops);

-int dma_set_coherent_mask(struct device *dev, u64 mask)
-{
- if (!dma_supported(dev, mask)) {
- /*
- * We need to special case the direct DMA ops which can
- * support a fallback for coherent allocations. There
- * is no dma_op->set_coherent_mask() so we have to do
- * things the hard way:
- */
- if (get_dma_ops(dev) != &dma_nommu_ops ||
- get_iommu_table_base(dev) == NULL ||
- !dma_iommu_dma_supported(dev, mask))
- return -EIO;
- }
- dev->coherent_dma_mask = mask;
- return 0;
-}
-EXPORT_SYMBOL(dma_set_coherent_mask);
-
int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (ppc_md.dma_set_mask)
--
2.19.1


2018-11-14 08:25:41

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 18/34] powerpc/powernv: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 95 ++++++-----------------
1 file changed, 25 insertions(+), 70 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1d9f446f3eff..23fd46cd2ab3 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1814,89 +1814,45 @@ static int pnv_pci_ioda_dma_64bit_bypass(struct pnv_ioda_pe *pe)
return -EIO;
}

-static int pnv_pci_ioda_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
+static bool pnv_pci_ioda_iommu_bypass_supported(struct pci_dev *pdev,
+ u64 dma_mask)
{
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
struct pnv_phb *phb = hose->private_data;
struct pci_dn *pdn = pci_get_pdn(pdev);
struct pnv_ioda_pe *pe;
- uint64_t top;
- bool bypass = false;
- s64 rc;

if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
return -ENODEV;

pe = &phb->ioda.pe_array[pdn->pe_number];
if (pe->tce_bypass_enabled) {
- top = pe->tce_bypass_base + memblock_end_of_DRAM() - 1;
- bypass = (dma_mask >= top);
+ u64 top = pe->tce_bypass_base + memblock_end_of_DRAM() - 1;
+ if (dma_mask >= top)
+ return true;
}

- if (bypass) {
- dev_info(&pdev->dev, "Using 64-bit DMA iommu bypass\n");
- set_dma_ops(&pdev->dev, &dma_nommu_ops);
- } else {
- /*
- * If the device can't set the TCE bypass bit but still wants
- * to access 4GB or more, on PHB3 we can reconfigure TVE#0 to
- * bypass the 32-bit region and be usable for 64-bit DMAs.
- * The device needs to be able to address all of this space.
- */
- if (dma_mask >> 32 &&
- dma_mask > (memory_hotplug_max() + (1ULL << 32)) &&
- /* pe->pdev should be set if it's a single device, pe->pbus if not */
- (pe->device_count == 1 || !pe->pbus) &&
- phb->model == PNV_PHB_MODEL_PHB3) {
- /* Configure the bypass mode */
- rc = pnv_pci_ioda_dma_64bit_bypass(pe);
- if (rc)
- return rc;
- /* 4GB offset bypasses 32-bit space */
- set_dma_offset(&pdev->dev, (1ULL << 32));
- set_dma_ops(&pdev->dev, &dma_nommu_ops);
- } else if (dma_mask >> 32 && dma_mask != DMA_BIT_MASK(64)) {
- /*
- * Fail the request if a DMA mask between 32 and 64 bits
- * was requested but couldn't be fulfilled. Ideally we
- * would do this for 64-bits but historically we have
- * always fallen back to 32-bits.
- */
- return -ENOMEM;
- } else {
- dev_info(&pdev->dev, "Using 32-bit DMA via iommu\n");
- set_dma_ops(&pdev->dev, &dma_iommu_ops);
- }
+ /*
+ * If the device can't set the TCE bypass bit but still wants
+ * to access 4GB or more, on PHB3 we can reconfigure TVE#0 to
+ * bypass the 32-bit region and be usable for 64-bit DMAs.
+ * The device needs to be able to address all of this space.
+ */
+ if (dma_mask >> 32 &&
+ dma_mask > (memory_hotplug_max() + (1ULL << 32)) &&
+ /* pe->pdev should be set if it's a single device, pe->pbus if not */
+ (pe->device_count == 1 || !pe->pbus) &&
+ phb->model == PNV_PHB_MODEL_PHB3) {
+ /* Configure the bypass mode */
+ s64 rc = pnv_pci_ioda_dma_64bit_bypass(pe);
+ if (rc)
+ return rc;
+ /* 4GB offset bypasses 32-bit space */
+ set_dma_offset(&pdev->dev, (1ULL << 32));
+ return true;
}
- *pdev->dev.dma_mask = dma_mask;
-
- /* Update peer npu devices */
- pnv_npu_try_dma_set_bypass(pdev, bypass);
-
- return 0;
-}
-
-static u64 pnv_pci_ioda_dma_get_required_mask(struct pci_dev *pdev)
-{
- struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- struct pnv_phb *phb = hose->private_data;
- struct pci_dn *pdn = pci_get_pdn(pdev);
- struct pnv_ioda_pe *pe;
- u64 end, mask;

- if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
- return 0;
-
- pe = &phb->ioda.pe_array[pdn->pe_number];
- if (!pe->tce_bypass_enabled)
- return __dma_get_required_mask(&pdev->dev);
-
-
- end = pe->tce_bypass_base + memblock_end_of_DRAM();
- mask = 1ULL << (fls64(end) - 1);
- mask += mask - 1;
-
- return mask;
+ return false;
}

static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
@@ -3674,6 +3630,7 @@ static void pnv_pci_ioda_shutdown(struct pci_controller *hose)
static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
.dma_dev_setup = pnv_pci_dma_dev_setup,
.dma_bus_setup = pnv_pci_dma_bus_setup,
+ .iommu_bypass_supported = pnv_pci_ioda_iommu_bypass_supported,
#ifdef CONFIG_PCI_MSI
.setup_msi_irqs = pnv_setup_msi_irqs,
.teardown_msi_irqs = pnv_teardown_msi_irqs,
@@ -3683,8 +3640,6 @@ static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
.window_alignment = pnv_pci_window_alignment,
.setup_bridge = pnv_pci_setup_bridge,
.reset_secondary_bus = pnv_pci_reset_secondary_bus,
- .dma_set_mask = pnv_pci_ioda_dma_set_mask,
- .dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask,
.shutdown = pnv_pci_ioda_shutdown,
};

--
2.19.1


2018-11-14 08:25:43

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 19/34] cxl: drop the dma_set_mask callback from vphb

The CXL code never even looks at the dma mask, so there is no good
reason for this sanity check. Remove it because it gets in the way
of the dma ops refactoring.

Signed-off-by: Christoph Hellwig <[email protected]>
---
drivers/misc/cxl/vphb.c | 12 ------------
1 file changed, 12 deletions(-)

diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c
index 7908633d9204..49da2f744bbf 100644
--- a/drivers/misc/cxl/vphb.c
+++ b/drivers/misc/cxl/vphb.c
@@ -11,17 +11,6 @@
#include <misc/cxl.h>
#include "cxl.h"

-static int cxl_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
-{
- if (dma_mask < DMA_BIT_MASK(64)) {
- pr_info("%s only 64bit DMA supported on CXL", __func__);
- return -EIO;
- }
-
- *(pdev->dev.dma_mask) = dma_mask;
- return 0;
-}
-
static int cxl_pci_probe_mode(struct pci_bus *bus)
{
return PCI_PROBE_NORMAL;
@@ -220,7 +209,6 @@ static struct pci_controller_ops cxl_pci_controller_ops =
.reset_secondary_bus = cxl_pci_reset_secondary_bus,
.setup_msi_irqs = cxl_setup_msi_irqs,
.teardown_msi_irqs = cxl_teardown_msi_irqs,
- .dma_set_mask = cxl_dma_set_mask,
};

int cxl_pci_vphb_add(struct cxl_afu *afu)
--
2.19.1


2018-11-14 08:25:47

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 21/34] powerpc/pci: remove the dma_set_mask pci_controller ops methods

Unused now.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/pci-bridge.h | 2 --
arch/powerpc/kernel/dma.c | 7 -------
2 files changed, 9 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index aace7033fa02..a50703af7db3 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -45,8 +45,6 @@ struct pci_controller_ops {
void (*teardown_msi_irqs)(struct pci_dev *pdev);
#endif

- int (*dma_set_mask)(struct pci_dev *pdev, u64 dma_mask);
-
void (*shutdown)(struct pci_controller *hose);
};

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 154e1cdae7f9..829eb2fefc8c 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -279,13 +279,6 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
if (ppc_md.dma_set_mask)
return ppc_md.dma_set_mask(dev, dma_mask);

- if (dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pci_controller *phb = pci_bus_to_host(pdev->bus);
- if (phb->controller_ops.dma_set_mask)
- return phb->controller_ops.dma_set_mask(pdev, dma_mask);
- }
-
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
*dev->dma_mask = dma_mask;
--
2.19.1


2018-11-14 08:25:54

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 23/34] powerpc/dma: remove get_pci_dma_ops

This function is only used by the Cell iommu code, which can keep track
if it is using the iommu internally just as good.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/pci.h | 2 --
arch/powerpc/kernel/pci-common.c | 6 ------
arch/powerpc/platforms/cell/iommu.c | 17 ++++++++---------
3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 2af9ded80540..04c44c4b0acf 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -52,10 +52,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)

#ifdef CONFIG_PCI
extern void set_pci_dma_ops(const struct dma_map_ops *dma_ops);
-extern const struct dma_map_ops *get_pci_dma_ops(void);
#else /* CONFIG_PCI */
#define set_pci_dma_ops(d)
-#define get_pci_dma_ops() NULL
#endif

#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 88e4f69a09e5..a84707680525 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -69,12 +69,6 @@ void set_pci_dma_ops(const struct dma_map_ops *dma_ops)
pci_dma_ops = dma_ops;
}

-const struct dma_map_ops *get_pci_dma_ops(void)
-{
- return pci_dma_ops;
-}
-EXPORT_SYMBOL(get_pci_dma_ops);
-
/*
* This function should run under locking protection, specifically
* hose_spinlock.
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index fb51f78035ce..93c7e4aef571 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -544,6 +544,7 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_nommu_offset;

static unsigned long dma_iommu_fixed_base;
+static bool cell_iommu_enabled;

/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */
bool iommu_fixed_is_weak;
@@ -572,16 +573,14 @@ static u64 cell_iommu_get_fixed_address(struct device *dev);

static void cell_dma_dev_setup(struct device *dev)
{
- if (get_pci_dma_ops() == &dma_iommu_ops) {
+ if (cell_iommu_enabled) {
u64 addr = cell_iommu_get_fixed_address(dev);

if (addr != OF_BAD_ADDR)
set_dma_offset(dev, addr + dma_iommu_fixed_base);
set_iommu_table_base(dev, cell_get_iommu_table(dev));
- } else if (get_pci_dma_ops() == &dma_nommu_ops) {
- set_dma_offset(dev, cell_dma_nommu_offset);
} else {
- BUG();
+ set_dma_offset(dev, cell_dma_nommu_offset);
}
}

@@ -599,11 +598,11 @@ static int cell_of_bus_notify(struct notifier_block *nb, unsigned long action,
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;

- /* We use the PCI DMA ops */
- dev->dma_ops = get_pci_dma_ops();
-
+ if (cell_iommu_enabled)
+ dev->dma_ops = &dma_iommu_ops;
+ else
+ dev->dma_ops = &dma_nommu_ops;
cell_dma_dev_setup(dev);
-
return 0;
}

@@ -1091,7 +1090,7 @@ static int __init cell_iommu_init(void)
cell_pci_iommu_bypass_supported;
}
set_pci_dma_ops(&dma_iommu_ops);
-
+ cell_iommu_enabled = true;
bail:
/* Register callbacks on OF platform device addition/removal
* to handle linking them to the right DMA operations
--
2.19.1


2018-11-14 08:25:55

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 05/34] powerpc/dma: remove the unused dma_iommu_ops export

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/kernel/dma-iommu.c | 2 --
1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index f9fe2080ceb9..2ca6cfaebf65 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -6,7 +6,6 @@
* busses using the iommu infrastructure
*/

-#include <linux/export.h>
#include <asm/iommu.h>

/*
@@ -123,4 +122,3 @@ struct dma_map_ops dma_iommu_ops = {
.get_required_mask = dma_iommu_get_required_mask,
.mapping_error = dma_iommu_mapping_error,
};
-EXPORT_SYMBOL(dma_iommu_ops);
--
2.19.1


2018-11-14 08:25:55

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 31/34] powerpc/dma: use generic direct and swiotlb ops

- The ppc32 case of dma_nommu_dma_supported already was a no-op, and the
64-bit case came to the same conclusion as dma_direct_supported, so
replace it with the generic version.

- supports CMA

- Note that the cache maintainance in the existing code is a bit odd
as it implements both the sync_to_device and sync_to_cpu callouts,
but never flushes caches when unmapping. This patch keeps both
directions arounds, which will lead to more flushing than the previous
implementation. Someone more familar with the required CPUs should
eventually take a look and optimize the cache flush handling if needed.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dma-mapping.h | 41 -----
arch/powerpc/include/asm/pgtable.h | 1 -
arch/powerpc/include/asm/swiotlb.h | 2 -
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/dma-iommu.c | 13 +-
arch/powerpc/kernel/dma-swiotlb.c | 24 +--
arch/powerpc/kernel/dma.c | 202 -------------------------
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/kernel/setup-common.c | 2 +-
arch/powerpc/mm/dma-noncoherent.c | 35 +++--
arch/powerpc/mm/mem.c | 22 ---
arch/powerpc/platforms/44x/warp.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +
arch/powerpc/platforms/cell/iommu.c | 4 +-
arch/powerpc/platforms/pasemi/iommu.c | 2 +-
arch/powerpc/platforms/pasemi/setup.c | 2 +-
arch/powerpc/platforms/pseries/vio.c | 7 +
arch/powerpc/sysdev/fsl_pci.c | 2 +-
drivers/misc/cxl/vphb.c | 2 +-
20 files changed, 50 insertions(+), 320 deletions(-)
delete mode 100644 arch/powerpc/kernel/dma.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4f03997ad54a..e200cdf92290 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -155,6 +155,7 @@ config PPC
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
select DYNAMIC_FTRACE if FUNCTION_TRACER
+ select DMA_DIRECT_OPS
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index f19c486e7b3f..93e57e28be28 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -18,46 +18,6 @@
#include <asm/io.h>
#include <asm/swiotlb.h>

-/* Some dma direct funcs must be visible for use in other dma_ops */
-extern void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag,
- unsigned long attrs);
-extern void __dma_nommu_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- unsigned long attrs);
-int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
- int nents, enum dma_data_direction direction,
- unsigned long attrs);
-dma_addr_t dma_nommu_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs);
-int dma_nommu_dma_supported(struct device *dev, u64 mask);
-u64 dma_nommu_get_required_mask(struct device *dev);
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
-/*
- * DMA-consistent mapping functions for PowerPCs that don't support
- * cache snooping. These allocate/free a region of uncached mapped
- * memory space for use with DMA devices. Alternatively, you could
- * allocate the space "normally" and use the cache management functions
- * to ensure it is consistent.
- */
-struct device;
-extern void __dma_sync(void *vaddr, size_t size, int direction);
-extern void __dma_sync_page(struct page *page, unsigned long offset,
- size_t size, int direction);
-extern unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr);
-
-#else /* ! CONFIG_NOT_COHERENT_CACHE */
-/*
- * Cache coherent cores.
- */
-
-#define __dma_sync(addr, size, rw) ((void)0)
-#define __dma_sync_page(pg, off, sz, rw) ((void)0)
-
-#endif /* ! CONFIG_NOT_COHERENT_CACHE */
-
static inline unsigned long device_to_mask(struct device *dev)
{
if (dev->dma_mask && *dev->dma_mask)
@@ -72,7 +32,6 @@ static inline unsigned long device_to_mask(struct device *dev)
#ifdef CONFIG_PPC64
extern const struct dma_map_ops dma_iommu_ops;
#endif
-extern const struct dma_map_ops dma_nommu_ops;

static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
{
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 8af32ce93c7f..70979b860761 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -66,7 +66,6 @@ extern unsigned long empty_zero_page[];

extern pgd_t swapper_pg_dir[];

-int dma_pfn_limit_to_zone(u64 pfn_limit);
extern void paging_init(void);

/*
diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/include/asm/swiotlb.h
index 26a0f12b835b..b7ff218109b3 100644
--- a/arch/powerpc/include/asm/swiotlb.h
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -13,8 +13,6 @@

#include <linux/swiotlb.h>

-extern const struct dma_map_ops powerpc_swiotlb_dma_ops;
-
extern unsigned int ppc_swiotlb_enable;
int __init swiotlb_setup_bus_notifier(void);

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 53d4b8d5b54d..d9e01cc3ae84 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -36,7 +36,7 @@ obj-y := cputable.o ptrace.o syscalls.o \
process.o systbl.o idle.o \
signal.o sysfs.o cacheinfo.o time.o \
prom.o traps.o setup-common.o \
- udbg.o misc.o io.o dma.o misc_$(BITS).o \
+ udbg.o misc.o io.o misc_$(BITS).o \
of_platform.o prom_parse.o
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 5b15e53ee43d..0224925c5628 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -21,7 +21,7 @@
static inline bool dma_iommu_alloc_bypass(struct device *dev)
{
return dev->archdata.iommu_bypass && !iommu_fixed_is_weak &&
- dma_nommu_dma_supported(dev, dev->coherent_dma_mask);
+ dma_direct_supported(dev, dev->coherent_dma_mask);
}

static inline bool dma_iommu_map_bypass(struct device *dev,
@@ -40,8 +40,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
unsigned long attrs)
{
if (dma_iommu_alloc_bypass(dev))
- return __dma_nommu_alloc_coherent(dev, size, dma_handle, flag,
- attrs);
+ return dma_direct_alloc(dev, size, dma_handle, flag, attrs);
return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
dma_handle, dev->coherent_dma_mask, flag,
dev_to_node(dev));
@@ -52,7 +51,7 @@ static void dma_iommu_free_coherent(struct device *dev, size_t size,
unsigned long attrs)
{
if (dma_iommu_alloc_bypass(dev))
- __dma_nommu_free_coherent(dev, size, vaddr, dma_handle, attrs);
+ dma_direct_free(dev, size, vaddr, dma_handle, attrs);
else
iommu_free_coherent(get_iommu_table_base(dev), size, vaddr,
dma_handle);
@@ -69,7 +68,7 @@ static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
unsigned long attrs)
{
if (dma_iommu_map_bypass(dev, attrs))
- return dma_nommu_map_page(dev, page, offset, size, direction,
+ return dma_direct_map_page(dev, page, offset, size, direction,
attrs);
return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
size, device_to_mask(dev), direction, attrs);
@@ -91,7 +90,7 @@ static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
unsigned long attrs)
{
if (dma_iommu_map_bypass(dev, attrs))
- return dma_nommu_map_sg(dev, sglist, nelems, direction, attrs);
+ return dma_direct_map_sg(dev, sglist, nelems, direction, attrs);
return ppc_iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
device_to_mask(dev), direction, attrs);
}
@@ -152,7 +151,7 @@ u64 dma_iommu_get_required_mask(struct device *dev)
return 0;

if (dev_is_pci(dev)) {
- u64 bypass_mask = dma_nommu_get_required_mask(dev);
+ u64 bypass_mask = dma_direct_get_required_mask(dev);

if (dma_iommu_bypass_supported(dev, bypass_mask))
return bypass_mask;
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 03df252ff5fb..bded4127791a 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -32,28 +32,6 @@ EXPORT_SYMBOL(arch_dma_set_mask);

unsigned int ppc_swiotlb_enable;

-/*
- * At the moment, all platforms that use this code only require
- * swiotlb to be used if we're operating on HIGHMEM. Since
- * we don't ever call anything other than map_sg, unmap_sg,
- * map_page, and unmap_page on highmem, use normal dma_ops
- * for everything else.
- */
-const struct dma_map_ops powerpc_swiotlb_dma_ops = {
- .alloc = __dma_nommu_alloc_coherent,
- .free = __dma_nommu_free_coherent,
- .map_sg = swiotlb_map_sg_attrs,
- .unmap_sg = swiotlb_unmap_sg_attrs,
- .dma_supported = swiotlb_dma_supported,
- .map_page = swiotlb_map_page,
- .unmap_page = swiotlb_unmap_page,
- .sync_single_for_cpu = swiotlb_sync_single_for_cpu,
- .sync_single_for_device = swiotlb_sync_single_for_device,
- .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
- .sync_sg_for_device = swiotlb_sync_sg_for_device,
- .mapping_error = dma_direct_mapping_error,
-};
-
static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -65,7 +43,7 @@ static int ppc_swiotlb_bus_notify(struct notifier_block *nb,

/* May need to bounce if the device can't address all of DRAM */
if ((dma_get_mask(dev) + 1) < memblock_end_of_DRAM())
- set_dma_ops(dev, &powerpc_swiotlb_dma_ops);
+ set_dma_ops(dev, &swiotlb_dma_ops);

return NOTIFY_DONE;
}
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
deleted file mode 100644
index a6590aa77181..000000000000
--- a/arch/powerpc/kernel/dma.c
+++ /dev/null
@@ -1,202 +0,0 @@
-/*
- * Copyright (C) 2006 Benjamin Herrenschmidt, IBM Corporation
- *
- * Provide default implementations of the DMA mapping callbacks for
- * directly mapped busses.
- */
-
-#include <linux/device.h>
-#include <linux/dma-direct.h>
-#include <linux/dma-debug.h>
-#include <linux/gfp.h>
-#include <linux/memblock.h>
-#include <linux/export.h>
-#include <linux/pci.h>
-#include <asm/vio.h>
-#include <asm/bug.h>
-#include <asm/machdep.h>
-#include <asm/swiotlb.h>
-#include <asm/iommu.h>
-
-/*
- * Generic direct DMA implementation
- *
- * This implementation supports a per-device offset that can be applied if
- * the address at which memory is visible to devices is not 0. Platform code
- * can set archdata.dma_data to an unsigned long holding the offset. By
- * default the offset is PCI_DRAM_OFFSET.
- */
-
-static u64 __maybe_unused get_pfn_limit(struct device *dev)
-{
- u64 pfn = (dev->coherent_dma_mask >> PAGE_SHIFT) + 1;
-
-#ifdef CONFIG_SWIOTLB
- if (dev->bus_dma_mask && dev->dma_ops == &powerpc_swiotlb_dma_ops)
- pfn = min_t(u64, pfn, dev->bus_dma_mask >> PAGE_SHIFT);
-#endif
-
- return pfn;
-}
-
-int dma_nommu_dma_supported(struct device *dev, u64 mask)
-{
-#ifdef CONFIG_PPC64
- u64 limit = phys_to_dma(dev, (memblock_end_of_DRAM() - 1));
-
- /* Limit fits in the mask, we are good */
- if (mask >= limit)
- return 1;
-
-#ifdef CONFIG_FSL_SOC
- /* Freescale gets another chance via ZONE_DMA, however
- * that will have to be refined if/when they support iommus
- */
- return 1;
-#endif
- /* Sorry ... */
- return 0;
-#else
- return 1;
-#endif
-}
-
-#ifndef CONFIG_NOT_COHERENT_CACHE
-void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag,
- unsigned long attrs)
-{
- void *ret;
- struct page *page;
- int node = dev_to_node(dev);
-#ifdef CONFIG_FSL_SOC
- u64 pfn = get_pfn_limit(dev);
- int zone;
-
- /*
- * This code should be OK on other platforms, but we have drivers that
- * don't set coherent_dma_mask. As a workaround we just ifdef it. This
- * whole routine needs some serious cleanup.
- */
-
- zone = dma_pfn_limit_to_zone(pfn);
- if (zone < 0) {
- dev_err(dev, "%s: No suitable zone for pfn %#llx\n",
- __func__, pfn);
- return NULL;
- }
-
- switch (zone) {
-#ifdef CONFIG_ZONE_DMA
- case ZONE_DMA:
- flag |= GFP_DMA;
- break;
-#endif
- };
-#endif /* CONFIG_FSL_SOC */
-
- page = alloc_pages_node(node, flag, get_order(size));
- if (page == NULL)
- return NULL;
- ret = page_address(page);
- memset(ret, 0, size);
- *dma_handle = phys_to_dma(dev,__pa(ret));
-
- return ret;
-}
-
-void __dma_nommu_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- unsigned long attrs)
-{
- free_pages((unsigned long)vaddr, get_order(size));
-}
-#endif /* !CONFIG_NOT_COHERENT_CACHE */
-
-int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
- int nents, enum dma_data_direction direction,
- unsigned long attrs)
-{
- struct scatterlist *sg;
- int i;
-
- for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = phys_to_dma(dev, sg_phys(sg));
- sg->dma_length = sg->length;
-
- if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
- continue;
-
- __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
- }
-
- return nents;
-}
-
-u64 dma_nommu_get_required_mask(struct device *dev)
-{
- u64 end, mask;
-
- end = memblock_end_of_DRAM() + get_dma_offset(dev);
-
- mask = 1ULL << (fls64(end) - 1);
- mask += mask - 1;
-
- return mask;
-}
-
-dma_addr_t dma_nommu_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
- __dma_sync_page(page, offset, size, dir);
-
- return phys_to_dma(dev, page_to_phys(page)) + offset;
-}
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
-static inline void dma_nommu_sync_sg(struct device *dev,
- struct scatterlist *sgl, int nents,
- enum dma_data_direction direction)
-{
- struct scatterlist *sg;
- int i;
-
- for_each_sg(sgl, sg, nents, i)
- __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
-}
-
-static inline void dma_nommu_sync_single(struct device *dev,
- dma_addr_t dma_handle, size_t size,
- enum dma_data_direction direction)
-{
- __dma_sync(bus_to_virt(dma_handle), size, direction);
-}
-#endif
-
-const struct dma_map_ops dma_nommu_ops = {
- .alloc = __dma_nommu_alloc_coherent,
- .free = __dma_nommu_free_coherent,
- .map_sg = dma_nommu_map_sg,
- .dma_supported = dma_nommu_dma_supported,
- .map_page = dma_nommu_map_page,
-#ifdef CONFIG_NOT_COHERENT_CACHE
- .sync_single_for_cpu = dma_nommu_sync_single,
- .sync_single_for_device = dma_nommu_sync_single,
- .sync_sg_for_cpu = dma_nommu_sync_sg,
- .sync_sg_for_device = dma_nommu_sync_sg,
-#endif
-};
-EXPORT_SYMBOL(dma_nommu_ops);
-
-static int __init dma_init(void)
-{
-#ifdef CONFIG_IBMVIO
- dma_debug_add_bus(&vio_bus_type);
-#endif
-
- return 0;
-}
-fs_initcall(dma_init);
-
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a84707680525..661b937f31ed 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -62,7 +62,7 @@ resource_size_t isa_mem_base;
EXPORT_SYMBOL(isa_mem_base);


-static const struct dma_map_ops *pci_dma_ops = &dma_nommu_ops;
+static const struct dma_map_ops *pci_dma_ops = &dma_direct_ops;

void set_pci_dma_ops(const struct dma_map_ops *dma_ops)
{
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 93ee3703b42f..104228c0e980 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -791,7 +791,7 @@ void arch_setup_pdev_archdata(struct platform_device *pdev)
{
pdev->archdata.dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = &pdev->archdata.dma_mask;
- set_dma_ops(&pdev->dev, &dma_nommu_ops);
+ set_dma_ops(&pdev->dev, &dma_direct_ops);
}

static __init void print_system_info(void)
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index ee95da19c82d..b5d2658c26af 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -152,8 +152,8 @@ static struct ppc_vm_region *ppc_vm_region_find(struct ppc_vm_region *head, unsi
* Allocate DMA-coherent memory space and return both the kernel remapped
* virtual and bus address for that space.
*/
-void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+void *arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+ gfp_t gfp, unsigned long attrs)
{
struct page *page;
struct ppc_vm_region *c;
@@ -254,7 +254,7 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
/*
* free a page as defined by the above mapping.
*/
-void __dma_nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
+void arch_dma_free(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle, unsigned long attrs)
{
struct ppc_vm_region *c;
@@ -314,7 +314,7 @@ void __dma_nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
/*
* make an area consistent.
*/
-void __dma_sync(void *vaddr, size_t size, int direction)
+static void __dma_sync(void *vaddr, size_t size, int direction)
{
unsigned long start = (unsigned long)vaddr;
unsigned long end = start + size;
@@ -340,7 +340,6 @@ void __dma_sync(void *vaddr, size_t size, int direction)
break;
}
}
-EXPORT_SYMBOL(__dma_sync);

#ifdef CONFIG_HIGHMEM
/*
@@ -387,21 +386,33 @@ static inline void __dma_sync_page_highmem(struct page *page,
* __dma_sync_page makes memory consistent. identical to __dma_sync, but
* takes a struct page instead of a virtual address
*/
-void __dma_sync_page(struct page *page, unsigned long offset,
- size_t size, int direction)
+static void __dma_sync_page(phys_addr_t paddr, size_t size, int dir)
{
+ struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
+ unsigned offset = paddr & ~PAGE_MASK;
+
#ifdef CONFIG_HIGHMEM
- __dma_sync_page_highmem(page, offset, size, direction);
+ __dma_sync_page_highmem(page, offset, size, dir);
#else
unsigned long start = (unsigned long)page_address(page) + offset;
- __dma_sync((void *)start, size, direction);
+ __dma_sync((void *)start, size, dir);
#endif
}
-EXPORT_SYMBOL(__dma_sync_page);
+
+void arch_sync_dma_for_device(struct device *dev, phys_addr_t paddr,
+ size_t size, enum dma_data_direction dir)
+{
+ __dma_sync_page(paddr, size, dir);
+}
+
+void arch_sync_dma_for_cpu(struct device *dev, phys_addr_t paddr,
+ size_t size, enum dma_data_direction dir)
+{
+ __dma_sync_page(paddr, size, dir);
+}

/*
- * Return the PFN for a given cpu virtual address returned by
- * __dma_nommu_alloc_coherent.
+ * Return the PFN for a given cpu virtual address returned by arch_dma_alloc.
*/
long arch_dma_coherent_to_pfn(struct device *dev, void *vaddr,
dma_addr_t dma_addr)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c0b676c3a5ba..9a00f470434c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -69,15 +69,12 @@ pte_t *kmap_pte;
EXPORT_SYMBOL(kmap_pte);
pgprot_t kmap_prot;
EXPORT_SYMBOL(kmap_prot);
-#define TOP_ZONE ZONE_HIGHMEM

static inline pte_t *virt_to_kpte(unsigned long vaddr)
{
return pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr),
vaddr), vaddr), vaddr);
}
-#else
-#define TOP_ZONE ZONE_NORMAL
#endif

int page_is_ram(unsigned long pfn)
@@ -260,25 +257,6 @@ static int __init mark_nonram_nosave(void)
*/
static unsigned long max_zone_pfns[MAX_NR_ZONES];

-/*
- * Find the least restrictive zone that is entirely below the
- * specified pfn limit. Returns < 0 if no suitable zone is found.
- *
- * pfn_limit must be u64 because it can exceed 32 bits even on 32-bit
- * systems -- the DMA limit can be higher than any possible real pfn.
- */
-int dma_pfn_limit_to_zone(u64 pfn_limit)
-{
- int i;
-
- for (i = TOP_ZONE; i >= 0; i--) {
- if (max_zone_pfns[i] <= pfn_limit)
- return i;
- }
-
- return -EPERM;
-}
-
/*
* paging_init() sets up the page tables - in fact we've already done this.
*/
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 7e4f8ca19ce8..c0e6fb270d59 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -47,7 +47,7 @@ static int __init warp_probe(void)
if (!of_machine_is_compatible("pika,warp"))
return 0;

- /* For __dma_nommu_alloc_coherent */
+ /* For arch_dma_alloc */
ISA_DMA_THRESHOLD = ~0L;

return 1;
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 5fdfc1a6435c..d0ececddd62b 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -415,6 +415,8 @@ config NOT_COHERENT_CACHE
depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || \
GAMECUBE_COMMON || AMIGAONE
select ARCH_HAS_DMA_COHERENT_TO_PFN
+ select ARCH_HAS_SYNC_DMA_FOR_DEVICE
+ select ARCH_HAS_SYNC_DMA_FOR_CPU
default n if PPC_47x
default y

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 93c7e4aef571..75fd2ee57e26 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -601,7 +601,7 @@ static int cell_of_bus_notify(struct notifier_block *nb, unsigned long action,
if (cell_iommu_enabled)
dev->dma_ops = &dma_iommu_ops;
else
- dev->dma_ops = &dma_nommu_ops;
+ dev->dma_ops = &dma_direct_ops;
cell_dma_dev_setup(dev);
return 0;
}
@@ -727,7 +727,7 @@ static int __init cell_iommu_init_disabled(void)
unsigned long base = 0, size;

/* When no iommu is present, we use direct DMA ops */
- set_pci_dma_ops(&dma_nommu_ops);
+ set_pci_dma_ops(&dma_direct_ops);

/* First make sure all IOC translation is turned off */
cell_disable_iommus();
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index f2971522fb4a..4466ac61bce6 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -186,7 +186,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
*/
if (dev->vendor == 0x1959 && dev->device == 0xa007 &&
!firmware_has_feature(FW_FEATURE_LPAR)) {
- dev->dev.dma_ops = &dma_nommu_ops;
+ dev->dev.dma_ops = &dma_direct_ops;
/*
* Set the coherent DMA mask to prevent the iommu
* being used unnecessarily
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 9a6eb04cca83..afb44e3dd8d2 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -362,7 +362,7 @@ static int pcmcia_notify(struct notifier_block *nb, unsigned long action,
return 0;

/* We use the direct ops for localbus */
- dev->dma_ops = &dma_nommu_ops;
+ dev->dma_ops = &dma_direct_ops;

return 0;
}
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 63dbc4cfe60d..eabb5620d354 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1703,3 +1703,10 @@ int vio_disable_interrupts(struct vio_dev *dev)
}
EXPORT_SYMBOL(vio_disable_interrupts);
#endif /* CONFIG_PPC_PSERIES */
+
+static int __init vio_init(void)
+{
+ dma_debug_add_bus(&vio_bus_type);
+ return 0;
+}
+fs_initcall(vio_init);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index cb91a3d113d1..081ed84c3f4c 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -126,7 +126,7 @@ static void setup_swiotlb_ops(struct pci_controller *hose)
{
if (ppc_swiotlb_enable) {
hose->controller_ops.dma_dev_setup = pci_dma_dev_setup_swiotlb;
- set_pci_dma_ops(&powerpc_swiotlb_dma_ops);
+ set_pci_dma_ops(&swiotlb_dma_ops);
}
}
#else
diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c
index 49da2f744bbf..f4c0e9d2affe 100644
--- a/drivers/misc/cxl/vphb.c
+++ b/drivers/misc/cxl/vphb.c
@@ -43,7 +43,7 @@ static bool cxl_pci_enable_device_hook(struct pci_dev *dev)
return false;
}

- set_dma_ops(&dev->dev, &dma_nommu_ops);
+ set_dma_ops(&dev->dev, &dma_direct_ops);
set_dma_offset(&dev->dev, PAGE_OFFSET);

/*
--
2.19.1


2018-11-14 08:26:05

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 29/34] powerpc/dma: use phys_to_dma instead of get_dma_offset

Use the standard portable helper instead of the powerpc specific one,
which is about to go away.

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/kernel/dma.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index cf0ae0b3fb24..5c83a34f288f 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -6,7 +6,7 @@
*/

#include <linux/device.h>
-#include <linux/dma-mapping.h>
+#include <linux/dma-direct.h>
#include <linux/dma-debug.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
@@ -42,7 +42,7 @@ static u64 __maybe_unused get_pfn_limit(struct device *dev)
int dma_nommu_dma_supported(struct device *dev, u64 mask)
{
#ifdef CONFIG_PPC64
- u64 limit = get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
+ u64 limit = phys_to_dma(dev, (memblock_end_of_DRAM() - 1));

/* Limit fits in the mask, we are good */
if (mask >= limit)
@@ -100,7 +100,7 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
return NULL;
ret = page_address(page);
memset(ret, 0, size);
- *dma_handle = __pa(ret) + get_dma_offset(dev);
+ *dma_handle = phys_to_dma(dev,__pa(ret));

return ret;
}
@@ -139,7 +139,7 @@ int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
int i;

for_each_sg(sgl, sg, nents, i) {
- sg->dma_address = sg_phys(sg) + get_dma_offset(dev);
+ sg->dma_address = phys_to_dma(dev, sg_phys(sg));
sg->dma_length = sg->length;

if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
@@ -170,7 +170,7 @@ dma_addr_t dma_nommu_map_page(struct device *dev, struct page *page,
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
__dma_sync_page(page, offset, size, dir);

- return page_to_phys(page) + offset + get_dma_offset(dev);
+ return phys_to_dma(dev, page_to_phys(page)) + offset;
}

#ifdef CONFIG_NOT_COHERENT_CACHE
--
2.19.1


2018-11-14 08:26:11

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 11/34] powerpc/pseries: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/pseries/iommu.c | 100 +++++++------------------
1 file changed, 27 insertions(+), 73 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index da5716de7f4c..8965d174c53b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -973,7 +973,7 @@ static LIST_HEAD(failed_ddw_pdn_list);
* pdn: the parent pe node with the ibm,dma_window property
* Future: also check if we can remap the base window for our base page size
*
- * returns the dma offset for use by dma_set_mask
+ * returns the dma offset for use by the direct mapped DMA code.
*/
static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
{
@@ -1193,87 +1193,40 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
iommu_add_device(&dev->dev);
}

-static int dma_set_mask_pSeriesLP(struct device *dev, u64 dma_mask)
+static bool iommu_bypass_supported_pSeriesLP(struct pci_dev *pdev, u64 dma_mask)
{
- bool ddw_enabled = false;
- struct device_node *pdn, *dn;
- struct pci_dev *pdev;
+ struct device_node *dn = pci_device_to_OF_node(pdev), *pdn;
const __be32 *dma_window = NULL;
u64 dma_offset;

- if (!dev->dma_mask)
- return -EIO;
-
- if (!dev_is_pci(dev))
- goto check_mask;
-
- pdev = to_pci_dev(dev);
-
/* only attempt to use a new window if 64-bit DMA is requested */
- if (!disable_ddw && dma_mask == DMA_BIT_MASK(64)) {
- dn = pci_device_to_OF_node(pdev);
- dev_dbg(dev, "node is %pOF\n", dn);
+ if (dma_mask < DMA_BIT_MASK(64))
+ return false;

- /*
- * the device tree might contain the dma-window properties
- * per-device and not necessarily for the bus. So we need to
- * search upwards in the tree until we either hit a dma-window
- * property, OR find a parent with a table already allocated.
- */
- for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->table_group;
- pdn = pdn->parent) {
- dma_window = of_get_property(pdn, "ibm,dma-window", NULL);
- if (dma_window)
- break;
- }
- if (pdn && PCI_DN(pdn)) {
- dma_offset = enable_ddw(pdev, pdn);
- if (dma_offset != 0) {
- dev_info(dev, "Using 64-bit direct DMA at offset %llx\n", dma_offset);
- set_dma_offset(dev, dma_offset);
- set_dma_ops(dev, &dma_nommu_ops);
- ddw_enabled = true;
- }
- }
- }
+ dev_dbg(&pdev->dev, "node is %pOF\n", dn);

- /* fall back on iommu ops */
- if (!ddw_enabled && get_dma_ops(dev) != &dma_iommu_ops) {
- dev_info(dev, "Restoring 32-bit DMA via iommu\n");
- set_dma_ops(dev, &dma_iommu_ops);
+ /*
+ * the device tree might contain the dma-window properties
+ * per-device and not necessarily for the bus. So we need to
+ * search upwards in the tree until we either hit a dma-window
+ * property, OR find a parent with a table already allocated.
+ */
+ for (pdn = dn; pdn && PCI_DN(pdn) && !PCI_DN(pdn)->table_group;
+ pdn = pdn->parent) {
+ dma_window = of_get_property(pdn, "ibm,dma-window", NULL);
+ if (dma_window)
+ break;
}

-check_mask:
- if (!dma_supported(dev, dma_mask))
- return -EIO;
-
- *dev->dma_mask = dma_mask;
- return 0;
-}
-
-static u64 dma_get_required_mask_pSeriesLP(struct device *dev)
-{
- if (!dev->dma_mask)
- return 0;
-
- if (!disable_ddw && dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
- struct device_node *dn;
-
- dn = pci_device_to_OF_node(pdev);
-
- /* search upwards for ibm,dma-window */
- for (; dn && PCI_DN(dn) && !PCI_DN(dn)->table_group;
- dn = dn->parent)
- if (of_get_property(dn, "ibm,dma-window", NULL))
- break;
- /* if there is a ibm,ddw-applicable property require 64 bits */
- if (dn && PCI_DN(dn) &&
- of_get_property(dn, "ibm,ddw-applicable", NULL))
- return DMA_BIT_MASK(64);
+ if (pdn && PCI_DN(pdn)) {
+ dma_offset = enable_ddw(pdev, pdn);
+ if (dma_offset != 0) {
+ set_dma_offset(&pdev->dev, dma_offset);
+ return true;
+ }
}

- return dma_iommu_get_required_mask(dev);
+ return false;
}

static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
@@ -1368,8 +1321,9 @@ void iommu_init_early_pSeries(void)
if (firmware_has_feature(FW_FEATURE_LPAR)) {
pseries_pci_controller_ops.dma_bus_setup = pci_dma_bus_setup_pSeriesLP;
pseries_pci_controller_ops.dma_dev_setup = pci_dma_dev_setup_pSeriesLP;
- ppc_md.dma_set_mask = dma_set_mask_pSeriesLP;
- ppc_md.dma_get_required_mask = dma_get_required_mask_pSeriesLP;
+ if (!disable_ddw)
+ pseries_pci_controller_ops.iommu_bypass_supported =
+ iommu_bypass_supported_pSeriesLP;
} else {
pseries_pci_controller_ops.dma_bus_setup = pci_dma_bus_setup_pSeries;
pseries_pci_controller_ops.dma_dev_setup = pci_dma_dev_setup_pSeries;
--
2.19.1


2018-11-14 08:26:28

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 34/34] powerpc/dma: trim the fat from <asm/dma-mapping.h>

There is no need to provide anything but get_arch_dma_ops to
<linux/dma-mapping.h>. More the remaining declarations to <asm/iommu.h>
and drop all the includes.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 29 -------------------
arch/powerpc/include/asm/iommu.h | 10 +++++++
arch/powerpc/platforms/44x/ppc476.c | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 1 +
arch/powerpc/sysdev/fsl_pci.c | 1 +
6 files changed, 14 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index a59c42879194..565d6f74b189 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -1,37 +1,9 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
* Copyright (C) 2004 IBM
- *
- * Implements the generic device dma API for powerpc.
- * the pci and vio busses
*/
#ifndef _ASM_DMA_MAPPING_H
#define _ASM_DMA_MAPPING_H
-#ifdef __KERNEL__
-
-#include <linux/types.h>
-#include <linux/cache.h>
-/* need struct page definitions */
-#include <linux/mm.h>
-#include <linux/scatterlist.h>
-#include <linux/dma-debug.h>
-#include <asm/io.h>
-#include <asm/swiotlb.h>
-
-static inline unsigned long device_to_mask(struct device *dev)
-{
- if (dev->dma_mask && *dev->dma_mask)
- return *dev->dma_mask;
- /* Assume devices without mask can take 32 bit addresses */
- return 0xfffffffful;
-}
-
-/*
- * Available generic sets of operations
- */
-#ifdef CONFIG_PPC64
-extern const struct dma_map_ops dma_iommu_ops;
-#endif

static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
{
@@ -43,5 +15,4 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
return NULL;
}

-#endif /* __KERNEL__ */
#endif /* _ASM_DMA_MAPPING_H */
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 5128aac8e165..46a8d4716d90 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -332,5 +332,15 @@ extern bool iommu_fixed_is_weak;
#define iommu_fixed_is_weak false
#endif

+extern const struct dma_map_ops dma_iommu_ops;
+
+static inline unsigned long device_to_mask(struct device *dev)
+{
+ if (dev->dma_mask && *dev->dma_mask)
+ return *dev->dma_mask;
+ /* Assume devices without mask can take 32 bit addresses */
+ return 0xfffffffful;
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/platforms/44x/ppc476.c b/arch/powerpc/platforms/44x/ppc476.c
index e55933f9cd55..a5e61e5c16e2 100644
--- a/arch/powerpc/platforms/44x/ppc476.c
+++ b/arch/powerpc/platforms/44x/ppc476.c
@@ -34,6 +34,7 @@
#include <asm/ppc4xx.h>
#include <asm/mpic.h>
#include <asm/mmu.h>
+#include <asm/swiotlb.h>

#include <linux/pci.h>
#include <linux/i2c.h>
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index b0dac307bebf..0ea13697189e 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -27,6 +27,7 @@
#include <asm/udbg.h>
#include <asm/mpic.h>
#include <asm/ehv_pic.h>
+#include <asm/swiotlb.h>
#include <soc/fsl/qe/qe_ic.h>

#include <linux/of_platform.h>
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
index 27631c607f3d..c52c8f9e8385 100644
--- a/arch/powerpc/platforms/85xx/qemu_e500.c
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -22,6 +22,7 @@
#include <asm/time.h>
#include <asm/udbg.h>
#include <asm/mpic.h>
+#include <asm/swiotlb.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>
#include "smp.h"
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 964a4aede6b1..9584765dbe3b 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -40,6 +40,7 @@
#include <asm/mpc85xx.h>
#include <asm/disassemble.h>
#include <asm/ppc-opcode.h>
+#include <asm/swiotlb.h>
#include <sysdev/fsl_soc.h>
#include <sysdev/fsl_pci.h>

--
2.19.1


2018-11-14 08:26:32

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 33/34] powerpc/dma: remove set_dma_offset

There is no good reason for this helper, just opencode it.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 6 ------
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 4 ++--
arch/powerpc/platforms/powernv/pci-ioda.c | 6 +++---
arch/powerpc/platforms/pseries/iommu.c | 7 ++-----
arch/powerpc/sysdev/dart_iommu.c | 2 +-
arch/powerpc/sysdev/fsl_pci.c | 2 +-
drivers/misc/cxl/vphb.c | 2 +-
8 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index c70f55d2f5e0..a59c42879194 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -43,11 +43,5 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
return NULL;
}

-static inline void set_dma_offset(struct device *dev, dma_addr_t off)
-{
- if (dev)
- dev->archdata.dma_offset = off;
-}
-
#endif /* __KERNEL__ */
#endif /* _ASM_DMA_MAPPING_H */
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 661b937f31ed..b645b3882815 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -966,7 +966,7 @@ static void pcibios_setup_device(struct pci_dev *dev)

/* Hook up default DMA ops */
set_dma_ops(&dev->dev, pci_dma_ops);
- set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
+ dev->dev.archdata.dma_offset = PCI_DRAM_OFFSET;

/* Additional platform DMA/iommu setup */
phb = pci_bus_to_host(dev->bus);
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 75fd2ee57e26..348a815779c1 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -577,10 +577,10 @@ static void cell_dma_dev_setup(struct device *dev)
u64 addr = cell_iommu_get_fixed_address(dev);

if (addr != OF_BAD_ADDR)
- set_dma_offset(dev, addr + dma_iommu_fixed_base);
+ dev->archdata.dma_offset = addr + dma_iommu_fixed_base;
set_iommu_table_base(dev, cell_get_iommu_table(dev));
} else {
- set_dma_offset(dev, cell_dma_nommu_offset);
+ dev->archdata.dma_offset = cell_dma_nommu_offset;
}
}

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 23fd46cd2ab3..e516d99bb2ed 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1735,7 +1735,7 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev

pe = &phb->ioda.pe_array[pdn->pe_number];
WARN_ON(get_dma_ops(&pdev->dev) != &dma_iommu_ops);
- set_dma_offset(&pdev->dev, pe->tce_bypass_base);
+ pdev->dev.archdata.dma_offset = pe->tce_bypass_base;
set_iommu_table_base(&pdev->dev, pe->table_group.tables[0]);
/*
* Note: iommu_add_device() will fail here as
@@ -1848,7 +1848,7 @@ static bool pnv_pci_ioda_iommu_bypass_supported(struct pci_dev *pdev,
if (rc)
return rc;
/* 4GB offset bypasses 32-bit space */
- set_dma_offset(&pdev->dev, (1ULL << 32));
+ pdev->dev.archdata.dma_offset = (1ULL << 32);
return true;
}

@@ -1863,7 +1863,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,

list_for_each_entry(dev, &bus->devices, bus_list) {
set_iommu_table_base(&dev->dev, pe->table_group.tables[0]);
- set_dma_offset(&dev->dev, pe->tce_bypass_base);
+ dev->dev.archdata.dma_offset = pe->tce_bypass_base;
if (add_to_group)
iommu_add_device(&dev->dev);

diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 8965d174c53b..a2ff20d154fe 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1197,7 +1197,6 @@ static bool iommu_bypass_supported_pSeriesLP(struct pci_dev *pdev, u64 dma_mask)
{
struct device_node *dn = pci_device_to_OF_node(pdev), *pdn;
const __be32 *dma_window = NULL;
- u64 dma_offset;

/* only attempt to use a new window if 64-bit DMA is requested */
if (dma_mask < DMA_BIT_MASK(64))
@@ -1219,11 +1218,9 @@ static bool iommu_bypass_supported_pSeriesLP(struct pci_dev *pdev, u64 dma_mask)
}

if (pdn && PCI_DN(pdn)) {
- dma_offset = enable_ddw(pdev, pdn);
- if (dma_offset != 0) {
- set_dma_offset(&pdev->dev, dma_offset);
+ pdev->dev.archdata.dma_offset = enable_ddw(pdev, pdn);
+ if (pdev->dev.archdata.dma_offset)
return true;
- }
}

return false;
diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 2681a19347ba..2e24fc87ed84 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -386,7 +386,7 @@ static bool dart_device_on_pcie(struct device *dev)
static void pci_dma_dev_setup_dart(struct pci_dev *dev)
{
if (dart_is_u4 && dart_device_on_pcie(&dev->dev))
- set_dma_offset(&dev->dev, DART_U4_BYPASS_BASE);
+ dev->dev.archdata.dma_offset = DART_U4_BYPASS_BASE;
set_iommu_table_base(&dev->dev, &iommu_table_dart);
}

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 081ed84c3f4c..964a4aede6b1 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -141,7 +141,7 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
*/
if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
dev->bus_dma_mask = 0;
- set_dma_offset(dev, pci64_dma_offset);
+ dev->archdata.dma_offset = pci64_dma_offset;
}

return 0;
diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c
index f4c0e9d2affe..f4ca1a4ada66 100644
--- a/drivers/misc/cxl/vphb.c
+++ b/drivers/misc/cxl/vphb.c
@@ -44,7 +44,7 @@ static bool cxl_pci_enable_device_hook(struct pci_dev *dev)
}

set_dma_ops(&dev->dev, &dma_direct_ops);
- set_dma_offset(&dev->dev, PAGE_OFFSET);
+ dev->dev.archdata.dma_offset = PAGE_OFFSET;

/*
* Allocate a context to do cxl things too. If we eventually do real
--
2.19.1


2018-11-14 08:26:35

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

Configure the dma settings at device setup time, and stop playing games
with get_pci_dma_ops. This prepares for using the common dma_configure
code later on.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 12352a58072a..cce5bf9515e5 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -657,14 +657,21 @@ static const struct dma_map_ops dma_iommu_fixed_ops = {
.mapping_error = dma_iommu_mapping_error,
};

+static u64 cell_iommu_get_fixed_address(struct device *dev);
+
static void cell_dma_dev_setup(struct device *dev)
{
- if (get_pci_dma_ops() == &dma_iommu_ops)
+ if (get_pci_dma_ops() == &dma_iommu_ops) {
+ u64 addr = cell_iommu_get_fixed_address(dev);
+
+ if (addr != OF_BAD_ADDR)
+ set_dma_offset(dev, addr + dma_iommu_fixed_base);
set_iommu_table_base(dev, cell_get_iommu_table(dev));
- else if (get_pci_dma_ops() == &dma_nommu_ops)
+ } else if (get_pci_dma_ops() == &dma_nommu_ops) {
set_dma_offset(dev, cell_dma_nommu_offset);
- else
+ } else {
BUG();
+ }
}

static void cell_pci_dma_dev_setup(struct pci_dev *dev)
@@ -950,19 +957,14 @@ static int dma_suported_and_switch(struct device *dev, u64 dma_mask)
{
if (dma_mask == DMA_BIT_MASK(64) &&
cell_iommu_get_fixed_address(dev) != OF_BAD_ADDR) {
- u64 addr = cell_iommu_get_fixed_address(dev) +
- dma_iommu_fixed_base;
dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
- dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
set_dma_ops(dev, &dma_iommu_fixed_ops);
- set_dma_offset(dev, addr);
return 1;
}

if (dma_iommu_dma_supported(dev, dma_mask)) {
dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
- set_dma_ops(dev, get_pci_dma_ops());
- cell_dma_dev_setup(dev);
+ set_dma_ops(dev, &dma_iommu_ops);
return 1;
}

--
2.19.1


2018-11-14 08:26:41

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 28/34] dma-mapping, powerpc: simplify the arch dma_set_mask override

Instead of letting the architecture supply all of dma_set_mask just
give it an additional hook selected by Kconfig.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/dma-mapping.h | 3 ---
arch/powerpc/kernel/dma-swiotlb.c | 8 ++++++++
arch/powerpc/kernel/dma.c | 12 ------------
arch/powerpc/sysdev/fsl_pci.c | 4 ----
include/linux/dma-mapping.h | 11 ++++++++---
kernel/dma/Kconfig | 3 +++
7 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2d4a19bc8023..4f03997ad54a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -126,6 +126,7 @@ config PPC
# Please keep this list sorted alphabetically.
#
select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_SET_MASK if SWIOTLB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index e5ee4ac97c14..16d45518d9bb 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -110,8 +110,5 @@ static inline void set_dma_offset(struct device *dev, dma_addr_t off)
dev->archdata.dma_offset = off;
}

-#define HAVE_ARCH_DMA_SET_MASK 1
-extern int dma_set_mask(struct device *dev, u64 dma_mask);
-
#endif /* __KERNEL__ */
#endif /* _ASM_DMA_MAPPING_H */
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 62caa16b91a9..b3266f7a6915 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -22,6 +22,14 @@
#include <asm/swiotlb.h>
#include <asm/dma.h>

+bool arch_dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ if (!ppc_md.dma_set_mask)
+ return 0;
+ return ppc_md.dma_set_mask(dev, dma_mask);
+}
+EXPORT_SYMBOL(arch_dma_set_mask);
+
unsigned int ppc_swiotlb_enable;

/*
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 59f38ca3975c..cf0ae0b3fb24 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -209,18 +209,6 @@ const struct dma_map_ops dma_nommu_ops = {
};
EXPORT_SYMBOL(dma_nommu_ops);

-int dma_set_mask(struct device *dev, u64 dma_mask)
-{
- if (ppc_md.dma_set_mask)
- return ppc_md.dma_set_mask(dev, dma_mask);
-
- if (!dev->dma_mask || !dma_supported(dev, dma_mask))
- return -EIO;
- *dev->dma_mask = dma_mask;
- return 0;
-}
-EXPORT_SYMBOL(dma_set_mask);
-
static int __init dma_init(void)
{
#ifdef CONFIG_IBMVIO
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 296ffabc9386..cb91a3d113d1 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -135,9 +135,6 @@ static inline void setup_swiotlb_ops(struct pci_controller *hose) {}

static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!dev->dma_mask || !dma_supported(dev, dma_mask))
- return -EIO;
-
/*
* Fix up PCI devices that are able to DMA to the large inbound
* mapping that allows addressing any RAM address from across PCI.
@@ -147,7 +144,6 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
set_dma_offset(dev, pci64_dma_offset);
}

- *dev->dma_mask = dma_mask;
return 0;
}

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 15bd41447025..8dd19e66c0e5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -598,18 +598,23 @@ static inline int dma_supported(struct device *dev, u64 mask)
return ops->dma_supported(dev, mask);
}

-#ifndef HAVE_ARCH_DMA_SET_MASK
+#ifdef CONFIG_ARCH_HAS_DMA_SET_MASK
+bool arch_dma_set_mask(struct device *dev, u64 mask);
+#else
+#define arch_dma_set_mask(dev, mask) true
+#endif
+
static inline int dma_set_mask(struct device *dev, u64 mask)
{
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
-
+ if (!arch_dma_set_mask(dev, mask))
+ return -EIO;
dma_check_mask(dev, mask);

*dev->dma_mask = mask;
return 0;
}
-#endif

static inline u64 dma_get_mask(struct device *dev)
{
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 645c7a2ecde8..951045c90c2c 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -16,6 +16,9 @@ config ARCH_DMA_ADDR_T_64BIT
config ARCH_HAS_DMA_COHERENCE_H
bool

+config ARCH_HAS_DMA_SET_MASK
+ bool
+
config HAVE_GENERIC_DMA_COHERENT
bool

--
2.19.1


2018-11-14 08:26:58

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 25/34] powerpc/dma: remove max_direct_dma_addr

The max_direct_dma_addr duplicates the bus_dma_mask field in struct
device. Use the generic field instead.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/device.h | 3 ---
arch/powerpc/include/asm/dma-direct.h | 4 +---
arch/powerpc/kernel/dma-swiotlb.c | 20 --------------------
arch/powerpc/kernel/dma.c | 5 ++---
arch/powerpc/sysdev/fsl_pci.c | 3 +--
5 files changed, 4 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
index 3814e1c2d4bc..a130be13ee83 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -38,9 +38,6 @@ struct dev_archdata {
#ifdef CONFIG_IOMMU_API
void *iommu_domain;
#endif
-#ifdef CONFIG_SWIOTLB
- dma_addr_t max_direct_dma_addr;
-#endif
#ifdef CONFIG_PPC64
struct pci_dn *pci_data;
#endif
diff --git a/arch/powerpc/include/asm/dma-direct.h b/arch/powerpc/include/asm/dma-direct.h
index 7702875aabb7..e00ab5d0612d 100644
--- a/arch/powerpc/include/asm/dma-direct.h
+++ b/arch/powerpc/include/asm/dma-direct.h
@@ -5,9 +5,7 @@
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
{
#ifdef CONFIG_SWIOTLB
- struct dev_archdata *sd = &dev->archdata;
-
- if (sd->max_direct_dma_addr && addr + size > sd->max_direct_dma_addr)
+ if (dev->bus_dma_mask && addr + size > dev->bus_dma_mask)
return false;
#endif

diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 38a2c9f5ab54..62caa16b91a9 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -24,21 +24,6 @@

unsigned int ppc_swiotlb_enable;

-static u64 swiotlb_powerpc_get_required(struct device *dev)
-{
- u64 end, mask, max_direct_dma_addr = dev->archdata.max_direct_dma_addr;
-
- end = memblock_end_of_DRAM();
- if (max_direct_dma_addr && end > max_direct_dma_addr)
- end = max_direct_dma_addr;
- end += get_dma_offset(dev);
-
- mask = 1ULL << (fls64(end) - 1);
- mask += mask - 1;
-
- return mask;
-}
-
/*
* At the moment, all platforms that use this code only require
* swiotlb to be used if we're operating on HIGHMEM. Since
@@ -60,22 +45,17 @@ const struct dma_map_ops powerpc_swiotlb_dma_ops = {
.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
.sync_sg_for_device = swiotlb_sync_sg_for_device,
.mapping_error = dma_direct_mapping_error,
- .get_required_mask = swiotlb_powerpc_get_required,
};

static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
struct device *dev = data;
- struct dev_archdata *sd;

/* We are only intereted in device addition */
if (action != BUS_NOTIFY_ADD_DEVICE)
return 0;

- sd = &dev->archdata;
- sd->max_direct_dma_addr = 0;
-
/* May need to bounce if the device can't address all of DRAM */
if ((dma_get_mask(dev) + 1) < memblock_end_of_DRAM())
set_dma_ops(dev, &powerpc_swiotlb_dma_ops);
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index f9f51fc505a1..59f38ca3975c 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -30,11 +30,10 @@
static u64 __maybe_unused get_pfn_limit(struct device *dev)
{
u64 pfn = (dev->coherent_dma_mask >> PAGE_SHIFT) + 1;
- struct dev_archdata __maybe_unused *sd = &dev->archdata;

#ifdef CONFIG_SWIOTLB
- if (sd->max_direct_dma_addr && dev->dma_ops == &powerpc_swiotlb_dma_ops)
- pfn = min_t(u64, pfn, sd->max_direct_dma_addr >> PAGE_SHIFT);
+ if (dev->bus_dma_mask && dev->dma_ops == &powerpc_swiotlb_dma_ops)
+ pfn = min_t(u64, pfn, dev->bus_dma_mask >> PAGE_SHIFT);
#endif

return pfn;
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 561f97d698cc..f136567a5ed5 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -117,9 +117,8 @@ static u64 pci64_dma_offset;
static void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
{
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- struct dev_archdata *sd = &pdev->dev.archdata;

- sd->max_direct_dma_addr =
+ pdev->dev.bus_dma_mask =
hose->dma_window_base_cur + hose->dma_window_size;
}

--
2.19.1


2018-11-14 08:27:01

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 24/34] powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c

pci_dma_dev_setup_swiotlb is only used by the fsl_pci code, and closely
related to it, so fsl_pci.c seems like a better place for it.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/swiotlb.h | 2 --
arch/powerpc/kernel/dma-swiotlb.c | 11 -----------
arch/powerpc/sysdev/fsl_pci.c | 9 +++++++++
3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/swiotlb.h b/arch/powerpc/include/asm/swiotlb.h
index f65ecf57b66c..26a0f12b835b 100644
--- a/arch/powerpc/include/asm/swiotlb.h
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -18,8 +18,6 @@ extern const struct dma_map_ops powerpc_swiotlb_dma_ops;
extern unsigned int ppc_swiotlb_enable;
int __init swiotlb_setup_bus_notifier(void);

-extern void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev);
-
#ifdef CONFIG_SWIOTLB
void swiotlb_detect_4g(void);
#else
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 678811abccfc..38a2c9f5ab54 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -63,17 +63,6 @@ const struct dma_map_ops powerpc_swiotlb_dma_ops = {
.get_required_mask = swiotlb_powerpc_get_required,
};

-void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
-{
- struct pci_controller *hose;
- struct dev_archdata *sd;
-
- hose = pci_bus_to_host(pdev->bus);
- sd = &pdev->dev.archdata;
- sd->max_direct_dma_addr =
- hose->dma_window_base_cur + hose->dma_window_size;
-}
-
static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 918be816b097..561f97d698cc 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -114,6 +114,15 @@ static struct pci_ops fsl_indirect_pcie_ops =
static u64 pci64_dma_offset;

#ifdef CONFIG_SWIOTLB
+static void pci_dma_dev_setup_swiotlb(struct pci_dev *pdev)
+{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct dev_archdata *sd = &pdev->dev.archdata;
+
+ sd->max_direct_dma_addr =
+ hose->dma_window_base_cur + hose->dma_window_size;
+}
+
static void setup_swiotlb_ops(struct pci_controller *hose)
{
if (ppc_swiotlb_enable) {
--
2.19.1


2018-11-14 08:27:01

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 27/34] powerpc/fsl_pci: simplify fsl_pci_dma_set_mask

swiotlb will only bounce buffer the effectice dma address for the device
is smaller than the actual DMA range. Instead of flipping between the
swiotlb and nommu ops for FSL SOCs that have the second outbound window
just don't set the bus dma_mask in this case.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/sysdev/fsl_pci.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index f136567a5ed5..296ffabc9386 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -143,7 +143,7 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
* mapping that allows addressing any RAM address from across PCI.
*/
if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
- set_dma_ops(dev, &dma_nommu_ops);
+ dev->bus_dma_mask = 0;
set_dma_offset(dev, pci64_dma_offset);
}

@@ -403,10 +403,6 @@ static void setup_pci_atmu(struct pci_controller *hose)
out_be32(&pci->piw[win_idx].piwar, piwar);
}

- /*
- * install our own dma_set_mask handler to fixup dma_ops
- * and dma_offset
- */
ppc_md.dma_set_mask = fsl_pci_dma_set_mask;

pr_info("%pOF: Setup 64-bit PCI DMA window\n", hose->dn);
--
2.19.1


2018-11-14 08:27:18

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 30/34] powerpc/dma: remove dma_nommu_mmap_coherent

The coherent cache version of this function already is functionally
identicall to the default version, and by defining the
arch_dma_coherent_to_pfn hook the same is ture for the noncoherent
version as well.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 4 ----
arch/powerpc/kernel/dma-iommu.c | 1 -
arch/powerpc/kernel/dma-swiotlb.c | 1 -
arch/powerpc/kernel/dma.c | 19 -------------------
arch/powerpc/mm/dma-noncoherent.c | 7 +++++--
arch/powerpc/platforms/Kconfig.cputype | 1 +
arch/powerpc/platforms/pseries/vio.c | 1 -
7 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 16d45518d9bb..f19c486e7b3f 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -25,10 +25,6 @@ extern void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
extern void __dma_nommu_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
unsigned long attrs);
-extern int dma_nommu_mmap_coherent(struct device *dev,
- struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t handle,
- size_t size, unsigned long attrs);
int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction direction,
unsigned long attrs);
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 4937b39e246b..5b15e53ee43d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -172,7 +172,6 @@ int dma_iommu_mapping_error(struct device *dev, dma_addr_t dma_addr)
const struct dma_map_ops dma_iommu_ops = {
.alloc = dma_iommu_alloc_coherent,
.free = dma_iommu_free_coherent,
- .mmap = dma_nommu_mmap_coherent,
.map_sg = dma_iommu_map_sg,
.unmap_sg = dma_iommu_unmap_sg,
.dma_supported = dma_iommu_dma_supported,
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index b3266f7a6915..03df252ff5fb 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -42,7 +42,6 @@ unsigned int ppc_swiotlb_enable;
const struct dma_map_ops powerpc_swiotlb_dma_ops = {
.alloc = __dma_nommu_alloc_coherent,
.free = __dma_nommu_free_coherent,
- .mmap = dma_nommu_mmap_coherent,
.map_sg = swiotlb_map_sg_attrs,
.unmap_sg = swiotlb_unmap_sg_attrs,
.dma_supported = swiotlb_dma_supported,
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 5c83a34f288f..a6590aa77181 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -113,24 +113,6 @@ void __dma_nommu_free_coherent(struct device *dev, size_t size,
}
#endif /* !CONFIG_NOT_COHERENT_CACHE */

-int dma_nommu_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t handle, size_t size,
- unsigned long attrs)
-{
- unsigned long pfn;
-
-#ifdef CONFIG_NOT_COHERENT_CACHE
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- pfn = __dma_get_coherent_pfn((unsigned long)cpu_addr);
-#else
- pfn = page_to_pfn(virt_to_page(cpu_addr));
-#endif
- return remap_pfn_range(vma, vma->vm_start,
- pfn + vma->vm_pgoff,
- vma->vm_end - vma->vm_start,
- vma->vm_page_prot);
-}
-
int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction direction,
unsigned long attrs)
@@ -196,7 +178,6 @@ static inline void dma_nommu_sync_single(struct device *dev,
const struct dma_map_ops dma_nommu_ops = {
.alloc = __dma_nommu_alloc_coherent,
.free = __dma_nommu_free_coherent,
- .mmap = dma_nommu_mmap_coherent,
.map_sg = dma_nommu_map_sg,
.dma_supported = dma_nommu_dma_supported,
.map_page = dma_nommu_map_page,
diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index e955539686a4..ee95da19c82d 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -30,6 +30,7 @@
#include <linux/types.h>
#include <linux/highmem.h>
#include <linux/dma-direct.h>
+#include <linux/dma-noncoherent.h>
#include <linux/export.h>

#include <asm/tlbflush.h>
@@ -400,14 +401,16 @@ EXPORT_SYMBOL(__dma_sync_page);

/*
* Return the PFN for a given cpu virtual address returned by
- * __dma_nommu_alloc_coherent. This is used by dma_mmap_coherent()
+ * __dma_nommu_alloc_coherent.
*/
-unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr)
+long arch_dma_coherent_to_pfn(struct device *dev, void *vaddr,
+ dma_addr_t dma_addr)
{
/* This should always be populated, so we don't test every
* level. If that fails, we'll have a nice crash which
* will be as good as a BUG_ON()
*/
+ unsigned long cpu_addr = (unsigned long)vaddr;
pgd_t *pgd = pgd_offset_k(cpu_addr);
pud_t *pud = pud_offset(pgd, cpu_addr);
pmd_t *pmd = pmd_offset(pud, cpu_addr);
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 6fedbf349fce..5fdfc1a6435c 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -414,6 +414,7 @@ config NOT_COHERENT_CACHE
bool
depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || \
GAMECUBE_COMMON || AMIGAONE
+ select ARCH_HAS_DMA_COHERENT_TO_PFN
default n if PPC_47x
default y

diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index ea3a9745c812..63dbc4cfe60d 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -603,7 +603,6 @@ static void vio_dma_iommu_unmap_sg(struct device *dev,
static const struct dma_map_ops vio_dma_mapping_ops = {
.alloc = vio_dma_iommu_alloc_coherent,
.free = vio_dma_iommu_free_coherent,
- .mmap = dma_nommu_mmap_coherent,
.map_sg = vio_dma_iommu_map_sg,
.unmap_sg = vio_dma_iommu_unmap_sg,
.map_page = vio_dma_iommu_map_page,
--
2.19.1


2018-11-14 08:27:21

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 14/34] powerpc/dart: remove dead cleanup code in iommu_init_early_dart

If dart_init failed we didn't have a chance to setup dma or controller
ops yet, so there is no point in resetting them.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/sysdev/dart_iommu.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index a5b40d1460f1..283ce04c5844 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -428,7 +428,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)

/* Initialize the DART HW */
if (dart_init(dn) != 0)
- goto bail;
+ return;

/* Setup bypass if supported */
if (dart_is_u4)
@@ -439,15 +439,6 @@ void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)

/* Setup pci_dma ops */
set_pci_dma_ops(&dma_iommu_ops);
- return;
-
- bail:
- /* If init failed, use direct iommu and null setup functions */
- controller_ops->dma_dev_setup = NULL;
- controller_ops->dma_bus_setup = NULL;
-
- /* Setup pci_dma ops */
- set_pci_dma_ops(&dma_nommu_ops);
}

#ifdef CONFIG_PM
--
2.19.1


2018-11-14 08:27:24

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 32/34] powerpc/dma: remove get_dma_offset

Just fold the calculation into __phys_to_dma/__dma_to_phys as those are
the only places that should know about it.

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/include/asm/dma-direct.h | 8 ++++++--
arch/powerpc/include/asm/dma-mapping.h | 16 ----------------
2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-direct.h b/arch/powerpc/include/asm/dma-direct.h
index 92d8aed86422..a2912b47102c 100644
--- a/arch/powerpc/include/asm/dma-direct.h
+++ b/arch/powerpc/include/asm/dma-direct.h
@@ -13,11 +13,15 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)

static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
{
- return paddr + get_dma_offset(dev);
+ if (!dev)
+ return paddr + PCI_DRAM_OFFSET;
+ return paddr + dev->archdata.dma_offset;
}

static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr)
{
- return daddr - get_dma_offset(dev);
+ if (!dev)
+ return daddr - PCI_DRAM_OFFSET;
+ return daddr - dev->archdata.dma_offset;
}
#endif /* ASM_POWERPC_DMA_DIRECT_H */
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 93e57e28be28..c70f55d2f5e0 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -43,22 +43,6 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
return NULL;
}

-/*
- * get_dma_offset()
- *
- * Get the dma offset on configurations where the dma address can be determined
- * from the physical address by looking at a simple offset. Direct dma and
- * swiotlb use this function, but it is typically not used by implementations
- * with an iommu.
- */
-static inline dma_addr_t get_dma_offset(struct device *dev)
-{
- if (dev)
- return dev->archdata.dma_offset;
-
- return PCI_DRAM_OFFSET;
-}
-
static inline void set_dma_offset(struct device *dev, dma_addr_t off)
{
if (dev)
--
2.19.1


2018-11-14 08:27:27

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 17/34] powerpc/powernv: remove pnv_npu_dma_set_mask

These devices are not PCIe devices and do not have associated dma map
ops, so this is just dead code.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 ---------
1 file changed, 9 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index afbb73cd3c5b..1d9f446f3eff 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3688,14 +3688,6 @@ static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
.shutdown = pnv_pci_ioda_shutdown,
};

-static int pnv_npu_dma_set_mask(struct pci_dev *npdev, u64 dma_mask)
-{
- dev_err_once(&npdev->dev,
- "%s operation unsupported for NVLink devices\n",
- __func__);
- return -EPERM;
-}
-
static const struct pci_controller_ops pnv_npu_ioda_controller_ops = {
.dma_dev_setup = pnv_pci_dma_dev_setup,
#ifdef CONFIG_PCI_MSI
@@ -3705,7 +3697,6 @@ static const struct pci_controller_ops pnv_npu_ioda_controller_ops = {
.enable_device_hook = pnv_pci_enable_device_hook,
.window_alignment = pnv_pci_window_alignment,
.reset_secondary_bus = pnv_pci_reset_secondary_bus,
- .dma_set_mask = pnv_npu_dma_set_mask,
.shutdown = pnv_pci_ioda_shutdown,
};

--
2.19.1


2018-11-14 08:27:31

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 13/34] powerpc/cell: use the generic iommu bypass code

This gets rid of a lot of clumsy code and finally allows us to mark
dma_iommu_ops const.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 2 +-
arch/powerpc/include/asm/iommu.h | 6 ++
arch/powerpc/kernel/dma-iommu.c | 7 +-
arch/powerpc/platforms/cell/iommu.c | 143 ++-----------------------
4 files changed, 22 insertions(+), 136 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 824f55995a18..140ce5ad3120 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -74,7 +74,7 @@ static inline unsigned long device_to_mask(struct device *dev)
* Available generic sets of operations
*/
#ifdef CONFIG_PPC64
-extern struct dma_map_ops dma_iommu_ops;
+extern const struct dma_map_ops dma_iommu_ops;
#endif
extern const struct dma_map_ops dma_nommu_ops;

diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 75daa10f31a4..5128aac8e165 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -326,5 +326,11 @@ extern void iommu_release_ownership(struct iommu_table *tbl);
extern enum dma_data_direction iommu_tce_direction(unsigned long tce);
extern unsigned long iommu_direction_to_tce_perm(enum dma_data_direction dir);

+#ifdef CONFIG_PPC_CELL_NATIVE
+extern bool iommu_fixed_is_weak;
+#else
+#define iommu_fixed_is_weak false
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 459be16f8334..4937b39e246b 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -20,14 +20,15 @@
*/
static inline bool dma_iommu_alloc_bypass(struct device *dev)
{
- return dev->archdata.iommu_bypass &&
+ return dev->archdata.iommu_bypass && !iommu_fixed_is_weak &&
dma_nommu_dma_supported(dev, dev->coherent_dma_mask);
}

static inline bool dma_iommu_map_bypass(struct device *dev,
unsigned long attrs)
{
- return dev->archdata.iommu_bypass;
+ return dev->archdata.iommu_bypass &&
+ (!iommu_fixed_is_weak || (attrs & DMA_ATTR_WEAK_ORDERING));
}

/* Allocates a contiguous real buffer and creates mappings over it.
@@ -168,7 +169,7 @@ int dma_iommu_mapping_error(struct device *dev, dma_addr_t dma_addr)
return dma_addr == IOMMU_MAPPING_ERROR;
}

-struct dma_map_ops dma_iommu_ops = {
+const struct dma_map_ops dma_iommu_ops = {
.alloc = dma_iommu_alloc_coherent,
.free = dma_iommu_free_coherent,
.mmap = dma_nommu_mmap_coherent,
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index cce5bf9515e5..fb51f78035ce 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -546,7 +546,7 @@ static unsigned long cell_dma_nommu_offset;
static unsigned long dma_iommu_fixed_base;

/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */
-static int iommu_fixed_is_weak;
+bool iommu_fixed_is_weak;

static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
@@ -568,95 +568,6 @@ static struct iommu_table *cell_get_iommu_table(struct device *dev)
return &window->table;
}

-/* A coherent allocation implies strong ordering */
-
-static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak)
- return iommu_alloc_coherent(dev, cell_get_iommu_table(dev),
- size, dma_handle,
- device_to_mask(dev), flag,
- dev_to_node(dev));
- else
- return dma_nommu_ops.alloc(dev, size, dma_handle, flag,
- attrs);
-}
-
-static void dma_fixed_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak)
- iommu_free_coherent(cell_get_iommu_table(dev), size, vaddr,
- dma_handle);
- else
- dma_nommu_ops.free(dev, size, vaddr, dma_handle, attrs);
-}
-
-static dma_addr_t dma_fixed_map_page(struct device *dev, struct page *page,
- unsigned long offset, size_t size,
- enum dma_data_direction direction,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak == (attrs & DMA_ATTR_WEAK_ORDERING))
- return dma_nommu_ops.map_page(dev, page, offset, size,
- direction, attrs);
- else
- return iommu_map_page(dev, cell_get_iommu_table(dev), page,
- offset, size, device_to_mask(dev),
- direction, attrs);
-}
-
-static void dma_fixed_unmap_page(struct device *dev, dma_addr_t dma_addr,
- size_t size, enum dma_data_direction direction,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak == (attrs & DMA_ATTR_WEAK_ORDERING))
- dma_nommu_ops.unmap_page(dev, dma_addr, size, direction,
- attrs);
- else
- iommu_unmap_page(cell_get_iommu_table(dev), dma_addr, size,
- direction, attrs);
-}
-
-static int dma_fixed_map_sg(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak == (attrs & DMA_ATTR_WEAK_ORDERING))
- return dma_nommu_ops.map_sg(dev, sg, nents, direction, attrs);
- else
- return ppc_iommu_map_sg(dev, cell_get_iommu_table(dev), sg,
- nents, device_to_mask(dev),
- direction, attrs);
-}
-
-static void dma_fixed_unmap_sg(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- unsigned long attrs)
-{
- if (iommu_fixed_is_weak == (attrs & DMA_ATTR_WEAK_ORDERING))
- dma_nommu_ops.unmap_sg(dev, sg, nents, direction, attrs);
- else
- ppc_iommu_unmap_sg(cell_get_iommu_table(dev), sg, nents,
- direction, attrs);
-}
-
-static int dma_suported_and_switch(struct device *dev, u64 dma_mask);
-
-static const struct dma_map_ops dma_iommu_fixed_ops = {
- .alloc = dma_fixed_alloc_coherent,
- .free = dma_fixed_free_coherent,
- .map_sg = dma_fixed_map_sg,
- .unmap_sg = dma_fixed_unmap_sg,
- .dma_supported = dma_suported_and_switch,
- .map_page = dma_fixed_map_page,
- .unmap_page = dma_fixed_unmap_page,
- .mapping_error = dma_iommu_mapping_error,
-};
-
static u64 cell_iommu_get_fixed_address(struct device *dev);

static void cell_dma_dev_setup(struct device *dev)
@@ -953,22 +864,10 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)
return dev_addr;
}

-static int dma_suported_and_switch(struct device *dev, u64 dma_mask)
+static bool cell_pci_iommu_bypass_supported(struct pci_dev *pdev, u64 mask)
{
- if (dma_mask == DMA_BIT_MASK(64) &&
- cell_iommu_get_fixed_address(dev) != OF_BAD_ADDR) {
- dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
- set_dma_ops(dev, &dma_iommu_fixed_ops);
- return 1;
- }
-
- if (dma_iommu_dma_supported(dev, dma_mask)) {
- dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
- set_dma_ops(dev, &dma_iommu_ops);
- return 1;
- }
-
- return 0;
+ return mask == DMA_BIT_MASK(64) &&
+ cell_iommu_get_fixed_address(&pdev->dev) != OF_BAD_ADDR;
}

static void insert_16M_pte(unsigned long addr, unsigned long *ptab,
@@ -1122,9 +1021,6 @@ static int __init cell_iommu_fixed_mapping_init(void)
cell_iommu_setup_window(iommu, np, dbase, dsize, 0);
}

- dma_iommu_ops.dma_supported = dma_suported_and_switch;
- set_pci_dma_ops(&dma_iommu_ops);
-
return 0;
}

@@ -1145,7 +1041,7 @@ static int __init setup_iommu_fixed(char *str)
pciep = of_find_node_by_type(NULL, "pcie-endpoint");

if (strcmp(str, "weak") == 0 || (pciep && strcmp(str, "strong") != 0))
- iommu_fixed_is_weak = DMA_ATTR_WEAK_ORDERING;
+ iommu_fixed_is_weak = true;

of_node_put(pciep);

@@ -1153,26 +1049,6 @@ static int __init setup_iommu_fixed(char *str)
}
__setup("iommu_fixed=", setup_iommu_fixed);

-static u64 cell_dma_get_required_mask(struct device *dev)
-{
- const struct dma_map_ops *dma_ops;
-
- if (!dev->dma_mask)
- return 0;
-
- if (!iommu_fixed_disabled &&
- cell_iommu_get_fixed_address(dev) != OF_BAD_ADDR)
- return DMA_BIT_MASK(64);
-
- dma_ops = get_dma_ops(dev);
- if (dma_ops->get_required_mask)
- return dma_ops->get_required_mask(dev);
-
- WARN_ONCE(1, "no get_required_mask in %p ops", dma_ops);
-
- return DMA_BIT_MASK(64);
-}
-
static int __init cell_iommu_init(void)
{
struct device_node *np;
@@ -1189,10 +1065,9 @@ static int __init cell_iommu_init(void)

/* Setup various callbacks */
cell_pci_controller_ops.dma_dev_setup = cell_pci_dma_dev_setup;
- ppc_md.dma_get_required_mask = cell_dma_get_required_mask;

if (!iommu_fixed_disabled && cell_iommu_fixed_mapping_init() == 0)
- goto bail;
+ goto done;

/* Create an iommu for each /axon node. */
for_each_node_by_name(np, "axon") {
@@ -1209,8 +1084,12 @@ static int __init cell_iommu_init(void)
continue;
cell_iommu_init_one(np, SPIDER_DMA_OFFSET);
}
-
+ done:
/* Setup default PCI iommu ops */
+ if (!iommu_fixed_disabled) {
+ cell_pci_controller_ops.iommu_bypass_supported =
+ cell_pci_iommu_bypass_supported;
+ }
set_pci_dma_ops(&dma_iommu_ops);

bail:
--
2.19.1


2018-11-14 08:27:47

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 07/34] powerpc/dma: remove the no-op dma_nommu_unmap_{page,sg} routines

These methods are optional, no need to implement no-op versions.

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/kernel/dma.c | 16 ----------------
1 file changed, 16 deletions(-)

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index d6deb458bb91..7078d72baec2 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -197,12 +197,6 @@ static int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
return nents;
}

-static void dma_nommu_unmap_sg(struct device *dev, struct scatterlist *sg,
- int nents, enum dma_data_direction direction,
- unsigned long attrs)
-{
-}
-
static u64 dma_nommu_get_required_mask(struct device *dev)
{
u64 end, mask;
@@ -228,14 +222,6 @@ static inline dma_addr_t dma_nommu_map_page(struct device *dev,
return page_to_phys(page) + offset + get_dma_offset(dev);
}

-static inline void dma_nommu_unmap_page(struct device *dev,
- dma_addr_t dma_address,
- size_t size,
- enum dma_data_direction direction,
- unsigned long attrs)
-{
-}
-
#ifdef CONFIG_NOT_COHERENT_CACHE
static inline void dma_nommu_sync_sg(struct device *dev,
struct scatterlist *sgl, int nents,
@@ -261,10 +247,8 @@ const struct dma_map_ops dma_nommu_ops = {
.free = dma_nommu_free_coherent,
.mmap = dma_nommu_mmap_coherent,
.map_sg = dma_nommu_map_sg,
- .unmap_sg = dma_nommu_unmap_sg,
.dma_supported = dma_nommu_dma_supported,
.map_page = dma_nommu_map_page,
- .unmap_page = dma_nommu_unmap_page,
.get_required_mask = dma_nommu_get_required_mask,
#ifdef CONFIG_NOT_COHERENT_CACHE
.sync_single_for_cpu = dma_nommu_sync_single,
--
2.19.1


2018-11-14 08:27:59

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 26/34] powerpc/dma: fix an off-by-one in dma_capable

We need to compare the last byte in the dma range and not the one after it
for the bus_dma_mask, just like we do for the regular dma_mask. Fix this
cleanly by merging the two comparisms into one.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/dma-direct.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-direct.h b/arch/powerpc/include/asm/dma-direct.h
index e00ab5d0612d..92d8aed86422 100644
--- a/arch/powerpc/include/asm/dma-direct.h
+++ b/arch/powerpc/include/asm/dma-direct.h
@@ -4,15 +4,11 @@

static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
{
-#ifdef CONFIG_SWIOTLB
- if (dev->bus_dma_mask && addr + size > dev->bus_dma_mask)
- return false;
-#endif
-
if (!dev->dma_mask)
return false;

- return addr + size - 1 <= *dev->dma_mask;
+ return addr + size - 1 <=
+ min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
}

static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
--
2.19.1


2018-11-14 08:28:05

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 20/34] powerpc/dma: stop overriding dma_get_required_mask

The ppc_md and pci_controller_ops methods are unused now and can be
removed. The dma_nommu implementation is generic to the generic one
except for using max_pfn instead of calling into the memblock API,
and all other dma_map_ops instances implement a method of their own.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/include/asm/device.h | 2 --
arch/powerpc/include/asm/dma-mapping.h | 2 --
arch/powerpc/include/asm/machdep.h | 2 --
arch/powerpc/include/asm/pci-bridge.h | 1 -
arch/powerpc/kernel/dma.c | 30 --------------------------
drivers/base/platform.c | 2 --
6 files changed, 39 deletions(-)

diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
index 1aa53318b4bc..3814e1c2d4bc 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -59,6 +59,4 @@ struct pdev_archdata {
u64 dma_mask;
};

-#define ARCH_HAS_DMA_GET_REQUIRED_MASK
-
#endif /* _ASM_POWERPC_DEVICE_H */
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 140ce5ad3120..e5ee4ac97c14 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -113,7 +113,5 @@ static inline void set_dma_offset(struct device *dev, dma_addr_t off)
#define HAVE_ARCH_DMA_SET_MASK 1
extern int dma_set_mask(struct device *dev, u64 dma_mask);

-extern u64 __dma_get_required_mask(struct device *dev);
-
#endif /* __KERNEL__ */
#endif /* _ASM_DMA_MAPPING_H */
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 8311869005fa..7b70dcbce1b9 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -47,9 +47,7 @@ struct machdep_calls {
#endif
#endif /* CONFIG_PPC64 */

- /* Platform set_dma_mask and dma_get_required_mask overrides */
int (*dma_set_mask)(struct device *dev, u64 dma_mask);
- u64 (*dma_get_required_mask)(struct device *dev);

int (*probe)(void);
void (*setup_arch)(void); /* Optional, may be NULL */
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 5c7a1e7ffc8a..aace7033fa02 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -46,7 +46,6 @@ struct pci_controller_ops {
#endif

int (*dma_set_mask)(struct pci_dev *pdev, u64 dma_mask);
- u64 (*dma_get_required_mask)(struct pci_dev *pdev);

void (*shutdown)(struct pci_controller *hose);
};
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 6c368b6820bb..154e1cdae7f9 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -246,7 +246,6 @@ const struct dma_map_ops dma_nommu_ops = {
.map_sg = dma_nommu_map_sg,
.dma_supported = dma_nommu_dma_supported,
.map_page = dma_nommu_map_page,
- .get_required_mask = dma_nommu_get_required_mask,
#ifdef CONFIG_NOT_COHERENT_CACHE
.sync_single_for_cpu = dma_nommu_sync_single,
.sync_single_for_device = dma_nommu_sync_single,
@@ -294,35 +293,6 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
}
EXPORT_SYMBOL(dma_set_mask);

-u64 __dma_get_required_mask(struct device *dev)
-{
- const struct dma_map_ops *dma_ops = get_dma_ops(dev);
-
- if (unlikely(dma_ops == NULL))
- return 0;
-
- if (dma_ops->get_required_mask)
- return dma_ops->get_required_mask(dev);
-
- return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
-}
-
-u64 dma_get_required_mask(struct device *dev)
-{
- if (ppc_md.dma_get_required_mask)
- return ppc_md.dma_get_required_mask(dev);
-
- if (dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
- struct pci_controller *phb = pci_bus_to_host(pdev->bus);
- if (phb->controller_ops.dma_get_required_mask)
- return phb->controller_ops.dma_get_required_mask(pdev);
- }
-
- return __dma_get_required_mask(dev);
-}
-EXPORT_SYMBOL_GPL(dma_get_required_mask);
-
static int __init dma_init(void)
{
#ifdef CONFIG_IBMVIO
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 41b91af95afb..648b6213e322 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1179,7 +1179,6 @@ int __init platform_bus_init(void)
return error;
}

-#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
static u64 dma_default_get_required_mask(struct device *dev)
{
u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
@@ -1208,7 +1207,6 @@ u64 dma_get_required_mask(struct device *dev)
return dma_default_get_required_mask(dev);
}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
-#endif

static __initdata LIST_HEAD(early_platform_driver_list);
static __initdata LIST_HEAD(early_platform_device_list);
--
2.19.1


2018-11-14 08:28:21

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 01/34] powerpc: use mm zones more sensibly

Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on
common 64-bit configfs, and ZONE_DMA32 is used for 31-bit schemes.

Move to a scheme closer to what other architectures use (and I dare to
say the intent of the system):

- ZONE_DMA: optionally for memory < 31-bit (64-bit embedded only)
- ZONE_NORMAL: everything addressable by the kernel
- ZONE_HIGHMEM: memory > 32-bit for 32-bit kernels

Also provide information on how ZONE_DMA is used by defining
ARCH_ZONE_DMA_BITS.

Contains various fixes from Benjamin Herrenschmidt.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/Kconfig | 8 +---
arch/powerpc/include/asm/page.h | 2 +
arch/powerpc/include/asm/pgtable.h | 1 -
arch/powerpc/kernel/dma-swiotlb.c | 6 +--
arch/powerpc/kernel/dma.c | 7 +--
arch/powerpc/mm/mem.c | 47 +++++++------------
arch/powerpc/platforms/85xx/corenet_generic.c | 10 ----
arch/powerpc/platforms/85xx/qemu_e500.c | 9 ----
include/linux/mmzone.h | 2 +-
9 files changed, 25 insertions(+), 67 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8be31261aec8..cffff3613bc1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -374,9 +374,9 @@ config PPC_ADV_DEBUG_DAC_RANGE
depends on PPC_ADV_DEBUG_REGS && 44x
default y

-config ZONE_DMA32
+config ZONE_DMA
bool
- default y if PPC64
+ default y if PPC_BOOK3E_64

config PGTABLE_LEVELS
int
@@ -869,10 +869,6 @@ config ISA
have an IBM RS/6000 or pSeries machine, say Y. If you have an
embedded board, consult your board documentation.

-config ZONE_DMA
- bool
- default y
-
config GENERIC_ISA_DMA
bool
depends on ISA_DMA_API
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index f6a1265face2..fc8c9ac0c6be 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -354,4 +354,6 @@ typedef struct page *pgtable_t;
#endif /* __ASSEMBLY__ */
#include <asm/slice.h>

+#define ARCH_ZONE_DMA_BITS 31
+
#endif /* _ASM_POWERPC_PAGE_H */
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 9679b7519a35..8af32ce93c7f 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -66,7 +66,6 @@ extern unsigned long empty_zero_page[];

extern pgd_t swapper_pg_dir[];

-void limit_zone_pfn(enum zone_type zone, unsigned long max_pfn);
int dma_pfn_limit_to_zone(u64 pfn_limit);
extern void paging_init(void);

diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 5fc335f4d9cd..678811abccfc 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -108,12 +108,8 @@ int __init swiotlb_setup_bus_notifier(void)

void __init swiotlb_detect_4g(void)
{
- if ((memblock_end_of_DRAM() - 1) > 0xffffffff) {
+ if ((memblock_end_of_DRAM() - 1) > 0xffffffff)
ppc_swiotlb_enable = 1;
-#ifdef CONFIG_ZONE_DMA32
- limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
-#endif
- }
}

static int __init check_swiotlb_enabled(void)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index dbfc7056d7df..6551685a4ed0 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -50,7 +50,7 @@ static int dma_nommu_dma_supported(struct device *dev, u64 mask)
return 1;

#ifdef CONFIG_FSL_SOC
- /* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
+ /* Freescale gets another chance via ZONE_DMA, however
* that will have to be refined if/when they support iommus
*/
return 1;
@@ -94,13 +94,10 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
}

switch (zone) {
+#ifdef CONFIG_ZONE_DMA
case ZONE_DMA:
flag |= GFP_DMA;
break;
-#ifdef CONFIG_ZONE_DMA32
- case ZONE_DMA32:
- flag |= GFP_DMA32;
- break;
#endif
};
#endif /* CONFIG_FSL_SOC */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 0a64fffabee1..c0b676c3a5ba 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -246,35 +246,19 @@ static int __init mark_nonram_nosave(void)
}
#endif

-static bool zone_limits_final;
-
/*
- * The memory zones past TOP_ZONE are managed by generic mm code.
- * These should be set to zero since that's what every other
- * architecture does.
+ * Zones usage:
+ *
+ * We setup ZONE_DMA to be 31-bits on all platforms and ZONE_NORMAL to be
+ * everything else. GFP_DMA32 page allocations automatically fall back to
+ * ZONE_DMA.
+ *
+ * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
+ * inform the generic DMA mapping code. 32-bit only devices (if not handled
+ * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
+ * otherwise served by ZONE_DMA.
*/
-static unsigned long max_zone_pfns[MAX_NR_ZONES] = {
- [0 ... TOP_ZONE ] = ~0UL,
- [TOP_ZONE + 1 ... MAX_NR_ZONES - 1] = 0
-};
-
-/*
- * Restrict the specified zone and all more restrictive zones
- * to be below the specified pfn. May not be called after
- * paging_init().
- */
-void __init limit_zone_pfn(enum zone_type zone, unsigned long pfn_limit)
-{
- int i;
-
- if (WARN_ON(zone_limits_final))
- return;
-
- for (i = zone; i >= 0; i--) {
- if (max_zone_pfns[i] > pfn_limit)
- max_zone_pfns[i] = pfn_limit;
- }
-}
+static unsigned long max_zone_pfns[MAX_NR_ZONES];

/*
* Find the least restrictive zone that is entirely below the
@@ -324,11 +308,14 @@ void __init paging_init(void)
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
(long int)((top_of_ram - total_ram) >> 20));

+#ifdef CONFIG_ZONE_DMA
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
+#endif
+ max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
- limit_zone_pfn(ZONE_NORMAL, lowmem_end_addr >> PAGE_SHIFT);
+ max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
#endif
- limit_zone_pfn(TOP_ZONE, top_of_ram >> PAGE_SHIFT);
- zone_limits_final = true;
+
free_area_init_nodes(max_zone_pfns);

mark_nonram_nosave();
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index ac191a7a1337..b0dac307bebf 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -68,16 +68,6 @@ void __init corenet_gen_setup_arch(void)

swiotlb_detect_4g();

-#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
- /*
- * Inbound windows don't cover the full lower 4 GiB
- * due to conflicts with PCICSRBAR and outbound windows,
- * so limit the DMA32 zone to 2 GiB, to allow consistent
- * allocations to succeed.
- */
- limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
-#endif
-
pr_info("%s board\n", ppc_md.name);

mpc85xx_qe_init();
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
index b63a8548366f..27631c607f3d 100644
--- a/arch/powerpc/platforms/85xx/qemu_e500.c
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -45,15 +45,6 @@ static void __init qemu_e500_setup_arch(void)

fsl_pci_assign_primary();
swiotlb_detect_4g();
-#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
- /*
- * Inbound windows don't cover the full lower 4 GiB
- * due to conflicts with PCICSRBAR and outbound windows,
- * so limit the DMA32 zone to 2 GiB, to allow consistent
- * allocations to succeed.
- */
- limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
-#endif
mpc85xx_smp_init();
}

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 847705a6d0ec..e2d01ccd071d 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -314,7 +314,7 @@ enum zone_type {
* Architecture Limit
* ---------------------------
* parisc, ia64, sparc <4G
- * s390 <2G
+ * s390, powerpc <2G
* arm Various
* alpha Unlimited or 0-16MB.
*
--
2.19.1


2018-11-14 08:28:28

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 15/34] powerpc/dart: use the generic iommu bypass code

Use the generic iommu bypass code instead of overriding set_dma_mask.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/powerpc/sysdev/dart_iommu.c | 45 +++++++++++---------------------
1 file changed, 15 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 283ce04c5844..2681a19347ba 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -360,13 +360,6 @@ static void iommu_table_dart_setup(void)
set_bit(iommu_table_dart.it_size - 1, iommu_table_dart.it_map);
}

-static void pci_dma_dev_setup_dart(struct pci_dev *dev)
-{
- if (dart_is_u4)
- set_dma_offset(&dev->dev, DART_U4_BYPASS_BASE);
- set_iommu_table_base(&dev->dev, &iommu_table_dart);
-}
-
static void pci_dma_bus_setup_dart(struct pci_bus *bus)
{
if (!iommu_table_dart_inited) {
@@ -390,27 +383,16 @@ static bool dart_device_on_pcie(struct device *dev)
return false;
}

-static int dart_dma_set_mask(struct device *dev, u64 dma_mask)
+static void pci_dma_dev_setup_dart(struct pci_dev *dev)
{
- if (!dev->dma_mask || !dma_supported(dev, dma_mask))
- return -EIO;
-
- /* U4 supports a DART bypass, we use it for 64-bit capable
- * devices to improve performances. However, that only works
- * for devices connected to U4 own PCIe interface, not bridged
- * through hypertransport. We need the device to support at
- * least 40 bits of addresses.
- */
- if (dart_device_on_pcie(dev) && dma_mask >= DMA_BIT_MASK(40)) {
- dev_info(dev, "Using 64-bit DMA iommu bypass\n");
- set_dma_ops(dev, &dma_nommu_ops);
- } else {
- dev_info(dev, "Using 32-bit DMA via iommu\n");
- set_dma_ops(dev, &dma_iommu_ops);
- }
+ if (dart_is_u4 && dart_device_on_pcie(&dev->dev))
+ set_dma_offset(&dev->dev, DART_U4_BYPASS_BASE);
+ set_iommu_table_base(&dev->dev, &iommu_table_dart);
+}

- *dev->dma_mask = dma_mask;
- return 0;
+static bool iommu_bypass_supported_dart(struct pci_dev *dev, u64 mask)
+{
+ return dart_is_u4 && dart_device_on_pcie(&dev->dev);
}

void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)
@@ -430,12 +412,15 @@ void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)
if (dart_init(dn) != 0)
return;

- /* Setup bypass if supported */
- if (dart_is_u4)
- ppc_md.dma_set_mask = dart_dma_set_mask;
-
+ /*
+ * U4 supports a DART bypass, we use it for 64-bit capable devices to
+ * improve performance. However, that only works for devices connected
+ * to the U4 own PCIe interface, not bridged through hypertransport.
+ * We need the device to support at least 40 bits of addresses.
+ */
controller_ops->dma_dev_setup = pci_dma_dev_setup_dart;
controller_ops->dma_bus_setup = pci_dma_bus_setup_dart;
+ controller_ops->iommu_bypass_supported = iommu_bypass_supported_dart;

/* Setup pci_dma ops */
set_pci_dma_ops(&dma_iommu_ops);
--
2.19.1


2018-11-14 08:29:30

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 03/34] powerpc/dma: remove the unused ARCH_HAS_DMA_MMAP_COHERENT define

Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
---
arch/powerpc/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 8fa394520af6..f2a4a7142b1e 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -112,7 +112,5 @@ extern int dma_set_mask(struct device *dev, u64 dma_mask);

extern u64 __dma_get_required_mask(struct device *dev);

-#define ARCH_HAS_DMA_MMAP_COHERENT
-
#endif /* __KERNEL__ */
#endif /* _ASM_DMA_MAPPING_H */
--
2.19.1


2018-11-27 07:43:50

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Any comments? I'd like to at least get the ball moving on the easy
bits.

On Wed, Nov 14, 2018 at 09:22:40AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series switches the powerpc port to use the generic swiotlb and
> noncoherent dma ops, and to use more generic code for the coherent
> direct mapping, as well as removing a lot of dead code.
>
> As this series is very large and depends on the dma-mapping tree I've
> also published a git tree:
>
> git://git.infradead.org/users/hch/misc.git powerpc-dma.4
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>
> Changes since v3:
> - rebase on the powerpc fixes tree
> - add a new patch to actually make the baseline amigaone config
> configure without warnings
> - only use ZONE_DMA for 64-bit embedded CPUs, on pseries an IOMMU is
> always present
> - fix compile in mem.c for one configuration
> - drop the full npu removal for now, will be resent separately
> - a few git bisection fixes
>
> The changes since v1 are to big to list and v2 was not posted in public.
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-11-28 11:07:13

by Michael Ellerman

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Christoph Hellwig <[email protected]> writes:

> Any comments? I'd like to at least get the ball moving on the easy
> bits.

Nothing specific yet.

I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.

There's not much we can do about that, but I'll just try and test it on
everything I can find.

Is the plan that you take these via the dma-mapping tree or that they go
via powerpc?

cheers

> On Wed, Nov 14, 2018 at 09:22:40AM +0100, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series switches the powerpc port to use the generic swiotlb and
>> noncoherent dma ops, and to use more generic code for the coherent
>> direct mapping, as well as removing a lot of dead code.
>>
>> As this series is very large and depends on the dma-mapping tree I've
>> also published a git tree:
>>
>> git://git.infradead.org/users/hch/misc.git powerpc-dma.4
>>
>> Gitweb:
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>>
>> Changes since v3:
>> - rebase on the powerpc fixes tree
>> - add a new patch to actually make the baseline amigaone config
>> configure without warnings
>> - only use ZONE_DMA for 64-bit embedded CPUs, on pseries an IOMMU is
>> always present
>> - fix compile in mem.c for one configuration
>> - drop the full npu removal for now, will be resent separately
>> - a few git bisection fixes
>>
>> The changes since v1 are to big to list and v2 was not posted in public.
>>
>> _______________________________________________
>> iommu mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
> ---end quoted text---

2018-11-28 16:10:55

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
> Nothing specific yet.
>
> I'm a bit worried it might break one of the many old obscure platforms
> we have that aren't well tested.
>
Please don't apply the new DMA mapping code if you don't be sure if it
works on all supported PowerPC machines. Is the new DMA mapping code
really necessary? It's not really nice, to rewrote code if the old code
works perfect. We must not forget, that we work for the end users. Does
the end user have advantages with this new code? Is it faster? The old
code works without any problems. I am also worried about this code. How
can I test this new DMA mapping code?

Thanks


2018-11-28 20:05:52

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

I will compile and test the kernel from the following Git on my PowerPC machines.

http://git.infradead.org/users/hch/misc.git

On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Nothing specific yet.

I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.


2018-11-28 20:36:21

by Michal Suchánek

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Wed, 28 Nov 2018 16:55:30 +0100
Christian Zigotzky <[email protected]> wrote:

> On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
> > Nothing specific yet.
> >
> > I'm a bit worried it might break one of the many old obscure platforms
> > we have that aren't well tested.
> >
> Please don't apply the new DMA mapping code if you don't be sure if it
> works on all supported PowerPC machines. Is the new DMA mapping code
> really necessary? It's not really nice, to rewrote code if the old code
> works perfect. We must not forget, that we work for the end users. Does
> the end user have advantages with this new code? Is it faster? The old
> code works without any problems.

There is another service provided to the users as well: new code that is
cleaner and simpler which allows easier bug fixes and new features.
Without being familiar with the DMA mapping code I cannot really say if
that's the case here.

> I am also worried about this code. How
> can I test this new DMA mapping code?

I suppose if your machine works it works for you.

Thanks

Michal

2018-11-29 12:07:53

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
> Christoph Hellwig <[email protected]> writes:
>
>> Any comments? I'd like to at least get the ball moving on the easy
>> bits.
> Nothing specific yet.
>
> I'm a bit worried it might break one of the many old obscure platforms
> we have that aren't well tested.
>
> There's not much we can do about that, but I'll just try and test it on
> everything I can find.
>
> Is the plan that you take these via the dma-mapping tree or that they go
> via powerpc?
>
> cheers
>
Hi All,

I compiled a test kernel from the following Git today.

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4

Command: git clone git://git.infradead.org/users/hch/misc.git -b
powerpc-dma.4 a

Unfortunately I get some DMA error messages and the PASEMI ethernet
doesn't work anymore.

[  367.627623] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627631] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627639] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627647] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627655] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627686] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.628418] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.628505] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.628592] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.629324] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.629417] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.629495] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.629589] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0

[  430.424732]pasemi_mac: rcmdsta error: 0x04ef3001

I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M).
The PASEMI ethernet works with the RC4 of kernel 4.20.

Cheers,
Christian

2018-11-29 15:33:31

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 29 November 2018 at 1:05PM, Christian Zigotzky wrote:
> On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
>> Christoph Hellwig <[email protected]> writes:
>>
>>> Any comments?  I'd like to at least get the ball moving on the easy
>>> bits.
>> Nothing specific yet.
>>
>> I'm a bit worried it might break one of the many old obscure platforms
>> we have that aren't well tested.
>>
>> There's not much we can do about that, but I'll just try and test it on
>> everything I can find.
>>
>> Is the plan that you take these via the dma-mapping tree or that they go
>> via powerpc?
>>
>> cheers
>>
> Hi All,
>
> I compiled a test kernel from the following Git today.
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>
>
> Command: git clone git://git.infradead.org/users/hch/misc.git -b
> powerpc-dma.4 a
>
> Unfortunately I get some DMA error messages and the PASEMI ethernet
> doesn't work anymore.
>
> [  367.627623] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.627631] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.627639] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.627647] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.627655] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.627686] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.628418] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.628505] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.628592] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.629324] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.629417] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.629495] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
> [  367.629589] pci 0000:00:1a.0: dma_direct_map_page: overflow
> 0x000000026bcb5002+110 of device mask ffffffff bus mask 0
>
> [  430.424732]pasemi_mac: rcmdsta error: 0x04ef3001
>
> I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M).
> The PASEMI ethernet works with the RC4 of kernel 4.20.
>
> Cheers,
> Christian
>
Hi All,

I tested this kernel on my NXP QorIQ P5020 board. U-Boot loads the dtb
file and the kernel and after that the booting stops. This board works
with the RC4 of kernel 4.20. Please test this kernel on your NXP and
PASEMI boards.

Thanks,
Christian


2018-11-29 17:06:39

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Nov 29, 2018 at 01:05:23PM +0100, Christian Zigotzky wrote:
> I compiled a test kernel from the following Git today.
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>
> Command: git clone git://git.infradead.org/users/hch/misc.git -b
> powerpc-dma.4 a
>
> Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't
> work anymore.

What kind of machine is this (and your other one)? Can you send me
(or point me to) the .config files?

2018-11-29 18:38:51

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

> > Please don't apply the new DMA mapping code if you don't be sure if it
> > works on all supported PowerPC machines. Is the new DMA mapping code
> > really necessary? It's not really nice, to rewrote code if the old code
> > works perfect. We must not forget, that we work for the end users. Does
> > the end user have advantages with this new code? Is it faster? The old
> > code works without any problems.
>
> There is another service provided to the users as well: new code that is
> cleaner and simpler which allows easier bug fixes and new features.
> Without being familiar with the DMA mapping code I cannot really say if
> that's the case here.

Yes, the main point is to move all architecturs to common code for the
dma direct mapping code. This means we have one code bases that sees
bugs fixed and features introduced the same way for everyone.

2018-11-29 19:12:37

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Wed, Nov 28, 2018 at 10:05:19PM +1100, Michael Ellerman wrote:
> Is the plan that you take these via the dma-mapping tree or that they go
> via powerpc?

In principle either way is fine with me. If it goes through the powerpc
tree we might run into a few minor conflicts with the dma-mapping tree
depending on how some of the current discussions go.

2018-11-29 19:47:20

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Christoph Hellwig <[email protected]> writes:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.

Hi, Christoph,

I'm sorry, but this series makes nouveau my Power Mac G5 very unhappy.
Dmesg and .config attached.
Let me know if you need anything else to help you debug this, I'm
happy to help with testing.

Thanks,
Rui


Attachments:
dmesg (60.79 kB)
.config (67.40 kB)
Download all attachments

2018-11-29 23:12:19

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 29 November 2018 at 6:03PM, Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 01:05:23PM +0100, Christian Zigotzky wrote:
>> I compiled a test kernel from the following Git today.
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>>
>> Command: git clone git://git.infradead.org/users/hch/misc.git -b
>> powerpc-dma.4 a
>>
>> Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't
>> work anymore.
> What kind of machine is this (and your other one)? Can you send me
> (or point me to) the .config files?
>
Hello Christoph,

Thanks for your reply and sorry for my bad email at the beginning. I
have bad experiences with rewroting of good working code. Actually I
work for the first level Linux support at A-EON Technology Ltd. Our
customers are typically desktop users. That means, we don't have always
time to hunt kernel bugs. Our customers are only interested in new
features, stability etc. It is really difficult to explain them about
rewroting of good working code as a new feature. For us as a first level
support it is very difficult and time intensive to look why the new code
doesn't work.

@All
Please also think of us because we have to explain your work to the end
customer. And it is really hard for us and time intensive to prove
mistakes because of rewroting code over and over again in opposite to you.
It is really a pity if you replace a good working code (The work from
another developer with a lot of bug fixes) with a buggy code.
Incidentally, it is also expensive. (time + money)

@Christoph
Anyway, back to testing. I tested your kernel on an A-EON AmigaOne X1000
and on an A-EON AmigaOne X5000 today.

More information:

A-EON AmigaOne X1000 (Nemo kernel config attached):

- https://en.wikipedia.org/wiki/AmigaOne_X1000
- http://www.amigaos.net/hardware/35/amigaone-x1000

A-EON AmigaOne X5000 (Cyrus kernel config attached):

- http://www.amigaos.net/hardware/133/amigaone-x5000
- http://wiki.amiga.org/index.php/AmigaONE_X5000

Please find attached the kernel configs.

Thanks,
Christian


Attachments:
cyrus-4.20-rc4.config (132.62 kB)
nemo-4.20-rc4.config (113.24 kB)
Download all attachments

2018-11-30 10:33:15

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Rui,

can you check if the patch below fixes the issue for you?

diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
index 2e24fc87ed84..809797dbe169 100644
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -392,7 +392,9 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)

static bool iommu_bypass_supported_dart(struct pci_dev *dev, u64 mask)
{
- return dart_is_u4 && dart_device_on_pcie(&dev->dev);
+ return dart_is_u4 &&
+ dart_device_on_pcie(&dev->dev) &&
+ mask >= DMA_BIT_MASK(40);
}

void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)

2018-11-30 10:54:37

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christian,

for such a diverse architecture like powerpc we'll have to rely on
users / non core developers like you to help with testing.

Can you try the patch below for he cyrus config?

For the nemo one I have no idea yet, there is no chance I could trick
you into a git bisect to see which patch caused the problem, is there?


diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 7b70dcbce1b9..2f0ca6560e47 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -47,7 +47,7 @@ struct machdep_calls {
#endif
#endif /* CONFIG_PPC64 */

- int (*dma_set_mask)(struct device *dev, u64 dma_mask);
+ void (*dma_set_mask)(struct device *dev, u64 dma_mask);

int (*probe)(void);
void (*setup_arch)(void); /* Optional, may be NULL */
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index bded4127791a..2587eb0f3fde 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -22,11 +22,10 @@
#include <asm/swiotlb.h>
#include <asm/dma.h>

-bool arch_dma_set_mask(struct device *dev, u64 dma_mask)
+void arch_dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!ppc_md.dma_set_mask)
- return 0;
- return ppc_md.dma_set_mask(dev, dma_mask);
+ if (ppc_md.dma_set_mask)
+ ppc_md.dma_set_mask(dev, dma_mask);
}
EXPORT_SYMBOL(arch_dma_set_mask);

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 9584765dbe3b..8582a418516b 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -134,7 +134,7 @@ static void setup_swiotlb_ops(struct pci_controller *hose)
static inline void setup_swiotlb_ops(struct pci_controller *hose) {}
#endif

-static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
+static void fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
/*
* Fix up PCI devices that are able to DMA to the large inbound
@@ -144,8 +144,6 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
dev->bus_dma_mask = 0;
dev->archdata.dma_offset = pci64_dma_offset;
}
-
- return 0;
}

static int setup_one_atmu(struct ccsr_pci __iomem *pci,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 8dd19e66c0e5..94a4db5f7ec3 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -599,17 +599,16 @@ static inline int dma_supported(struct device *dev, u64 mask)
}

#ifdef CONFIG_ARCH_HAS_DMA_SET_MASK
-bool arch_dma_set_mask(struct device *dev, u64 mask);
+void arch_dma_set_mask(struct device *dev, u64 mask);
#else
-#define arch_dma_set_mask(dev, mask) true
+#define arch_dma_set_mask(dev, mask) do { } while (0)
#endif

static inline int dma_set_mask(struct device *dev, u64 mask)
{
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
- if (!arch_dma_set_mask(dev, mask))
- return -EIO;
+ arch_dma_set_mask(dev, mask);
dma_check_mask(dev, mask);

*dev->dma_mask = mask;


2018-11-30 11:46:56

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, 30 Nov 2018 at 10:32, Christoph Hellwig <[email protected]> wrote:
>
> Hi Rui,
>
> can you check if the patch below fixes the issue for you?
>
> diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
> index 2e24fc87ed84..809797dbe169 100644
> --- a/arch/powerpc/sysdev/dart_iommu.c
> +++ b/arch/powerpc/sysdev/dart_iommu.c
> @@ -392,7 +392,9 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)
>
> static bool iommu_bypass_supported_dart(struct pci_dev *dev, u64 mask)
> {
> - return dart_is_u4 && dart_device_on_pcie(&dev->dev);
> + return dart_is_u4 &&
> + dart_device_on_pcie(&dev->dev) &&
> + mask >= DMA_BIT_MASK(40);
> }
>
> void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)

Hi, Christoph,

Thanks for the quick response! I applied it on top of your
powerpc-dma.4 branch and retested.
I'm not seeing nouveau complaining anymore (I'm not using X11 or any
DE, though).
In any case and FWIW, this series is

Tested-by: Rui Salvaterra <[email protected]>

Thanks,
Rui

2018-11-30 12:25:00

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Thanks a lot for your fast reply.

On 30 November 2018 at 11:53AM, Christoph Hellwig wrote:
> Hi Christian,
>
> for such a diverse architecture like powerpc we'll have to rely on
> users / non core developers like you to help with testing.
I see. I will help as good as I can.
>
> Can you try the patch below for he cyrus config?
Yes, of course. I patched your Git kernel and after that I compiled it
again. U-Boot loads the kernel and the dtb file. Then the kernel starts
but it doesn't find any hard disks (partitions).

@All
Could you please also test Christoph's kernel on your PASEMI and NXP
boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git
-b powerpc-dma.4 a'
*PLEASE*
>
> For the nemo one I have no idea yet,
We had some problems with the PASEMI ethernet and DMA two years ago. I
had to deactivate the option PASEMI_IOMMU_DMA_FORCE.

commit 416f37d0816b powerpc/pasemi: Fix coherent_dma_mask for dma engine:

Commit 817820b0 ("powerpc/iommu: Support "hybrid" iommu/direct DMA
ops for coherent_mask < dma_mask) adds a check of coherent_dma_mask for
dma allocations.

Unfortunately current PASemi code does not set this value for the DMA
engine, which ends up with the default value of 0xffffffff, the result
is on a PASemi system with >2Gb ram and iommu enabled the onboard
ethernet stops working due to an inability to allocate memory. Add an
initialisation to pci_dma_dev_setup_pasemi().
Signed-off-by: Darren Stevens <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>

Links:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/146701.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=416f37d0816b9720b8227953e55954d81456f991

FYI: DMA handling has been rewritten in 2015. We had some problems with
the new DMA code in 2015. I had to revert the commit ' [RFC/PATCH,v2]
powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask <
dma_mask' in 2015.

Link: https://patchwork.ozlabs.org/patch/472535/

I had to create a patch in 2015:

    diff -rupN linux-4.4/arch/powerpc/Kconfig
linux-4.4-nemo/arch/powerpc/Kconfig
    --- linux-4.4/arch/powerpc/Kconfig    2015-12-07 00:43:12.000000000
+0100
    +++ linux-4.4-nemo/arch/powerpc/Kconfig    2015-12-07
14:48:23.371987988 +0100
    @@ -158,8 +155,6 @@ config PPC
         select HAVE_PERF_EVENTS_NMI if PPC64
         select EDAC_SUPPORT
         select EDAC_ATOMIC_SCRUB
    -    select ARCH_HAS_DMA_SET_COHERENT_MASK
    -    select HAVE_ARCH_SECCOMP_FILTER

     config GENERIC_CSUM
         def_bool CPU_LITTLE_ENDIAN
    @@ -419,8 +414,7 @@ config PPC64_SUPPORTS_MEMORY_FAILURE

     config KEXEC
         bool "kexec system call"
    -    depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) ||
PPC_BOOK3E
    -    select KEXEC_CORE
    +    depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))
         help
           kexec is a system call that implements the ability to
shutdown your
           current kernel, and to start another kernel.  It is like a
reboot

    diff -rupN linux-4.4/arch/powerpc/kernel/dma.c
linux-4.4-nemo/arch/powerpc/kernel/dma.c
    --- linux-4.4/arch/powerpc/kernel/dma.c    2015-12-07
00:43:12.000000000 +0100
    +++ linux-4.4-nemo/arch/powerpc/kernel/dma.c    2015-12-07
14:49:38.098286892 +0100
    @@ -40,31 +39,9 @@ static u64 __maybe_unused get_pfn_limit(
         return pfn;
     }

    -static int dma_direct_dma_supported(struct device *dev, u64 mask)
    -{
    -#ifdef CONFIG_PPC64
    -    u64 limit = get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
    -
    -    /* Limit fits in the mask, we are good */
    -    if (mask >= limit)
    -        return 1;
    -
    -#ifdef CONFIG_FSL_SOC
    -    /* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
    -     * that will have to be refined if/when they support iommus
    -     */
    -    return 1;
    -#endif
    -    /* Sorry ... */
    -    return 0;
    -#else
    -    return 1;
    -#endif
    -}
    -
    -void *__dma_direct_alloc_coherent(struct device *dev, size_t size,
    -                  dma_addr_t *dma_handle, gfp_t flag,
    -                  struct dma_attrs *attrs)
    +void *dma_direct_alloc_coherent(struct device *dev, size_t size,
    +                dma_addr_t *dma_handle, gfp_t flag,
    +                struct dma_attrs *attrs)
     {
         void *ret;
     #ifdef CONFIG_NOT_COHERENT_CACHE
    @@ -119,9 +96,9 @@ void *__dma_direct_alloc_coherent(struct
     #endif
     }

    -void __dma_direct_free_coherent(struct device *dev, size_t size,
    -                void *vaddr, dma_addr_t dma_handle,
    -                struct dma_attrs *attrs)
    +void dma_direct_free_coherent(struct device *dev, size_t size,
    +                  void *vaddr, dma_addr_t dma_handle,
    +                  struct dma_attrs *attrs)
     {
     #ifdef CONFIG_NOT_COHERENT_CACHE
         __dma_free_coherent(size, vaddr);
    @@ -130,51 +107,6 @@ void __dma_direct_free_coherent(struct d
     #endif
     }

    -static void *dma_direct_alloc_coherent(struct device *dev, size_t
size,
    -                       dma_addr_t *dma_handle, gfp_t flag,
    -                       struct dma_attrs *attrs)
    -{
    -    struct iommu_table *iommu;
    -
    -    /* The coherent mask may be smaller than the real mask, check if
    -     * we can really use the direct ops
    -     */
    -    if (dma_direct_dma_supported(dev, dev->coherent_dma_mask))
    -        return __dma_direct_alloc_coherent(dev, size, dma_handle,
    -                           flag, attrs);
    -
    -    /* Ok we can't ... do we have an iommu ? If not, fail */
    -    iommu = get_iommu_table_base(dev);
    -    if (!iommu)
    -        return NULL;
    -
    -    /* Try to use the iommu */
    -    return iommu_alloc_coherent(dev, iommu, size, dma_handle,
    -                    dev->coherent_dma_mask, flag,
    -                    dev_to_node(dev));
    -}
    -
    -static void dma_direct_free_coherent(struct device *dev, size_t size,
    -                     void *vaddr, dma_addr_t dma_handle,
    -                     struct dma_attrs *attrs)
    -{
    -    struct iommu_table *iommu;
    -
    -    /* See comments in dma_direct_alloc_coherent() */
    -    if (dma_direct_dma_supported(dev, dev->coherent_dma_mask))
    -        return __dma_direct_free_coherent(dev, size, vaddr,
dma_handle,
    -                          attrs);
    -    /* Maybe we used an iommu ... */
    -    iommu = get_iommu_table_base(dev);
    -
    -    /* If we hit that we should have never allocated in the first
    -     * place so how come we are freeing ?
    -     */
    -    if (WARN_ON(!iommu))
    -        return;
    -    iommu_free_coherent(iommu, size, vaddr, dma_handle);
    -}
    -
     int dma_direct_mmap_coherent(struct device *dev, struct
vm_area_struct *vma,
                      void *cpu_addr, dma_addr_t handle, size_t size,
                      struct dma_attrs *attrs)
    @@ -215,6 +147,18 @@ static void dma_direct_unmap_sg(struct d
     {
     }

    +static int dma_direct_dma_supported(struct device *dev, u64 mask)
    +{
    +#ifdef CONFIG_PPC64
    +    /* Could be improved so platforms can set the limit in case
    +     * they have limited DMA windows
    +     */
    +    return mask >= get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
    +#else
    +    return 1;
    +#endif
    +}
    +
     static u64 dma_direct_get_required_mask(struct device *dev)
     {
         u64 end, mask;
    @@ -286,25 +230,6 @@ struct dma_map_ops dma_direct_ops = {
     };
     EXPORT_SYMBOL(dma_direct_ops);

    -int dma_set_coherent_mask(struct device *dev, u64 mask)
    -{
    -    if (!dma_supported(dev, mask)) {
    -        /*
    -         * We need to special case the direct DMA ops which can
    -         * support a fallback for coherent allocations. There
    -         * is no dma_op->set_coherent_mask() so we have to do
    -         * things the hard way:
    -         */
    -        if (get_dma_ops(dev) != &dma_direct_ops ||
    -            get_iommu_table_base(dev) == NULL ||
    -            !dma_iommu_dma_supported(dev, mask))
    -            return -EIO;
    -    }
    -    dev->coherent_dma_mask = mask;
    -    return 0;
    -}
    -EXPORT_SYMBOL(dma_set_coherent_mask);
    -
     #define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)

     int __dma_set_mask(struct device *dev, u64 dma_mask)

Interesting PASEMI ethernet files:

arch/powerpc/platforms/pasemi/iommu.c
drivers/net/ethernet/pasemi/pasemi_mac.c
drivers/net/ethernet/pasemi/pasemi_mac.h
drivers/net/ethernet/pasemi/pasemi_mac_ethtool.c
drivers/net/ethernet/pasemi/Makefile
drivers/net/ethernet/pasemi/Kconfig

I know this is a lot of information but I hope it helps.

Thanks,
Christian

2018-11-30 13:12:13

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Nov 30, 2018 at 01:23:20PM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> Thanks a lot for your fast reply.
>
> On 30 November 2018 at 11:53AM, Christoph Hellwig wrote:
>> Hi Christian,
>>
>> for such a diverse architecture like powerpc we'll have to rely on
>> users / non core developers like you to help with testing.
> I see. I will help as good as I can.
>>
>> Can you try the patch below for he cyrus config?
> Yes, of course. I patched your Git kernel and after that I compiled it
> again. U-Boot loads the kernel and the dtb file. Then the kernel starts but
> it doesn't find any hard disks (partitions).

Interesting. Does it find the storage controller (what kind of
storage does it use?).

For the PASEMI board can you test the attached patch? Also are you
using Compact Flash cards on that system?

> @All
> Could you please also test Christoph's kernel on your PASEMI and NXP
> boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git -b
> powerpc-dma.4 a'

FYI, I've pushed a new powerpc-dma.5 with the various fixes discussed
in this thread.


2018-11-30 15:32:36

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hello Christoph,

Thanks for your reply.

On 30 November 2018 at 2:10PM, Christoph Hellwig wrote:
> On Fri, Nov 30, 2018 at 01:23:20PM +0100, Christian Zigotzky wrote:
>> Yes, of course. I patched your Git kernel and after that I compiled it
>> again. U-Boot loads the kernel and the dtb file. Then the kernel starts but
>> it doesn't find any hard disks (partitions).
> Interesting. Does it find the storage controller (what kind of
> storage does it use?).
It seems not. I don't see any infos about hard disks in the kernel ring
buffer. The two serial ATA (SATA 2.0) controllers are integrated in the
P5020 SoC and the hard disks are connected via SerDes lanes (PCIe) to
the SoC. LANE 16 = SATA 0 and LANE 17 = SATA 1.
> For the PASEMI board can you test the attached patch? Also are you
> using Compact Flash cards on that system?
Yes, we are using Compact Flash cards. The slot is wired to the CPU
local bus. It works with your kernel. :-)

Where is the attached patch?

I downloaded the version 5 of your Git kernel and compiled it today.
Unfortunately the PASEMI ethernet doesn't work.

Error message: pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0

@All
Could you please also test Christoph's kernel on your PASEMI and NXP boards? Download:

'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian


2018-11-30 16:43:30

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi, Christoph,

Your powerpc-dma.5 branch seems to be working fine on my G5, so

Tested-by: Rui Salvaterra <[email protected]>

Thanks again!
Rui

2018-12-02 06:14:00

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, 2018-11-30 at 11:44 +0000, Rui Salvaterra wrote:
> Thanks for the quick response! I applied it on top of your
> powerpc-dma.4 branch and retested.
> I'm not seeing nouveau complaining anymore (I'm not using X11 or any
> DE, though).
> In any case and FWIW, this series is
>
> Tested-by: Rui Salvaterra <[email protected]>

Talking of which ... Christoph, not sure if we can do something about
this at the DMA API level or keep hacks but some adapters such as the
nVidia GPUs have a HW hack we can use to work around their limitations
in that case.

They have a register that can program a fixed value for the top bits
that they don't support.

This works fine for any linear mapping with an offset, provided they
can program the offset in that register and they have enough DMA range
to cover all memory from that offset.

I can probably get the info about this from them so we can exploit it
in nouveau.

Cheers,
Ben.

> Thanks,
> Rui


2018-12-04 07:32:01

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi All,

Could you please test Christoph's kernel on your PASEMI and NXP boards?
Download:

'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian

2018-12-04 09:56:00

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 04 December 2018 at 08:31AM, Christian Zigotzky wrote:
> Hi All,
>
> Could you please test Christoph's kernel on your PASEMI and NXP
> boards? Download:
>
> 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
>
> Thanks,
> Christian
>
I successfully tested this kernel on a virtual e5500 QEMU machine today.

Command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel
uImage-dma -drive
format=raw,file=MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -nic
user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device
virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp 4

QEMU version 3.1.0.

I don't know why this kernel doesn't recognize the hard disks connected
to my physical P5020 board and why the onboard ethernet on my PASEMI
board doesn't work. (dma_direct_map_page: overflow)

-- Christian


2018-12-04 14:26:07

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:
> I don't know why this kernel doesn't recognize the hard disks connected to
> my physical P5020 board and why the onboard ethernet on my PASEMI board
> doesn't work. (dma_direct_map_page: overflow)

Do you know if this actually works for the baseline before my patches?
E.g. with commit 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 ?

2018-12-05 10:05:34

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 04 December 2018 at 3:24PM, Christoph Hellwig wrote:
> On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:
>> I don't know why this kernel doesn't recognize the hard disks connected to
>> my physical P5020 board and why the onboard ethernet on my PASEMI board
>> doesn't work. (dma_direct_map_page: overflow)
> Do you know if this actually works for the baseline before my patches?
> E.g. with commit 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 ?
>
Hi Christoph,

Thanks for your reply. I undid all dma mapping commits with the
following command:

git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97

After that I compiled the kernels with this code for my P5020 board
(Cyrus) and for my PASEMI board (Nemo) today.

Result: PASEMI onboard ethernet works again and the P5020 board boots.

It seems the dma mapping commits are the problem.

@All
Could you please test Christoph's kernel on your PASEMI and NXP boards?
Download:

'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian


2018-12-05 14:07:46

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Wed, Dec 05, 2018 at 10:44:05AM +0100, Christian Zigotzky wrote:
> Thanks for your reply. I undid all dma mapping commits with the following
> command:
>
> git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97
>
> After that I compiled the kernels with this code for my P5020 board (Cyrus)
> and for my PASEMI board (Nemo) today.
>
> Result: PASEMI onboard ethernet works again and the P5020 board boots.
>
> It seems the dma mapping commits are the problem.

Thanks. Can you try a few stepping points in the tree?

First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
(the first one) applied?

Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b

And if that still works with commits up to
c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a

2018-12-06 10:57:40

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
>
> Thanks. Can you try a few stepping points in the tree?
>
> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
> (the first one) applied?
>
> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b
>
> And if that still works with commits up to
> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a
>
Hi Christoph,

I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the
following command:

git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6

Result: PASEMI onboard ethernet works again and the P5020 board boots.

I will test the other commits in the next days.

@All
It is really important, that you also test Christoph's work on your
PASEMI and NXP boards. Could you please help us with solving the issues?

'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'

Thanks,
Christian


2018-12-06 14:11:52

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 05/34] powerpc/dma: remove the unused dma_iommu_ops export

ping?

On Wed, Nov 14, 2018 at 09:22:45AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/kernel/dma-iommu.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index f9fe2080ceb9..2ca6cfaebf65 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -6,7 +6,6 @@
> * busses using the iommu infrastructure
> */
>
> -#include <linux/export.h>
> #include <asm/iommu.h>
>
> /*
> @@ -123,4 +122,3 @@ struct dma_map_ops dma_iommu_ops = {
> .get_required_mask = dma_iommu_get_required_mask,
> .mapping_error = dma_iommu_mapping_error,
> };
> -EXPORT_SYMBOL(dma_iommu_ops);
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:11:58

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 02/34] powerpc: allow NOT_COHERENT_CACHE for amigaone

powerpc maintainers, can you pick this up as this is a bug fix for the
currently existing powerpc Kconfig code?

On Wed, Nov 14, 2018 at 09:22:42AM +0100, Christoph Hellwig wrote:
> AMIGAONE select NOT_COHERENT_CACHE, so we better allow it.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/platforms/Kconfig.cputype | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index f4e2c5729374..6fedbf349fce 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -412,7 +412,8 @@ config NR_CPUS
>
> config NOT_COHERENT_CACHE
> bool
> - depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
> + depends on 4xx || PPC_8xx || E200 || PPC_MPC512x || \
> + GAMECUBE_COMMON || AMIGAONE
> default n if PPC_47x
> default y
>
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:03

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 06/34] powerpc/dma: split the two __dma_alloc_coherent implementations

ping?

On Wed, Nov 14, 2018 at 09:22:46AM +0100, Christoph Hellwig wrote:
> The implemementation for the CONFIG_NOT_COHERENT_CACHE case doesn't share
> any code with the one for systems with coherent caches. Split it off
> and merge it with the helpers in dma-noncoherent.c that have no other
> callers.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> Acked-by: Benjamin Herrenschmidt <[email protected]>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 5 -----
> arch/powerpc/kernel/dma.c | 14 ++------------
> arch/powerpc/mm/dma-noncoherent.c | 15 +++++++--------
> arch/powerpc/platforms/44x/warp.c | 2 +-
> 4 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index f2a4a7142b1e..dacd0f93f2b2 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -39,9 +39,6 @@ extern int dma_nommu_mmap_coherent(struct device *dev,
> * to ensure it is consistent.
> */
> struct device;
> -extern void *__dma_alloc_coherent(struct device *dev, size_t size,
> - dma_addr_t *handle, gfp_t gfp);
> -extern void __dma_free_coherent(size_t size, void *vaddr);
> extern void __dma_sync(void *vaddr, size_t size, int direction);
> extern void __dma_sync_page(struct page *page, unsigned long offset,
> size_t size, int direction);
> @@ -52,8 +49,6 @@ extern unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr);
> * Cache coherent cores.
> */
>
> -#define __dma_alloc_coherent(dev, gfp, size, handle) NULL
> -#define __dma_free_coherent(size, addr) ((void)0)
> #define __dma_sync(addr, size, rw) ((void)0)
> #define __dma_sync_page(pg, off, sz, rw) ((void)0)
>
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index 6551685a4ed0..d6deb458bb91 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -62,18 +62,12 @@ static int dma_nommu_dma_supported(struct device *dev, u64 mask)
> #endif
> }
>
> +#ifndef CONFIG_NOT_COHERENT_CACHE
> void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag,
> unsigned long attrs)
> {
> void *ret;
> -#ifdef CONFIG_NOT_COHERENT_CACHE
> - ret = __dma_alloc_coherent(dev, size, dma_handle, flag);
> - if (ret == NULL)
> - return NULL;
> - *dma_handle += get_dma_offset(dev);
> - return ret;
> -#else
> struct page *page;
> int node = dev_to_node(dev);
> #ifdef CONFIG_FSL_SOC
> @@ -110,19 +104,15 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
> *dma_handle = __pa(ret) + get_dma_offset(dev);
>
> return ret;
> -#endif
> }
>
> void __dma_nommu_free_coherent(struct device *dev, size_t size,
> void *vaddr, dma_addr_t dma_handle,
> unsigned long attrs)
> {
> -#ifdef CONFIG_NOT_COHERENT_CACHE
> - __dma_free_coherent(size, vaddr);
> -#else
> free_pages((unsigned long)vaddr, get_order(size));
> -#endif
> }
> +#endif /* !CONFIG_NOT_COHERENT_CACHE */
>
> static void *dma_nommu_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag,
> diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
> index b6e7b5952ab5..e955539686a4 100644
> --- a/arch/powerpc/mm/dma-noncoherent.c
> +++ b/arch/powerpc/mm/dma-noncoherent.c
> @@ -29,7 +29,7 @@
> #include <linux/string.h>
> #include <linux/types.h>
> #include <linux/highmem.h>
> -#include <linux/dma-mapping.h>
> +#include <linux/dma-direct.h>
> #include <linux/export.h>
>
> #include <asm/tlbflush.h>
> @@ -151,8 +151,8 @@ static struct ppc_vm_region *ppc_vm_region_find(struct ppc_vm_region *head, unsi
> * Allocate DMA-coherent memory space and return both the kernel remapped
> * virtual and bus address for that space.
> */
> -void *
> -__dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp)
> +void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> struct page *page;
> struct ppc_vm_region *c;
> @@ -223,7 +223,7 @@ __dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t
> /*
> * Set the "dma handle"
> */
> - *handle = page_to_phys(page);
> + *dma_handle = phys_to_dma(dev, page_to_phys(page));
>
> do {
> SetPageReserved(page);
> @@ -249,12 +249,12 @@ __dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *handle, gfp_t
> no_page:
> return NULL;
> }
> -EXPORT_SYMBOL(__dma_alloc_coherent);
>
> /*
> * free a page as defined by the above mapping.
> */
> -void __dma_free_coherent(size_t size, void *vaddr)
> +void __dma_nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
> + dma_addr_t dma_handle, unsigned long attrs)
> {
> struct ppc_vm_region *c;
> unsigned long flags, addr;
> @@ -309,7 +309,6 @@ void __dma_free_coherent(size_t size, void *vaddr)
> __func__, vaddr);
> dump_stack();
> }
> -EXPORT_SYMBOL(__dma_free_coherent);
>
> /*
> * make an area consistent.
> @@ -401,7 +400,7 @@ EXPORT_SYMBOL(__dma_sync_page);
>
> /*
> * Return the PFN for a given cpu virtual address returned by
> - * __dma_alloc_coherent. This is used by dma_mmap_coherent()
> + * __dma_nommu_alloc_coherent. This is used by dma_mmap_coherent()
> */
> unsigned long __dma_get_coherent_pfn(unsigned long cpu_addr)
> {
> diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
> index a886c2c22097..7e4f8ca19ce8 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -47,7 +47,7 @@ static int __init warp_probe(void)
> if (!of_machine_is_compatible("pika,warp"))
> return 0;
>
> - /* For __dma_alloc_coherent */
> + /* For __dma_nommu_alloc_coherent */
> ISA_DMA_THRESHOLD = ~0L;
>
> return 1;
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:15

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 01/34] powerpc: use mm zones more sensibly

Ben / Michael,

can we get this one queued up for 4.21 to prepare for the DMA work later
on?

On Wed, Nov 14, 2018 at 09:22:41AM +0100, Christoph Hellwig wrote:
> Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on
> common 64-bit configfs, and ZONE_DMA32 is used for 31-bit schemes.
>
> Move to a scheme closer to what other architectures use (and I dare to
> say the intent of the system):
>
> - ZONE_DMA: optionally for memory < 31-bit (64-bit embedded only)
> - ZONE_NORMAL: everything addressable by the kernel
> - ZONE_HIGHMEM: memory > 32-bit for 32-bit kernels
>
> Also provide information on how ZONE_DMA is used by defining
> ARCH_ZONE_DMA_BITS.
>
> Contains various fixes from Benjamin Herrenschmidt.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/Kconfig | 8 +---
> arch/powerpc/include/asm/page.h | 2 +
> arch/powerpc/include/asm/pgtable.h | 1 -
> arch/powerpc/kernel/dma-swiotlb.c | 6 +--
> arch/powerpc/kernel/dma.c | 7 +--
> arch/powerpc/mm/mem.c | 47 +++++++------------
> arch/powerpc/platforms/85xx/corenet_generic.c | 10 ----
> arch/powerpc/platforms/85xx/qemu_e500.c | 9 ----
> include/linux/mmzone.h | 2 +-
> 9 files changed, 25 insertions(+), 67 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 8be31261aec8..cffff3613bc1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -374,9 +374,9 @@ config PPC_ADV_DEBUG_DAC_RANGE
> depends on PPC_ADV_DEBUG_REGS && 44x
> default y
>
> -config ZONE_DMA32
> +config ZONE_DMA
> bool
> - default y if PPC64
> + default y if PPC_BOOK3E_64
>
> config PGTABLE_LEVELS
> int
> @@ -869,10 +869,6 @@ config ISA
> have an IBM RS/6000 or pSeries machine, say Y. If you have an
> embedded board, consult your board documentation.
>
> -config ZONE_DMA
> - bool
> - default y
> -
> config GENERIC_ISA_DMA
> bool
> depends on ISA_DMA_API
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index f6a1265face2..fc8c9ac0c6be 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -354,4 +354,6 @@ typedef struct page *pgtable_t;
> #endif /* __ASSEMBLY__ */
> #include <asm/slice.h>
>
> +#define ARCH_ZONE_DMA_BITS 31
> +
> #endif /* _ASM_POWERPC_PAGE_H */
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index 9679b7519a35..8af32ce93c7f 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -66,7 +66,6 @@ extern unsigned long empty_zero_page[];
>
> extern pgd_t swapper_pg_dir[];
>
> -void limit_zone_pfn(enum zone_type zone, unsigned long max_pfn);
> int dma_pfn_limit_to_zone(u64 pfn_limit);
> extern void paging_init(void);
>
> diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
> index 5fc335f4d9cd..678811abccfc 100644
> --- a/arch/powerpc/kernel/dma-swiotlb.c
> +++ b/arch/powerpc/kernel/dma-swiotlb.c
> @@ -108,12 +108,8 @@ int __init swiotlb_setup_bus_notifier(void)
>
> void __init swiotlb_detect_4g(void)
> {
> - if ((memblock_end_of_DRAM() - 1) > 0xffffffff) {
> + if ((memblock_end_of_DRAM() - 1) > 0xffffffff)
> ppc_swiotlb_enable = 1;
> -#ifdef CONFIG_ZONE_DMA32
> - limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
> -#endif
> - }
> }
>
> static int __init check_swiotlb_enabled(void)
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index dbfc7056d7df..6551685a4ed0 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -50,7 +50,7 @@ static int dma_nommu_dma_supported(struct device *dev, u64 mask)
> return 1;
>
> #ifdef CONFIG_FSL_SOC
> - /* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
> + /* Freescale gets another chance via ZONE_DMA, however
> * that will have to be refined if/when they support iommus
> */
> return 1;
> @@ -94,13 +94,10 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
> }
>
> switch (zone) {
> +#ifdef CONFIG_ZONE_DMA
> case ZONE_DMA:
> flag |= GFP_DMA;
> break;
> -#ifdef CONFIG_ZONE_DMA32
> - case ZONE_DMA32:
> - flag |= GFP_DMA32;
> - break;
> #endif
> };
> #endif /* CONFIG_FSL_SOC */
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 0a64fffabee1..c0b676c3a5ba 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -246,35 +246,19 @@ static int __init mark_nonram_nosave(void)
> }
> #endif
>
> -static bool zone_limits_final;
> -
> /*
> - * The memory zones past TOP_ZONE are managed by generic mm code.
> - * These should be set to zero since that's what every other
> - * architecture does.
> + * Zones usage:
> + *
> + * We setup ZONE_DMA to be 31-bits on all platforms and ZONE_NORMAL to be
> + * everything else. GFP_DMA32 page allocations automatically fall back to
> + * ZONE_DMA.
> + *
> + * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
> + * inform the generic DMA mapping code. 32-bit only devices (if not handled
> + * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
> + * otherwise served by ZONE_DMA.
> */
> -static unsigned long max_zone_pfns[MAX_NR_ZONES] = {
> - [0 ... TOP_ZONE ] = ~0UL,
> - [TOP_ZONE + 1 ... MAX_NR_ZONES - 1] = 0
> -};
> -
> -/*
> - * Restrict the specified zone and all more restrictive zones
> - * to be below the specified pfn. May not be called after
> - * paging_init().
> - */
> -void __init limit_zone_pfn(enum zone_type zone, unsigned long pfn_limit)
> -{
> - int i;
> -
> - if (WARN_ON(zone_limits_final))
> - return;
> -
> - for (i = zone; i >= 0; i--) {
> - if (max_zone_pfns[i] > pfn_limit)
> - max_zone_pfns[i] = pfn_limit;
> - }
> -}
> +static unsigned long max_zone_pfns[MAX_NR_ZONES];
>
> /*
> * Find the least restrictive zone that is entirely below the
> @@ -324,11 +308,14 @@ void __init paging_init(void)
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> (long int)((top_of_ram - total_ram) >> 20));
>
> +#ifdef CONFIG_ZONE_DMA
> + max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
> +#endif
> + max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
> #ifdef CONFIG_HIGHMEM
> - limit_zone_pfn(ZONE_NORMAL, lowmem_end_addr >> PAGE_SHIFT);
> + max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
> #endif
> - limit_zone_pfn(TOP_ZONE, top_of_ram >> PAGE_SHIFT);
> - zone_limits_final = true;
> +
> free_area_init_nodes(max_zone_pfns);
>
> mark_nonram_nosave();
> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
> index ac191a7a1337..b0dac307bebf 100644
> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> @@ -68,16 +68,6 @@ void __init corenet_gen_setup_arch(void)
>
> swiotlb_detect_4g();
>
> -#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
> - /*
> - * Inbound windows don't cover the full lower 4 GiB
> - * due to conflicts with PCICSRBAR and outbound windows,
> - * so limit the DMA32 zone to 2 GiB, to allow consistent
> - * allocations to succeed.
> - */
> - limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
> -#endif
> -
> pr_info("%s board\n", ppc_md.name);
>
> mpc85xx_qe_init();
> diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
> index b63a8548366f..27631c607f3d 100644
> --- a/arch/powerpc/platforms/85xx/qemu_e500.c
> +++ b/arch/powerpc/platforms/85xx/qemu_e500.c
> @@ -45,15 +45,6 @@ static void __init qemu_e500_setup_arch(void)
>
> fsl_pci_assign_primary();
> swiotlb_detect_4g();
> -#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
> - /*
> - * Inbound windows don't cover the full lower 4 GiB
> - * due to conflicts with PCICSRBAR and outbound windows,
> - * so limit the DMA32 zone to 2 GiB, to allow consistent
> - * allocations to succeed.
> - */
> - limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
> -#endif
> mpc85xx_smp_init();
> }
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 847705a6d0ec..e2d01ccd071d 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -314,7 +314,7 @@ enum zone_type {
> * Architecture Limit
> * ---------------------------
> * parisc, ia64, sparc <4G
> - * s390 <2G
> + * s390, powerpc <2G
> * arm Various
> * alpha Unlimited or 0-16MB.
> *
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:24

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 19/34] cxl: drop the dma_set_mask callback from vphb

ping?

On Wed, Nov 14, 2018 at 09:22:59AM +0100, Christoph Hellwig wrote:
> The CXL code never even looks at the dma mask, so there is no good
> reason for this sanity check. Remove it because it gets in the way
> of the dma ops refactoring.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> drivers/misc/cxl/vphb.c | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c
> index 7908633d9204..49da2f744bbf 100644
> --- a/drivers/misc/cxl/vphb.c
> +++ b/drivers/misc/cxl/vphb.c
> @@ -11,17 +11,6 @@
> #include <misc/cxl.h>
> #include "cxl.h"
>
> -static int cxl_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
> -{
> - if (dma_mask < DMA_BIT_MASK(64)) {
> - pr_info("%s only 64bit DMA supported on CXL", __func__);
> - return -EIO;
> - }
> -
> - *(pdev->dev.dma_mask) = dma_mask;
> - return 0;
> -}
> -
> static int cxl_pci_probe_mode(struct pci_bus *bus)
> {
> return PCI_PROBE_NORMAL;
> @@ -220,7 +209,6 @@ static struct pci_controller_ops cxl_pci_controller_ops =
> .reset_secondary_bus = cxl_pci_reset_secondary_bus,
> .setup_msi_irqs = cxl_setup_msi_irqs,
> .teardown_msi_irqs = cxl_teardown_msi_irqs,
> - .dma_set_mask = cxl_dma_set_mask,
> };
>
> int cxl_pci_vphb_add(struct cxl_afu *afu)
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:31

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 07/34] powerpc/dma: remove the no-op dma_nommu_unmap_{page, sg} routines

ping?

On Wed, Nov 14, 2018 at 09:22:47AM +0100, Christoph Hellwig wrote:
> These methods are optional, no need to implement no-op versions.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> Acked-by: Benjamin Herrenschmidt <[email protected]>
> ---
> arch/powerpc/kernel/dma.c | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
> index d6deb458bb91..7078d72baec2 100644
> --- a/arch/powerpc/kernel/dma.c
> +++ b/arch/powerpc/kernel/dma.c
> @@ -197,12 +197,6 @@ static int dma_nommu_map_sg(struct device *dev, struct scatterlist *sgl,
> return nents;
> }
>
> -static void dma_nommu_unmap_sg(struct device *dev, struct scatterlist *sg,
> - int nents, enum dma_data_direction direction,
> - unsigned long attrs)
> -{
> -}
> -
> static u64 dma_nommu_get_required_mask(struct device *dev)
> {
> u64 end, mask;
> @@ -228,14 +222,6 @@ static inline dma_addr_t dma_nommu_map_page(struct device *dev,
> return page_to_phys(page) + offset + get_dma_offset(dev);
> }
>
> -static inline void dma_nommu_unmap_page(struct device *dev,
> - dma_addr_t dma_address,
> - size_t size,
> - enum dma_data_direction direction,
> - unsigned long attrs)
> -{
> -}
> -
> #ifdef CONFIG_NOT_COHERENT_CACHE
> static inline void dma_nommu_sync_sg(struct device *dev,
> struct scatterlist *sgl, int nents,
> @@ -261,10 +247,8 @@ const struct dma_map_ops dma_nommu_ops = {
> .free = dma_nommu_free_coherent,
> .mmap = dma_nommu_mmap_coherent,
> .map_sg = dma_nommu_map_sg,
> - .unmap_sg = dma_nommu_unmap_sg,
> .dma_supported = dma_nommu_dma_supported,
> .map_page = dma_nommu_map_page,
> - .unmap_page = dma_nommu_unmap_page,
> .get_required_mask = dma_nommu_get_required_mask,
> #ifdef CONFIG_NOT_COHERENT_CACHE
> .sync_single_for_cpu = dma_nommu_sync_single,
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:39

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 04/34] powerpc/dma: remove the unused ISA_DMA_THRESHOLD export

ping?

On Wed, Nov 14, 2018 at 09:22:44AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <[email protected]>
> Acked-by: Benjamin Herrenschmidt <[email protected]>
> ---
> arch/powerpc/kernel/setup_32.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index 81909600013a..07f7e6aaf104 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -59,7 +59,6 @@ unsigned long ISA_DMA_THRESHOLD;
> unsigned int DMA_MODE_READ;
> unsigned int DMA_MODE_WRITE;
>
> -EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
> EXPORT_SYMBOL(DMA_MODE_READ);
> EXPORT_SYMBOL(DMA_MODE_WRITE);
>
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:13:55

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 03/34] powerpc/dma: remove the unused ARCH_HAS_DMA_MMAP_COHERENT define

ping?

On Wed, Nov 14, 2018 at 09:22:43AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <[email protected]>
> Acked-by: Benjamin Herrenschmidt <[email protected]>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index 8fa394520af6..f2a4a7142b1e 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -112,7 +112,5 @@ extern int dma_set_mask(struct device *dev, u64 dma_mask);
>
> extern u64 __dma_get_required_mask(struct device *dev);
>
> -#define ARCH_HAS_DMA_MMAP_COHERENT
> -
> #endif /* __KERNEL__ */
> #endif /* _ASM_DMA_MAPPING_H */
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:14:14

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 08/34] powerpc/dma: untangle vio_dma_mapping_ops from dma_iommu_ops

ping?

On Wed, Nov 14, 2018 at 09:22:48AM +0100, Christoph Hellwig wrote:
> vio_dma_mapping_ops currently does a lot of indirect calls through
> dma_iommu_ops, which not only make the code harder to follow but are
> also expensive in the post-spectre world. Unwind the indirect calls
> by calling the ppc_iommu_* or iommu_* APIs directly applicable, or
> just use the dma_iommu_* methods directly where we can.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/include/asm/iommu.h | 1 +
> arch/powerpc/kernel/dma-iommu.c | 2 +-
> arch/powerpc/platforms/pseries/vio.c | 87 ++++++++++++----------------
> 3 files changed, 38 insertions(+), 52 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
> index 35db0cbc9222..75daa10f31a4 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -242,6 +242,7 @@ static inline int __init tce_iommu_bus_notifier_init(void)
> }
> #endif /* !CONFIG_IOMMU_API */
>
> +u64 dma_iommu_get_required_mask(struct device *dev);
> int dma_iommu_mapping_error(struct device *dev, dma_addr_t dma_addr);
>
> #else
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 2ca6cfaebf65..0613278abf9f 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -92,7 +92,7 @@ int dma_iommu_dma_supported(struct device *dev, u64 mask)
> return 1;
> }
>
> -static u64 dma_iommu_get_required_mask(struct device *dev)
> +u64 dma_iommu_get_required_mask(struct device *dev)
> {
> struct iommu_table *tbl = get_iommu_table_base(dev);
> u64 mask;
> diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
> index 88f1ad1d6309..ea3a9745c812 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -492,7 +492,9 @@ static void *vio_dma_iommu_alloc_coherent(struct device *dev, size_t size,
> return NULL;
> }
>
> - ret = dma_iommu_ops.alloc(dev, size, dma_handle, flag, attrs);
> + ret = iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
> + dma_handle, dev->coherent_dma_mask, flag,
> + dev_to_node(dev));
> if (unlikely(ret == NULL)) {
> vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
> atomic_inc(&viodev->cmo.allocs_failed);
> @@ -507,8 +509,7 @@ static void vio_dma_iommu_free_coherent(struct device *dev, size_t size,
> {
> struct vio_dev *viodev = to_vio_dev(dev);
>
> - dma_iommu_ops.free(dev, size, vaddr, dma_handle, attrs);
> -
> + iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
> vio_cmo_dealloc(viodev, roundup(size, PAGE_SIZE));
> }
>
> @@ -518,22 +519,22 @@ static dma_addr_t vio_dma_iommu_map_page(struct device *dev, struct page *page,
> unsigned long attrs)
> {
> struct vio_dev *viodev = to_vio_dev(dev);
> - struct iommu_table *tbl;
> + struct iommu_table *tbl = get_iommu_table_base(dev);
> dma_addr_t ret = IOMMU_MAPPING_ERROR;
>
> - tbl = get_iommu_table_base(dev);
> - if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)))) {
> - atomic_inc(&viodev->cmo.allocs_failed);
> - return ret;
> - }
> -
> - ret = dma_iommu_ops.map_page(dev, page, offset, size, direction, attrs);
> - if (unlikely(dma_mapping_error(dev, ret))) {
> - vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
> - atomic_inc(&viodev->cmo.allocs_failed);
> - }
> -
> + if (vio_cmo_alloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl))))
> + goto out_fail;
> + ret = iommu_map_page(dev, tbl, page, offset, size, device_to_mask(dev),
> + direction, attrs);
> + if (unlikely(ret == IOMMU_MAPPING_ERROR))
> + goto out_deallocate;
> return ret;
> +
> +out_deallocate:
> + vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
> +out_fail:
> + atomic_inc(&viodev->cmo.allocs_failed);
> + return IOMMU_MAPPING_ERROR;
> }
>
> static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
> @@ -542,11 +543,9 @@ static void vio_dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
> unsigned long attrs)
> {
> struct vio_dev *viodev = to_vio_dev(dev);
> - struct iommu_table *tbl;
> -
> - tbl = get_iommu_table_base(dev);
> - dma_iommu_ops.unmap_page(dev, dma_handle, size, direction, attrs);
> + struct iommu_table *tbl = get_iommu_table_base(dev);
>
> + iommu_unmap_page(tbl, dma_handle, size, direction, attrs);
> vio_cmo_dealloc(viodev, roundup(size, IOMMU_PAGE_SIZE(tbl)));
> }
>
> @@ -555,34 +554,32 @@ static int vio_dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
> unsigned long attrs)
> {
> struct vio_dev *viodev = to_vio_dev(dev);
> - struct iommu_table *tbl;
> + struct iommu_table *tbl = get_iommu_table_base(dev);
> struct scatterlist *sgl;
> int ret, count;
> size_t alloc_size = 0;
>
> - tbl = get_iommu_table_base(dev);
> for_each_sg(sglist, sgl, nelems, count)
> alloc_size += roundup(sgl->length, IOMMU_PAGE_SIZE(tbl));
>
> - if (vio_cmo_alloc(viodev, alloc_size)) {
> - atomic_inc(&viodev->cmo.allocs_failed);
> - return 0;
> - }
> -
> - ret = dma_iommu_ops.map_sg(dev, sglist, nelems, direction, attrs);
> -
> - if (unlikely(!ret)) {
> - vio_cmo_dealloc(viodev, alloc_size);
> - atomic_inc(&viodev->cmo.allocs_failed);
> - return ret;
> - }
> + if (vio_cmo_alloc(viodev, alloc_size))
> + goto out_fail;
> + ret = ppc_iommu_map_sg(dev, tbl, sglist, nelems, device_to_mask(dev),
> + direction, attrs);
> + if (unlikely(!ret))
> + goto out_deallocate;
>
> for_each_sg(sglist, sgl, ret, count)
> alloc_size -= roundup(sgl->dma_length, IOMMU_PAGE_SIZE(tbl));
> if (alloc_size)
> vio_cmo_dealloc(viodev, alloc_size);
> -
> return ret;
> +
> +out_deallocate:
> + vio_cmo_dealloc(viodev, alloc_size);
> +out_fail:
> + atomic_inc(&viodev->cmo.allocs_failed);
> + return 0;
> }
>
> static void vio_dma_iommu_unmap_sg(struct device *dev,
> @@ -591,30 +588,18 @@ static void vio_dma_iommu_unmap_sg(struct device *dev,
> unsigned long attrs)
> {
> struct vio_dev *viodev = to_vio_dev(dev);
> - struct iommu_table *tbl;
> + struct iommu_table *tbl = get_iommu_table_base(dev);
> struct scatterlist *sgl;
> size_t alloc_size = 0;
> int count;
>
> - tbl = get_iommu_table_base(dev);
> for_each_sg(sglist, sgl, nelems, count)
> alloc_size += roundup(sgl->dma_length, IOMMU_PAGE_SIZE(tbl));
>
> - dma_iommu_ops.unmap_sg(dev, sglist, nelems, direction, attrs);
> -
> + ppc_iommu_unmap_sg(tbl, sglist, nelems, direction, attrs);
> vio_cmo_dealloc(viodev, alloc_size);
> }
>
> -static int vio_dma_iommu_dma_supported(struct device *dev, u64 mask)
> -{
> - return dma_iommu_ops.dma_supported(dev, mask);
> -}
> -
> -static u64 vio_dma_get_required_mask(struct device *dev)
> -{
> - return dma_iommu_ops.get_required_mask(dev);
> -}
> -
> static const struct dma_map_ops vio_dma_mapping_ops = {
> .alloc = vio_dma_iommu_alloc_coherent,
> .free = vio_dma_iommu_free_coherent,
> @@ -623,8 +608,8 @@ static const struct dma_map_ops vio_dma_mapping_ops = {
> .unmap_sg = vio_dma_iommu_unmap_sg,
> .map_page = vio_dma_iommu_map_page,
> .unmap_page = vio_dma_iommu_unmap_page,
> - .dma_supported = vio_dma_iommu_dma_supported,
> - .get_required_mask = vio_dma_get_required_mask,
> + .dma_supported = dma_iommu_mapping_error,
> + .get_required_mask = dma_iommu_get_required_mask,
> .mapping_error = dma_iommu_mapping_error,
> };
>
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 14:15:19

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 14/34] powerpc/dart: remove dead cleanup code in iommu_init_early_dart

ping?

On Wed, Nov 14, 2018 at 09:22:54AM +0100, Christoph Hellwig wrote:
> If dart_init failed we didn't have a chance to setup dma or controller
> ops yet, so there is no point in resetting them.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/sysdev/dart_iommu.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
> index a5b40d1460f1..283ce04c5844 100644
> --- a/arch/powerpc/sysdev/dart_iommu.c
> +++ b/arch/powerpc/sysdev/dart_iommu.c
> @@ -428,7 +428,7 @@ void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)
>
> /* Initialize the DART HW */
> if (dart_init(dn) != 0)
> - goto bail;
> + return;
>
> /* Setup bypass if supported */
> if (dart_is_u4)
> @@ -439,15 +439,6 @@ void __init iommu_init_early_dart(struct pci_controller_ops *controller_ops)
>
> /* Setup pci_dma ops */
> set_pci_dma_ops(&dma_iommu_ops);
> - return;
> -
> - bail:
> - /* If init failed, use direct iommu and null setup functions */
> - controller_ops->dma_dev_setup = NULL;
> - controller_ops->dma_bus_setup = NULL;
> -
> - /* Setup pci_dma ops */
> - set_pci_dma_ops(&dma_nommu_ops);
> }
>
> #ifdef CONFIG_PM
> --
> 2.19.1
>
> _______________________________________________
> iommu mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
---end quoted text---

2018-12-06 17:12:49

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Please don’t merge this code. We are still testing and trying to figure out where the problems are in the code.

— Christian

Sent from my iPhone

> On 6. Dec 2018, at 11:55, Christian Zigotzky <[email protected]> wrote:
>
>> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
>>
>> Thanks. Can you try a few stepping points in the tree?
>>
>> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>> (the first one) applied?
>>
>> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b
>>
>> And if that still works with commits up to
>> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a
>>
> Hi Christoph,
>
> I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the following command:
>
> git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>
> Result: PASEMI onboard ethernet works again and the P5020 board boots.
>
> I will test the other commits in the next days.
>
> @All
> It is really important, that you also test Christoph's work on your PASEMI and NXP boards. Could you please help us with solving the issues?
>
> 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
>
> Thanks,
> Christian
>

2018-12-06 19:37:29

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote:
> Please don’t merge this code. We are still testing and trying to figure out where the problems are in the code.

The ones I sent pings for were either tested successfully by you
(the zone change) or are trivial cleanups that don't affect your setup.

2018-12-07 07:51:16

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Good to know. Sorry because of the email.

Sent from my iPhone

> On 6. Dec 2018, at 20:36, Christoph Hellwig <[email protected]> wrote:
>
>> On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote:
>> Please don’t merge this code. We are still testing and trying to figure out where the problems are in the code.
>
> The ones I sent pings for were either tested successfully by you
> (the zone change) or are trivial cleanups that don't affect your setup.

2018-12-07 12:19:43

by Michael Ellerman

[permalink] [raw]
Subject: Re: [PATCH 01/34] powerpc: use mm zones more sensibly

Christoph Hellwig <[email protected]> writes:

> Ben / Michael,
>
> can we get this one queued up for 4.21 to prepare for the DMA work later
> on?

I was hoping the PASEMI / NXP regressions could be solved before
merging.

My p5020ds is booting fine with this series, so I'm not sure why it's
causing problems on Christian's machine.

The last time I turned on my PASEMI board it tripped some breakers, so I
need to investigate that before I can help test that.

I'll see how things look on Monday and either merge the commits you
identified or the whole series depending on if there's any more info
from Christian.

cheers

> On Wed, Nov 14, 2018 at 09:22:41AM +0100, Christoph Hellwig wrote:
>> Powerpc has somewhat odd usage where ZONE_DMA is used for all memory on
>> common 64-bit configfs, and ZONE_DMA32 is used for 31-bit schemes.
>>
>> Move to a scheme closer to what other architectures use (and I dare to
>> say the intent of the system):
>>
>> - ZONE_DMA: optionally for memory < 31-bit (64-bit embedded only)
>> - ZONE_NORMAL: everything addressable by the kernel
>> - ZONE_HIGHMEM: memory > 32-bit for 32-bit kernels
>>
>> Also provide information on how ZONE_DMA is used by defining
>> ARCH_ZONE_DMA_BITS.
>>
>> Contains various fixes from Benjamin Herrenschmidt.
>>
>> Signed-off-by: Christoph Hellwig <[email protected]>
>> ---
>> arch/powerpc/Kconfig | 8 +---
>> arch/powerpc/include/asm/page.h | 2 +
>> arch/powerpc/include/asm/pgtable.h | 1 -
>> arch/powerpc/kernel/dma-swiotlb.c | 6 +--
>> arch/powerpc/kernel/dma.c | 7 +--
>> arch/powerpc/mm/mem.c | 47 +++++++------------
>> arch/powerpc/platforms/85xx/corenet_generic.c | 10 ----
>> arch/powerpc/platforms/85xx/qemu_e500.c | 9 ----
>> include/linux/mmzone.h | 2 +-
>> 9 files changed, 25 insertions(+), 67 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 8be31261aec8..cffff3613bc1 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -374,9 +374,9 @@ config PPC_ADV_DEBUG_DAC_RANGE
>> depends on PPC_ADV_DEBUG_REGS && 44x
>> default y
>>
>> -config ZONE_DMA32
>> +config ZONE_DMA
>> bool
>> - default y if PPC64
>> + default y if PPC_BOOK3E_64
>>
>> config PGTABLE_LEVELS
>> int
>> @@ -869,10 +869,6 @@ config ISA
>> have an IBM RS/6000 or pSeries machine, say Y. If you have an
>> embedded board, consult your board documentation.
>>
>> -config ZONE_DMA
>> - bool
>> - default y
>> -
>> config GENERIC_ISA_DMA
>> bool
>> depends on ISA_DMA_API
>> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
>> index f6a1265face2..fc8c9ac0c6be 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -354,4 +354,6 @@ typedef struct page *pgtable_t;
>> #endif /* __ASSEMBLY__ */
>> #include <asm/slice.h>
>>
>> +#define ARCH_ZONE_DMA_BITS 31
>> +
>> #endif /* _ASM_POWERPC_PAGE_H */
>> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
>> index 9679b7519a35..8af32ce93c7f 100644
>> --- a/arch/powerpc/include/asm/pgtable.h
>> +++ b/arch/powerpc/include/asm/pgtable.h
>> @@ -66,7 +66,6 @@ extern unsigned long empty_zero_page[];
>>
>> extern pgd_t swapper_pg_dir[];
>>
>> -void limit_zone_pfn(enum zone_type zone, unsigned long max_pfn);
>> int dma_pfn_limit_to_zone(u64 pfn_limit);
>> extern void paging_init(void);
>>
>> diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
>> index 5fc335f4d9cd..678811abccfc 100644
>> --- a/arch/powerpc/kernel/dma-swiotlb.c
>> +++ b/arch/powerpc/kernel/dma-swiotlb.c
>> @@ -108,12 +108,8 @@ int __init swiotlb_setup_bus_notifier(void)
>>
>> void __init swiotlb_detect_4g(void)
>> {
>> - if ((memblock_end_of_DRAM() - 1) > 0xffffffff) {
>> + if ((memblock_end_of_DRAM() - 1) > 0xffffffff)
>> ppc_swiotlb_enable = 1;
>> -#ifdef CONFIG_ZONE_DMA32
>> - limit_zone_pfn(ZONE_DMA32, (1ULL << 32) >> PAGE_SHIFT);
>> -#endif
>> - }
>> }
>>
>> static int __init check_swiotlb_enabled(void)
>> diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
>> index dbfc7056d7df..6551685a4ed0 100644
>> --- a/arch/powerpc/kernel/dma.c
>> +++ b/arch/powerpc/kernel/dma.c
>> @@ -50,7 +50,7 @@ static int dma_nommu_dma_supported(struct device *dev, u64 mask)
>> return 1;
>>
>> #ifdef CONFIG_FSL_SOC
>> - /* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
>> + /* Freescale gets another chance via ZONE_DMA, however
>> * that will have to be refined if/when they support iommus
>> */
>> return 1;
>> @@ -94,13 +94,10 @@ void *__dma_nommu_alloc_coherent(struct device *dev, size_t size,
>> }
>>
>> switch (zone) {
>> +#ifdef CONFIG_ZONE_DMA
>> case ZONE_DMA:
>> flag |= GFP_DMA;
>> break;
>> -#ifdef CONFIG_ZONE_DMA32
>> - case ZONE_DMA32:
>> - flag |= GFP_DMA32;
>> - break;
>> #endif
>> };
>> #endif /* CONFIG_FSL_SOC */
>> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
>> index 0a64fffabee1..c0b676c3a5ba 100644
>> --- a/arch/powerpc/mm/mem.c
>> +++ b/arch/powerpc/mm/mem.c
>> @@ -246,35 +246,19 @@ static int __init mark_nonram_nosave(void)
>> }
>> #endif
>>
>> -static bool zone_limits_final;
>> -
>> /*
>> - * The memory zones past TOP_ZONE are managed by generic mm code.
>> - * These should be set to zero since that's what every other
>> - * architecture does.
>> + * Zones usage:
>> + *
>> + * We setup ZONE_DMA to be 31-bits on all platforms and ZONE_NORMAL to be
>> + * everything else. GFP_DMA32 page allocations automatically fall back to
>> + * ZONE_DMA.
>> + *
>> + * By using 31-bit unconditionally, we can exploit ARCH_ZONE_DMA_BITS to
>> + * inform the generic DMA mapping code. 32-bit only devices (if not handled
>> + * by an IOMMU anyway) will take a first dip into ZONE_NORMAL and get
>> + * otherwise served by ZONE_DMA.
>> */
>> -static unsigned long max_zone_pfns[MAX_NR_ZONES] = {
>> - [0 ... TOP_ZONE ] = ~0UL,
>> - [TOP_ZONE + 1 ... MAX_NR_ZONES - 1] = 0
>> -};
>> -
>> -/*
>> - * Restrict the specified zone and all more restrictive zones
>> - * to be below the specified pfn. May not be called after
>> - * paging_init().
>> - */
>> -void __init limit_zone_pfn(enum zone_type zone, unsigned long pfn_limit)
>> -{
>> - int i;
>> -
>> - if (WARN_ON(zone_limits_final))
>> - return;
>> -
>> - for (i = zone; i >= 0; i--) {
>> - if (max_zone_pfns[i] > pfn_limit)
>> - max_zone_pfns[i] = pfn_limit;
>> - }
>> -}
>> +static unsigned long max_zone_pfns[MAX_NR_ZONES];
>>
>> /*
>> * Find the least restrictive zone that is entirely below the
>> @@ -324,11 +308,14 @@ void __init paging_init(void)
>> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
>> (long int)((top_of_ram - total_ram) >> 20));
>>
>> +#ifdef CONFIG_ZONE_DMA
>> + max_zone_pfns[ZONE_DMA] = min(max_low_pfn, 0x7fffffffUL >> PAGE_SHIFT);
>> +#endif
>> + max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
>> #ifdef CONFIG_HIGHMEM
>> - limit_zone_pfn(ZONE_NORMAL, lowmem_end_addr >> PAGE_SHIFT);
>> + max_zone_pfns[ZONE_HIGHMEM] = max_pfn;
>> #endif
>> - limit_zone_pfn(TOP_ZONE, top_of_ram >> PAGE_SHIFT);
>> - zone_limits_final = true;
>> +
>> free_area_init_nodes(max_zone_pfns);
>>
>> mark_nonram_nosave();
>> diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
>> index ac191a7a1337..b0dac307bebf 100644
>> --- a/arch/powerpc/platforms/85xx/corenet_generic.c
>> +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
>> @@ -68,16 +68,6 @@ void __init corenet_gen_setup_arch(void)
>>
>> swiotlb_detect_4g();
>>
>> -#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
>> - /*
>> - * Inbound windows don't cover the full lower 4 GiB
>> - * due to conflicts with PCICSRBAR and outbound windows,
>> - * so limit the DMA32 zone to 2 GiB, to allow consistent
>> - * allocations to succeed.
>> - */
>> - limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
>> -#endif
>> -
>> pr_info("%s board\n", ppc_md.name);
>>
>> mpc85xx_qe_init();
>> diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
>> index b63a8548366f..27631c607f3d 100644
>> --- a/arch/powerpc/platforms/85xx/qemu_e500.c
>> +++ b/arch/powerpc/platforms/85xx/qemu_e500.c
>> @@ -45,15 +45,6 @@ static void __init qemu_e500_setup_arch(void)
>>
>> fsl_pci_assign_primary();
>> swiotlb_detect_4g();
>> -#if defined(CONFIG_FSL_PCI) && defined(CONFIG_ZONE_DMA32)
>> - /*
>> - * Inbound windows don't cover the full lower 4 GiB
>> - * due to conflicts with PCICSRBAR and outbound windows,
>> - * so limit the DMA32 zone to 2 GiB, to allow consistent
>> - * allocations to succeed.
>> - */
>> - limit_zone_pfn(ZONE_DMA32, 1UL << (31 - PAGE_SHIFT));
>> -#endif
>> mpc85xx_smp_init();
>> }
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 847705a6d0ec..e2d01ccd071d 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -314,7 +314,7 @@ enum zone_type {
>> * Architecture Limit
>> * ---------------------------
>> * parisc, ia64, sparc <4G
>> - * s390 <2G
>> + * s390, powerpc <2G
>> * arm Various
>> * alpha Unlimited or 0-16MB.
>> *
>> --
>> 2.19.1
>>
>> _______________________________________________
>> iommu mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
> ---end quoted text---

2018-12-07 13:46:11

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 06 December 2018 at 11:55AM, Christian Zigotzky wrote:
> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
>>
>> Thanks.  Can you try a few stepping points in the tree?
>>
>> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>> (the first one) applied?
>>
>> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b
>>
>> And if that still works with commits up to
>> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a
>>
> Hi Christoph,
>
> I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the
> following command:
>
> git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>
> Result: PASEMI onboard ethernet works again and the P5020 board boots.
>
> I will test the other commits in the next days.
>
> @All
> It is really important, that you also test Christoph's work on your
> PASEMI and NXP boards. Could you please help us with solving the issues?
>
> 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
>
> Thanks,
> Christian
>
>
Today I tested the commit 5da11e49df21f21dac25a2491aa788307bdacb6b.

git checkout 5da11e49df21f21dac25a2491aa788307bdacb6b

The PASEMI onboard ethernet works and the P5020 board boots.

-- Christian


2018-12-07 14:11:25

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 01/34] powerpc: use mm zones more sensibly

On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote:
> Christoph Hellwig <[email protected]> writes:
>
> > Ben / Michael,
> >
> > can we get this one queued up for 4.21 to prepare for the DMA work later
> > on?
>
> I was hoping the PASEMI / NXP regressions could be solved before
> merging.
>
> My p5020ds is booting fine with this series, so I'm not sure why it's
> causing problems on Christian's machine.
>
> The last time I turned on my PASEMI board it tripped some breakers, so I
> need to investigate that before I can help test that.
>
> I'll see how things look on Monday and either merge the commits you
> identified or the whole series depending on if there's any more info
> from Christian.

Christian just confirmed everything up to at least
"powerpc/dma: stop overriding dma_get_required_mask" works for his
setups.

2018-12-07 15:06:15

by Christian Zigotzky

[permalink] [raw]
Subject: Re: [PATCH 01/34] powerpc: use mm zones more sensibly

I will work at the weekend to figure out where the problematic commit is.

— Christian

Sent from my iPhone

> On 7. Dec 2018, at 15:09, Christoph Hellwig <[email protected]> wrote:
>
>> On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote:
>> Christoph Hellwig <[email protected]> writes:
>>
>>> Ben / Michael,
>>>
>>> can we get this one queued up for 4.21 to prepare for the DMA work later
>>> on?
>>
>> I was hoping the PASEMI / NXP regressions could be solved before
>> merging.
>>
>> My p5020ds is booting fine with this series, so I'm not sure why it's
>> causing problems on Christian's machine.
>>
>> The last time I turned on my PASEMI board it tripped some breakers, so I
>> need to investigate that before I can help test that.
>>
>> I'll see how things look on Monday and either merge the commits you
>> identified or the whole series depending on if there's any more info
>> from Christian.
>
> Christian just confirmed everything up to at least
> "powerpc/dma: stop overriding dma_get_required_mask" works for his
> setups.

2018-12-07 18:34:25

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c)

git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d

Result: The PASEMI onboard ethernet works and the X5000 boots.

— Christian

Sent from my iPhone

> On 7. Dec 2018, at 14:45, Christian Zigotzky <[email protected]> wrote:
>
>> On 06 December 2018 at 11:55AM, Christian Zigotzky wrote:
>>> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
>>>
>>> Thanks. Can you try a few stepping points in the tree?
>>>
>>> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>>> (the first one) applied?
>>>
>>> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b
>>>
>>> And if that still works with commits up to
>>> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a
>>>
>> Hi Christoph,
>>
>> I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the following command:
>>
>> git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6
>>
>> Result: PASEMI onboard ethernet works again and the P5020 board boots.
>>
>> I will test the other commits in the next days.
>>
>> @All
>> It is really important, that you also test Christoph's work on your PASEMI and NXP boards. Could you please help us with solving the issues?
>>
>> 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a'
>>
>> Thanks,
>> Christian
>>
>>
> Today I tested the commit 5da11e49df21f21dac25a2491aa788307bdacb6b.
>
> git checkout 5da11e49df21f21dac25a2491aa788307bdacb6b
>
> The PASEMI onboard ethernet works and the P5020 board boots.
>
> -- Christian
>

2018-12-08 10:30:01

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove
max_direct_dma_addr)

git checkout 7ebc44c535f6bd726d553756d38b137acc718443

OK, the PASEMI onboard ethernet works and the P5020 board boots.

-- Christian


On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>
> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>
> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>
> — Christian



2018-12-08 11:45:22

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.

I completely missed your posting of V4 ! I was wondering what was
taking you so long :)

I'll give it a spin & send acks over the next 2 or 3 days.

Cheers,
Ben.

> On Wed, Nov 14, 2018 at 09:22:40AM +0100, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series switches the powerpc port to use the generic swiotlb and
> > noncoherent dma ops, and to use more generic code for the coherent
> > direct mapping, as well as removing a lot of dead code.
> >
> > As this series is very large and depends on the dma-mapping tree I've
> > also published a git tree:
> >
> > git://git.infradead.org/users/hch/misc.git powerpc-dma.4
> >
> > Gitweb:
> >
> > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
> >
> > Changes since v3:
> > - rebase on the powerpc fixes tree
> > - add a new patch to actually make the baseline amigaone config
> > configure without warnings
> > - only use ZONE_DMA for 64-bit embedded CPUs, on pseries an IOMMU is
> > always present
> > - fix compile in mem.c for one configuration
> > - drop the full npu removal for now, will be resent separately
> > - a few git bisection fixes
> >
> > The changes since v1 are to big to list and v2 was not posted in public.
> >
> > _______________________________________________
> > iommu mailing list
> > [email protected]
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> ---end quoted text---


2018-12-08 12:49:48

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, 2018-11-27 at 08:42 +0100, Christoph Hellwig wrote:
> Any comments? I'd like to at least get the ball moving on the easy
> bits.

So I had to cleanup some dust but it works on G5 with and without iommu
and 32-bit powermacs at least.

We're doing more tests, hopefully mpe can dig out some PASemi and
NXP/FSL HW as well. I'll try to review & ack the patches over the next
few days too.

Cheers,
Ben.

> On Wed, Nov 14, 2018 at 09:22:40AM +0100, Christoph Hellwig wrote:
> > Hi all,
> >
> > this series switches the powerpc port to use the generic swiotlb and
> > noncoherent dma ops, and to use more generic code for the coherent
> > direct mapping, as well as removing a lot of dead code.
> >
> > As this series is very large and depends on the dma-mapping tree I've
> > also published a git tree:
> >
> > git://git.infradead.org/users/hch/misc.git powerpc-dma.4
> >
> > Gitweb:
> >
> > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
> >
> > Changes since v3:
> > - rebase on the powerpc fixes tree
> > - add a new patch to actually make the baseline amigaone config
> > configure without warnings
> > - only use ZONE_DMA for 64-bit embedded CPUs, on pseries an IOMMU is
> > always present
> > - fix compile in mem.c for one configuration
> > - drop the full npu removal for now, will be resent separately
> > - a few git bisection fixes
> >
> > The changes since v1 are to big to list and v2 was not posted in public.
> >
> > _______________________________________________
> > iommu mailing list
> > [email protected]
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> ---end quoted text---


2018-12-08 13:48:49

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an
off-by-one in dma_capable)

git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615

The PASEMI onboard ethernet also works with this commit and the X5000
boots without any problems.

-- Christian


On 08 December 2018 at 11:29AM, Christian Zigotzky wrote:
> Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma:
> remove max_direct_dma_addr)
>
> git checkout 7ebc44c535f6bd726d553756d38b137acc718443
>
> OK, the PASEMI onboard ethernet works and the P5020 board boots.
>
> -- Christian
>
>
> On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
>> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma:
>> move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>>
>> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>>
>> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>>
>> — Christian
>
>
>


2018-12-08 17:05:48

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Just as a warning: this series now has some conflicts with the dma
mapping tree due to the ->mapping_error removal, and there might be
some bigger ones if the direct calls for the direct mapping code series
goes ahead. None of them affect the early part of the series that do
not touch the actual dma_map_ops instances, though.

2018-12-08 17:19:17

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sun, Dec 02, 2018 at 05:11:02PM +1100, Benjamin Herrenschmidt wrote:
> Talking of which ... Christoph, not sure if we can do something about
> this at the DMA API level or keep hacks but some adapters such as the
> nVidia GPUs have a HW hack we can use to work around their limitations
> in that case.
>
> They have a register that can program a fixed value for the top bits
> that they don't support.
>
> This works fine for any linear mapping with an offset, provided they
> can program the offset in that register and they have enough DMA range
> to cover all memory from that offset.
>
> I can probably get the info about this from them so we can exploit it
> in nouveau.

I think we can expose the direct mapping offset if people care enough,
we just have to be very careful designing the API. I'll happily leave
that to those that actually want to use it, but I'll gladly help
reviewing it.

2018-12-09 10:26:15

by Michael Ellerman

[permalink] [raw]
Subject: Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

Christoph Hellwig <[email protected]> writes:

> Configure the dma settings at device setup time, and stop playing games
> with get_pci_dma_ops. This prepares for using the common dma_configure
> code later on.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++---------
> 1 file changed, 11 insertions(+), 9 deletions(-)

This one's crashing, haven't dug into why yet:

[ 1.347085] Unable to handle kernel paging request for data at address 0x00000040
[ 1.391505] Faulting instruction address: 0xc0000000006b6e6c
cpu 0x0: Vector: 380 (Data SLB Access) at [c0000007fc9032d0]
pc: c0000000006b6e6c: .of_n_addr_cells+0x34/0xc0
lr: c000000000070b30: .cell_iommu_get_fixed_address+0x58/0x2b0
sp: c0000007fc903560
msr: 9000000000009032
dar: 40
current = 0xc0000007fc8d0000
paca = 0xc000000000f60000 irqmask: 0x03 irq_happened: 0x01
pid = 1, comm = swapper/0
Linux version 4.20.0-rc2-gcc7x-g1e32f48 (kerkins@p82) (gcc version 7.4.1 20181208 (Custom eb377405ab2d1900)) #1 SMP Sun Dec 9 12:16:48 AEDT 2018
enter ? for help
[c0000007fc9035f0] c000000000070b30 .cell_iommu_get_fixed_address+0x58/0x2b0
[c0000007fc9036c0] c0000000000711ac .cell_dma_dev_setup.part.1+0x24/0x118
[c0000007fc903740] c000000000071374 .cell_of_bus_notify+0x6c/0xbc
[c0000007fc9037c0] c0000000000e7ef0 .notifier_call_chain+0x90/0xf8
[c0000007fc903860] c0000000000e8c2c .blocking_notifier_call_chain+0x84/0xb8
[c0000007fc9038f0] c000000000597544 .device_add+0x584/0x7b8
[c0000007fc9039c0] c0000000005a0308 .platform_device_add+0x148/0x2f0
[c0000007fc903a60] c0000000005a1508 .platform_device_register_full+0x148/0x168
[c0000007fc903ae0] c000000000a9a8a0 .__machine_initcall_cell_cell_publish_devices+0x1bc/0x210
[c0000007fc903be0] c00000000000eca4 .do_one_initcall+0x64/0x2d8
[c0000007fc903cc0] c000000000a844ec .kernel_init_freeable+0x3dc/0x4e4
[c0000007fc903da0] c00000000000f06c .kernel_init+0x24/0x150
[c0000007fc903e20] c00000000000a9c0 .ret_from_kernel_thread+0x58/0x78

cheers

> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index 12352a58072a..cce5bf9515e5 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -657,14 +657,21 @@ static const struct dma_map_ops dma_iommu_fixed_ops = {
> .mapping_error = dma_iommu_mapping_error,
> };
>
> +static u64 cell_iommu_get_fixed_address(struct device *dev);
> +
> static void cell_dma_dev_setup(struct device *dev)
> {
> - if (get_pci_dma_ops() == &dma_iommu_ops)
> + if (get_pci_dma_ops() == &dma_iommu_ops) {
> + u64 addr = cell_iommu_get_fixed_address(dev);
> +
> + if (addr != OF_BAD_ADDR)
> + set_dma_offset(dev, addr + dma_iommu_fixed_base);
> set_iommu_table_base(dev, cell_get_iommu_table(dev));
> - else if (get_pci_dma_ops() == &dma_nommu_ops)
> + } else if (get_pci_dma_ops() == &dma_nommu_ops) {
> set_dma_offset(dev, cell_dma_nommu_offset);
> - else
> + } else {
> BUG();
> + }
> }
>
> static void cell_pci_dma_dev_setup(struct pci_dev *dev)
> @@ -950,19 +957,14 @@ static int dma_suported_and_switch(struct device *dev, u64 dma_mask)
> {
> if (dma_mask == DMA_BIT_MASK(64) &&
> cell_iommu_get_fixed_address(dev) != OF_BAD_ADDR) {
> - u64 addr = cell_iommu_get_fixed_address(dev) +
> - dma_iommu_fixed_base;
> dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
> - dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
> set_dma_ops(dev, &dma_iommu_fixed_ops);
> - set_dma_offset(dev, addr);
> return 1;
> }
>
> if (dma_iommu_dma_supported(dev, dma_mask)) {
> dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
> - set_dma_ops(dev, get_pci_dma_ops());
> - cell_dma_dev_setup(dev);
> + set_dma_ops(dev, &dma_iommu_ops);
> return 1;
> }
>
> --
> 2.19.1

2018-12-09 14:21:04

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci:
simplify fsl_pci_dma_set_mask)

git checkout 602307b034734ce77a05da4b99333a2eaf6b6482

The PASEMI onboard ethernet works and the X5000 boots.

-- Christian


On 08 December 2018 at 2:47PM, Christian Zigotzky wrote:
> Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix
> an off-by-one in dma_capable)
>
> git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615
>
> The PASEMI onboard ethernet also works with this commit and the X5000
> boots without any problems.
>
> -- Christian
>
>
> On 08 December 2018 at 11:29AM, Christian Zigotzky wrote:
>> Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma:
>> remove max_direct_dma_addr)
>>
>> git checkout 7ebc44c535f6bd726d553756d38b137acc718443
>>
>> OK, the PASEMI onboard ethernet works and the P5020 board boots.
>>
>> -- Christian
>>
>>
>> On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
>>> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma:
>>> move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>>>
>>> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>>>
>>> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>>>
>>> — Christian
>>
>>
>>
>
>


2018-12-09 18:27:58

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping,
powerpc: simplify the arch dma_set_mask override)

Result: No problems with the PASEMI onboard ethernet and with booting
the X5000 (P5020 board).

-- Christian


On 09 December 2018 at 3:20PM, Christian Zigotzky wrote:
> Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci:
> simplify fsl_pci_dma_set_mask)
>
> git checkout 602307b034734ce77a05da4b99333a2eaf6b6482
>
> The PASEMI onboard ethernet works and the X5000 boots.
>
> -- Christian
>
>
> On 08 December 2018 at 2:47PM, Christian Zigotzky wrote:
>> Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix
>> an off-by-one in dma_capable)
>>
>> git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615
>>
>> The PASEMI onboard ethernet also works with this commit and the X5000
>> boots without any problems.
>>
>> -- Christian
>>
>>
>> On 08 December 2018 at 11:29AM, Christian Zigotzky wrote:
>>> Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma:
>>> remove max_direct_dma_addr)
>>>
>>> git checkout 7ebc44c535f6bd726d553756d38b137acc718443
>>>
>>> OK, the PASEMI onboard ethernet works and the P5020 board boots.
>>>
>>> -- Christian
>>>
>>>
>>> On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
>>>> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma:
>>>> move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>>>>
>>>> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>>>>
>>>> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>>>>
>>>> — Christian
>>>
>>>
>>>
>>
>>
>
>


2018-12-10 16:52:18

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (powerpc/dma: use
phys_to_dma instead of get_dma_offset)

The P5020 board boots and the PASEMI onboard ethernet works.

-- Christian


On 09 December 2018 at 7:26PM, Christian Zigotzky wrote:
> Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping,
> powerpc: simplify the arch dma_set_mask override)
>
> Result: No problems with the PASEMI onboard ethernet and with booting
> the X5000 (P5020 board).
>
> -- Christian
>
>
> On 09 December 2018 at 3:20PM, Christian Zigotzky wrote:
>> Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci:
>> simplify fsl_pci_dma_set_mask)
>>
>> git checkout 602307b034734ce77a05da4b99333a2eaf6b6482
>>
>> The PASEMI onboard ethernet works and the X5000 boots.
>>
>> -- Christian
>>
>>
>> On 08 December 2018 at 2:47PM, Christian Zigotzky wrote:
>>> Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma:
>>> fix an off-by-one in dma_capable)
>>>
>>> git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615
>>>
>>> The PASEMI onboard ethernet also works with this commit and the
>>> X5000 boots without any problems.
>>>
>>> -- Christian
>>>
>>>
>>> On 08 December 2018 at 11:29AM, Christian Zigotzky wrote:
>>>> Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma:
>>>> remove max_direct_dma_addr)
>>>>
>>>> git checkout 7ebc44c535f6bd726d553756d38b137acc718443
>>>>
>>>> OK, the PASEMI onboard ethernet works and the P5020 board boots.
>>>>
>>>> -- Christian
>>>>
>>>>
>>>> On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
>>>>> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma:
>>>>> move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>>>>>
>>>>> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>>>>>
>>>>> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>>>>>
>>>>> — Christian
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


2018-12-10 19:08:19

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sat, 8 Dec 2018 at 17:17, Christoph Hellwig <[email protected]> wrote:
>
> On Sun, Dec 02, 2018 at 05:11:02PM +1100, Benjamin Herrenschmidt wrote:
> > Talking of which ... Christoph, not sure if we can do something about
> > this at the DMA API level or keep hacks but some adapters such as the
> > nVidia GPUs have a HW hack we can use to work around their limitations
> > in that case.
> >
> > They have a register that can program a fixed value for the top bits
> > that they don't support.
> >
> > This works fine for any linear mapping with an offset, provided they
> > can program the offset in that register and they have enough DMA range
> > to cover all memory from that offset.
> >
> > I can probably get the info about this from them so we can exploit it
> > in nouveau.
>
> I think we can expose the direct mapping offset if people care enough,
> we just have to be very careful designing the API. I'll happily leave
> that to those that actually want to use it, but I'll gladly help
> reviewing it.

Hi, Christoph and Ben,

It just came to my mind (and this is most likely a stupid question,
but still)… Is there any possibility of these changes having an
(positive) effect on the long-standing problem of Power Mac machines
with AGP graphics cards (which have to be limited to PCI transfers,
otherwise they'll hang, due to coherence issues)? If so, I have a G4
machine where I'd gladly test them.

Thanks,

Rui

2018-12-10 21:04:12

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, 2018-12-10 at 20:33 +0100, Christoph Hellwig wrote:
> On Mon, Dec 10, 2018 at 05:04:46PM +0000, Rui Salvaterra wrote:
> > Hi, Christoph and Ben,
> >
> > It just came to my mind (and this is most likely a stupid question,
> > but still)… Is there any possibility of these changes having an
> > (positive) effect on the long-standing problem of Power Mac machines
> > with AGP graphics cards (which have to be limited to PCI transfers,
> > otherwise they'll hang, due to coherence issues)? If so, I have a G4
> > machine where I'd gladly test them.
>
> These patches themselves are not going to affect that directly.
> But IFF the problem really is that the AGP needs to be treated as not
> cache coherent (I have no idea if that is true) the generic direct
> mapping code has full support for a per-device coherent flag, so
> support for a non-coherent AGP slot could be implemented relatively
> simply.

AGP is a gigantic nightmare :-) It's not just cache coherency issues
(some implementations are coherent, some aren't, Apple's is ... weird).

Apple has all sort of bugs, and Darwin source code only sheds light on
some of them. Some implementation can only read, not write I think, for
example. There are issues with transfers crossing some boundaries I
beleive, but it's all unclear.

Apple makes this work with a combination of hacks in the AGP "driver"
and the closed source GPU driver, which we don't see.

I have given up trying to make that stuff work reliably a decade ago :)

Cheers,
Ben.



2018-12-10 23:22:33

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, Dec 10, 2018 at 05:04:46PM +0000, Rui Salvaterra wrote:
> Hi, Christoph and Ben,
>
> It just came to my mind (and this is most likely a stupid question,
> but still)… Is there any possibility of these changes having an
> (positive) effect on the long-standing problem of Power Mac machines
> with AGP graphics cards (which have to be limited to PCI transfers,
> otherwise they'll hang, due to coherence issues)? If so, I have a G4
> machine where I'd gladly test them.

These patches themselves are not going to affect that directly.
But IFF the problem really is that the AGP needs to be treated as not
cache coherent (I have no idea if that is true) the generic direct
mapping code has full support for a per-device coherent flag, so
support for a non-coherent AGP slot could be implemented relatively
simply.

2018-12-10 23:29:31

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, 10 Dec 2018 at 19:33, Christoph Hellwig <[email protected]> wrote:
>
> On Mon, Dec 10, 2018 at 05:04:46PM +0000, Rui Salvaterra wrote:
> > Hi, Christoph and Ben,
> >
> > It just came to my mind (and this is most likely a stupid question,
> > but still)… Is there any possibility of these changes having an
> > (positive) effect on the long-standing problem of Power Mac machines
> > with AGP graphics cards (which have to be limited to PCI transfers,
> > otherwise they'll hang, due to coherence issues)? If so, I have a G4
> > machine where I'd gladly test them.
>
> These patches themselves are not going to affect that directly.
> But IFF the problem really is that the AGP needs to be treated as not
> cache coherent (I have no idea if that is true) the generic direct
> mapping code has full support for a per-device coherent flag, so
> support for a non-coherent AGP slot could be implemented relatively
> simply.

Thanks for the insight, Christoph. Well, the problem[1] is real, and
it's been known for a long time, though I can't be sure if it's *only*
a coherence issue. If someone who knows the hardware manages to cook
up a patch (as hacky is it may be), I'll definitely fire up old my G4
laptop to test it! :)

[1] https://bugs.freedesktop.org/show_bug.cgi?id=95017

2018-12-11 09:38:28

by Rui Salvaterra

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, 10 Dec 2018 at 20:49, Benjamin Herrenschmidt
<[email protected]> wrote:
>

[snip]

>
> AGP is a gigantic nightmare :-) It's not just cache coherency issues
> (some implementations are coherent, some aren't, Apple's is ... weird).
>
> Apple has all sort of bugs, and Darwin source code only sheds light on
> some of them. Some implementation can only read, not write I think, for
> example. There are issues with transfers crossing some boundaries I
> beleive, but it's all unclear.
>
> Apple makes this work with a combination of hacks in the AGP "driver"
> and the closed source GPU driver, which we don't see.
>
> I have given up trying to make that stuff work reliably a decade ago :)
>
> Cheers,
> Ben.

That's what I was afraid of… what a mess. At least now I have a
definitive answer from one of the original authors of the code, thanks
a lot, Ben. :)
I have an unresearched belief that AGP support was hacked in the Mac
series as an afterthought (weren't they supposed to be PCI/PCI-X
only?), and your explanation surely seems to corroborate. :/

2018-12-11 17:11:06

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 977706f9755d2d697aa6f45b4f9f0e07516efeda (powerpc/dma: remove
dma_nommu_mmap_coherent)

Result: The P5020 board boots and the PASEMI onboard ethernet works.

-- Christian


On 10 December 2018 at 4:54PM, Christian Zigotzky wrote:
> Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (powerpc/dma: use
> phys_to_dma instead of get_dma_offset)
>
> The P5020 board boots and the PASEMI onboard ethernet works.
>
> -- Christian
>
>
> On 09 December 2018 at 7:26PM, Christian Zigotzky wrote:
>> Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping,
>> powerpc: simplify the arch dma_set_mask override)
>>
>> Result: No problems with the PASEMI onboard ethernet and with booting
>> the X5000 (P5020 board).
>>
>> -- Christian
>>
>>
>> On 09 December 2018 at 3:20PM, Christian Zigotzky wrote:
>>> Next step: 602307b034734ce77a05da4b99333a2eaf6b6482
>>> (powerpc/fsl_pci: simplify fsl_pci_dma_set_mask)
>>>
>>> git checkout 602307b034734ce77a05da4b99333a2eaf6b6482
>>>
>>> The PASEMI onboard ethernet works and the X5000 boots.
>>>
>>> -- Christian
>>>
>>>
>>> On 08 December 2018 at 2:47PM, Christian Zigotzky wrote:
>>>> Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma:
>>>> fix an off-by-one in dma_capable)
>>>>
>>>> git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615
>>>>
>>>> The PASEMI onboard ethernet also works with this commit and the
>>>> X5000 boots without any problems.
>>>>
>>>> -- Christian
>>>>
>>>>
>>>> On 08 December 2018 at 11:29AM, Christian Zigotzky wrote:
>>>>> Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma:
>>>>> remove max_direct_dma_addr)
>>>>>
>>>>> git checkout 7ebc44c535f6bd726d553756d38b137acc718443
>>>>>
>>>>> OK, the PASEMI onboard ethernet works and the P5020 board boots.
>>>>>
>>>>> -- Christian
>>>>>
>>>>>
>>>>> On 07 December 2018 at 7:33PM, Christian Zigotzky wrote:
>>>>>> Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma:
>>>>>> move pci_dma_dev_setup_swiotlb to fsl_pci.c)
>>>>>>
>>>>>> git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d
>>>>>>
>>>>>> Result: The PASEMI onboard ethernet works and the P5020 board boots.
>>>>>>
>>>>>> — Christian
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


2018-12-11 18:19:55

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 7decbcfc656805603ab97206b3f816f26cd2cf7d (powerpc/dma: use
generic direct and swiotlb ops)

git checkout 7decbcfc656805603ab97206b3f816f26cd2cf7d

We have the bad commit! :-) The PASEMI onboard ethernet doesn't work
with this commit anymore.

Error messages:

[  367.627623] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627631] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627639] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0
[  367.627647] pci 0000:00:1a.0: dma_direct_map_page: overflow
0x000000026bcb5002+110 of device mask ffffffff bus mask 0

pci 0000:00:1a.0 = 00:1a.0 DMA controller: PA Semi, Inc PWRficient DMA
Controller (rev 12)

X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
kernel starts but it doesn't find any hard disks (partitions). That
means this is also the bad commit for the P5020 board.

Link to the bad commit:
http://git.infradead.org/users/hch/misc.git/commit/7decbcfc656805603ab97206b3f816f26cd2cf7d

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.5

The commit before (977706f9755d2d697aa6f45b4f9f0e07516efeda -
powerpc/dma: remove dma_nommu_mmap_coherent) works without any problems.

-- Christian



2018-12-12 00:50:19

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
> kernel starts but it doesn't find any hard disks (partitions). That
> means this is also the bad commit for the P5020 board.

What are the disks hanging off ? A PCIe device of some sort ?

Can you send good & bad dmesg logs ?

Ben.



2018-12-12 07:06:41

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4



> On 12. Dec 2018, at 01:47, Benjamin Herrenschmidt <[email protected]> wrote:
>
>> On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote:
>> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the
>> kernel starts but it doesn't find any hard disks (partitions). That
>> means this is also the bad commit for the P5020 board.
>
> What are the disks hanging off ? A PCIe device of some sort ?
>
> Can you send good & bad dmesg logs ?
>
> Ben.
>
>
Unfortunately not. It doesn’t detect any hard disk. That means the kernel ring buffer won’t save to log files. I don’t have a serial null modem cable for seeing all output. We use SATA disks. I will investigate more in this problem with rollback the files in the bad commit.

— Christian




2018-12-12 14:17:20

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Thanks for bisecting. I've spent some time going over the conversion
but can't really pinpoint it. I have three little patches that switch
parts of the code to the generic version. This is on top of the
last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda).

Can you check with whіch one things stop working?



Attachments:
(No filename) (330.00 B)
0001-get_required_mask.patch (800.00 B)
0002-swiotlb-dma_supported.patch (897.00 B)
0003-nommu-dma_supported.patch (857.00 B)
0004-alloc-free.patch (896.00 B)
Download all attachments

2018-12-12 14:38:22

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

On Sun, Dec 09, 2018 at 09:23:39PM +1100, Michael Ellerman wrote:
> Christoph Hellwig <[email protected]> writes:
>
> > Configure the dma settings at device setup time, and stop playing games
> > with get_pci_dma_ops. This prepares for using the common dma_configure
> > code later on.
> >
> > Signed-off-by: Christoph Hellwig <[email protected]>
> > ---
> > arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++---------
> > 1 file changed, 11 insertions(+), 9 deletions(-)
>
> This one's crashing, haven't dug into why yet:

Can you provide a gdb assembly of the exact crash site? This looks
like for some odd reason the DT structures aren't fully setup by the
time we are probing the device, which seems odd.

Either way, something like the patch below would ensure we call
cell_iommu_get_fixed_address from a similar context as before, can you
check if that fixes the issue?

diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 93c7e4aef571..4891b338bf9f 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -569,19 +569,12 @@ static struct iommu_table *cell_get_iommu_table(struct device *dev)
return &window->table;
}

-static u64 cell_iommu_get_fixed_address(struct device *dev);
-
static void cell_dma_dev_setup(struct device *dev)
{
- if (cell_iommu_enabled) {
- u64 addr = cell_iommu_get_fixed_address(dev);
-
- if (addr != OF_BAD_ADDR)
- set_dma_offset(dev, addr + dma_iommu_fixed_base);
+ if (cell_iommu_enabled)
set_iommu_table_base(dev, cell_get_iommu_table(dev));
- } else {
+ else
set_dma_offset(dev, cell_dma_nommu_offset);
- }
}

static void cell_pci_dma_dev_setup(struct pci_dev *dev)
@@ -865,8 +858,16 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)

static bool cell_pci_iommu_bypass_supported(struct pci_dev *pdev, u64 mask)
{
- return mask == DMA_BIT_MASK(64) &&
- cell_iommu_get_fixed_address(&pdev->dev) != OF_BAD_ADDR;
+ if (mask == DMA_BIT_MASK(64)) {
+ u64 addr = cell_iommu_get_fixed_address(&pdev->dev);
+
+ if (addr != OF_BAD_ADDR) {
+ set_dma_offset(&pdev->dev, dma_iommu_fixed_base + addr);
+ return true;
+ }
+ }
+
+ return true;
}

static void insert_16M_pte(unsigned long addr, unsigned long *ptab,

2018-12-12 14:41:19

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Thanks a lot for your reply. I will test your patches tomorrow.

Cheers,
Christian

Sent from my iPhone

> On 12. Dec 2018, at 15:15, Christoph Hellwig <[email protected]> wrote:
>
> Thanks for bisecting. I've spent some time going over the conversion
> but can't really pinpoint it. I have three little patches that switch
> parts of the code to the generic version. This is on top of the
> last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
>
> Can you check with whіch one things stop working?
>
>
> <0001-get_required_mask.patch>
> <0002-swiotlb-dma_supported.patch>
> <0003-nommu-dma_supported.patch>
> <0004-alloc-free.patch>

2018-12-13 08:44:11

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 12 December 2018 at 3:39PM, Christian Zigotzky wrote:
> Hi Christoph,
>
> Thanks a lot for your reply. I will test your patches tomorrow.
>
> Cheers,
> Christian
>
> Sent from my iPhone
>
>> On 12. Dec 2018, at 15:15, Christoph Hellwig <[email protected]> wrote:
>>
>> Thanks for bisecting. I've spent some time going over the conversion
>> but can't really pinpoint it. I have three little patches that switch
>> parts of the code to the generic version. This is on top of the
>> last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
>>
>> Can you check with whіch one things stop working?
>>
>>
>> <0001-get_required_mask.patch>
>> <0002-swiotlb-dma_supported.patch>
>> <0003-nommu-dma_supported.patch>
>> <0004-alloc-free.patch>

Today I tried the first patch (0001-get_required_mask.patch) with the
last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
Unfortunately this patch is already included in the last good commit
(977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch.

-- Christian



2018-12-13 09:11:25

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
> Today I tried the first patch (0001-get_required_mask.patch) with the last
> good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
> patch is already included in the last good commit
> (977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch.

Hmm, I don't think this is the case. This is my local git log output:

commit 83a4b87de6bc6a75b500c9959de88e2157fbcd7c
Author: Christoph Hellwig <[email protected]>
Date: Wed Dec 12 15:07:49 2018 +0100

get_required_mask

commit 977706f9755d2d697aa6f45b4f9f0e07516efeda
Author: Christoph Hellwig <[email protected]>
Date: Sat Nov 10 22:34:27 2018 +0100

powerpc/dma: remove dma_nommu_mmap_coherent

I've also pushed a git branch with these out to:

git://git.infradead.org/users/hch/misc.git powerpc-dma.5-debug

2018-12-13 09:50:00

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 13 December 2018 at 10:10AM, Christoph Hellwig wrote:
> On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
>> Today I tried the first patch (0001-get_required_mask.patch) with the last
>> good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
>> patch is already included in the last good commit
>> (977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch.
> Hmm, I don't think this is the case. This is my local git log output:
>
> commit 83a4b87de6bc6a75b500c9959de88e2157fbcd7c
> Author: Christoph Hellwig <[email protected]>
> Date: Wed Dec 12 15:07:49 2018 +0100
>
> get_required_mask
>
> commit 977706f9755d2d697aa6f45b4f9f0e07516efeda
> Author: Christoph Hellwig <[email protected]>
> Date: Sat Nov 10 22:34:27 2018 +0100
>
> powerpc/dma: remove dma_nommu_mmap_coherent
>
> I've also pushed a git branch with these out to:
>
> git://git.infradead.org/users/hch/misc.git powerpc-dma.5-debug
>
Sorry Christioph. I was wrong. The first patch isn't included in the
last good commit. I will try it again. I can only test beside my main
work. That means it takes longer.

-- Christian


2018-12-13 11:20:40

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 13 December 2018 at 10:47AM, Christian Zigotzky wrote:
> On 13 December 2018 at 10:10AM, Christoph Hellwig wrote:
>> On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
>>> Today I tried the first patch (0001-get_required_mask.patch) with
>>> the last
>>> good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
>>> Unfortunately this
>>> patch is already included in the last good commit
>>> (977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch.
>> Hmm, I don't think this is the case.  This is my local git log output:
>>
>> commit 83a4b87de6bc6a75b500c9959de88e2157fbcd7c
>> Author: Christoph Hellwig <[email protected]>
>> Date:   Wed Dec 12 15:07:49 2018 +0100
>>
>>      get_required_mask
>>
>> commit 977706f9755d2d697aa6f45b4f9f0e07516efeda
>> Author: Christoph Hellwig <[email protected]>
>> Date:   Sat Nov 10 22:34:27 2018 +0100
>>
>>      powerpc/dma: remove dma_nommu_mmap_coherent
>>
>> I've also pushed a git branch with these out to:
>>
>>      git://git.infradead.org/users/hch/misc.git powerpc-dma.5-debug
>>
> Sorry Christioph. I was wrong. The first patch isn't included in the
> last good commit. I will try it again. I can only test beside my main
> work. That means it takes longer.
>
> -- Christian
>
>
I tried it again but I get the following error message:

MODPOST vmlinux.o
arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
(.text+0x274): undefined reference to `.dma_direct_get_required_mask'
make: *** [vmlinux] Error 1


2018-12-13 11:27:23

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
> I tried it again but I get the following error message:
>
> MODPOST vmlinux.o
> arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
> make: *** [vmlinux] Error 1

Sorry, you need this one liner before all the patches posted last time:

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d8819e3a1eb1..7e78c2798f2f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -154,6 +154,7 @@ config PPC
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
select DYNAMIC_FTRACE if FUNCTION_TRACER
+ select DMA_DIRECT_OPS
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32

2018-12-13 13:36:17

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
> On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
>> I tried it again but I get the following error message:
>>
>> MODPOST vmlinux.o
>> arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
>> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
>> make: *** [vmlinux] Error 1
> Sorry, you need this one liner before all the patches posted last time:
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d8819e3a1eb1..7e78c2798f2f 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -154,6 +154,7 @@ config PPC
> select CLONE_BACKWARDS
> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> select DYNAMIC_FTRACE if FUNCTION_TRACER
> + select DMA_DIRECT_OPS
> select EDAC_ATOMIC_SCRUB
> select EDAC_SUPPORT
> select GENERIC_ATOMIC64 if PPC32
>
Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020
board) boots with the patch '0001-get_required_mask.patch'.

-- Christian


2018-12-13 17:58:09

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
> On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
>> On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
>>> I tried it again but I get the following error message:
>>>
>>> MODPOST vmlinux.o
>>> arch/powerpc/kernel/dma-iommu.o: In function
>>> `.dma_iommu_get_required_mask':
>>> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
>>> make: *** [vmlinux] Error 1
>> Sorry, you need this one liner before all the patches posted last time:
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index d8819e3a1eb1..7e78c2798f2f 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -154,6 +154,7 @@ config PPC
>>       select CLONE_BACKWARDS
>>       select DCACHE_WORD_ACCESS        if PPC64 && CPU_LITTLE_ENDIAN
>>       select DYNAMIC_FTRACE            if FUNCTION_TRACER
>> +    select DMA_DIRECT_OPS
>>       select EDAC_ATOMIC_SCRUB
>>       select EDAC_SUPPORT
>>       select GENERIC_ATOMIC64            if PPC32
>>
> Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020
> board) boots with the patch '0001-get_required_mask.patch'.
>
> -- Christian
>
>
Next patch: '0002-swiotlb-dma_supported.patch' for the last good commit
(977706f9755d2d697aa6f45b4f9f0e07516efeda).

The PASEMI onboard ethernet works and the X5000 (P5020 board) boots.

-- Christian


2018-12-13 21:55:27

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 13 December 2018 at 6:48PM, Christian Zigotzky wrote:
> On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
>> On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
>>> On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
>>>> I tried it again but I get the following error message:
>>>>
>>>> MODPOST vmlinux.o
>>>> arch/powerpc/kernel/dma-iommu.o: In function
>>>> `.dma_iommu_get_required_mask':
>>>> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
>>>> make: *** [vmlinux] Error 1
>>> Sorry, you need this one liner before all the patches posted last time:
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index d8819e3a1eb1..7e78c2798f2f 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -154,6 +154,7 @@ config PPC
>>>       select CLONE_BACKWARDS
>>>       select DCACHE_WORD_ACCESS        if PPC64 && CPU_LITTLE_ENDIAN
>>>       select DYNAMIC_FTRACE            if FUNCTION_TRACER
>>> +    select DMA_DIRECT_OPS
>>>       select EDAC_ATOMIC_SCRUB
>>>       select EDAC_SUPPORT
>>>       select GENERIC_ATOMIC64            if PPC32
>>>
>> Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020
>> board) boots with the patch '0001-get_required_mask.patch'.
>>
>> -- Christian
>>
>>
> Next patch: '0002-swiotlb-dma_supported.patch' for the last good
> commit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
>
> The PASEMI onboard ethernet works and the X5000 (P5020 board) boots.
>
> -- Christian
>
>
Next patch: '0003-nommu-dma_supported.patch'

No problems with the PASEMI onboard ethernet and the P5020 board boots.

-- Christian


2018-12-14 12:01:38

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 12 December 2018 at 3:15PM, Christoph Hellwig wrote:
> Thanks for bisecting.  I've spent some time going over the conversion
> but can't really pinpoint it.  I have three little patches that switch
> parts of the code to the generic version.  This is on top of the
> last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
>
> Can you check with whіch one things stop working?

Hello Christoph,

Great news! All your patches work!

I tested all your patches (including the patch '0004-alloc-free.patch'
today) and the PASEMI onboard ethernet works and the P5020 board boots
without any problems. Thank you for your work!
I have a few days off. That means, I will work less and only for the
A-EON first level Linux support. I can test again on Thursday next week.

Have a nice weekend!

Cheers,
Christian

2018-12-14 13:31:10

by Michael Ellerman

[permalink] [raw]
Subject: Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

Christoph Hellwig <[email protected]> writes:
> On Sun, Dec 09, 2018 at 09:23:39PM +1100, Michael Ellerman wrote:
>> Christoph Hellwig <[email protected]> writes:
>>
>> > Configure the dma settings at device setup time, and stop playing games
>> > with get_pci_dma_ops. This prepares for using the common dma_configure
>> > code later on.
>> >
>> > Signed-off-by: Christoph Hellwig <[email protected]>
>> > ---
>> > arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++---------
>> > 1 file changed, 11 insertions(+), 9 deletions(-)
>>
>> This one's crashing, haven't dug into why yet:
>
> Can you provide a gdb assembly of the exact crash site? This looks
> like for some odd reason the DT structures aren't fully setup by the
> time we are probing the device, which seems odd.

It's dev->of_node which is NULL.

Because we were passed a platform_device which doesn't have an of_node.

It's the cbe-mic device created in cell_publish_devices().

I can fix that by simply checking for a NULL node, then the system boots
but then I have no network devices, due to:

tg3 0000:00:01.0: enabling device (0140 -> 0142)
tg3 0000:00:01.0: DMA engine test failed, aborting
tg3: probe of 0000:00:01.0 failed with error -12
tg3 0000:00:01.1: enabling device (0140 -> 0142)
tg3 0000:00:01.1: DMA engine test failed, aborting
tg3: probe of 0000:00:01.1 failed with error -12


I think the problem is that we don't want to set iommu_bypass_supported
unless cell_iommu_fixed_mapping_init() succeeds.

Yep. This makes it work for me on cell on top of your v5.

cheers


diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 348a815779c1..8329fda17cc8 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -813,6 +813,10 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)
int i, len, best, naddr, nsize, pna, range_size;

np = of_node_get(dev->of_node);
+ if (!np)
+ /* We can be called for platform devices that have no of_node */
+ goto out;
+
while (1) {
naddr = of_n_addr_cells(np);
nsize = of_n_size_cells(np);
@@ -1065,8 +1069,11 @@ static int __init cell_iommu_init(void)
/* Setup various callbacks */
cell_pci_controller_ops.dma_dev_setup = cell_pci_dma_dev_setup;

- if (!iommu_fixed_disabled && cell_iommu_fixed_mapping_init() == 0)
+ if (!iommu_fixed_disabled && cell_iommu_fixed_mapping_init() == 0) {
+ cell_pci_controller_ops.iommu_bypass_supported =
+ cell_pci_iommu_bypass_supported;
goto done;
+ }

/* Create an iommu for each /axon node. */
for_each_node_by_name(np, "axon") {
@@ -1085,10 +1092,6 @@ static int __init cell_iommu_init(void)
}
done:
/* Setup default PCI iommu ops */
- if (!iommu_fixed_disabled) {
- cell_pci_controller_ops.iommu_bypass_supported =
- cell_pci_iommu_bypass_supported;
- }
set_pci_dma_ops(&dma_iommu_ops);
cell_iommu_enabled = true;
bail:

2018-12-14 16:44:02

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

On Sat, Dec 15, 2018 at 12:29:11AM +1100, Michael Ellerman wrote:
> I think the problem is that we don't want to set iommu_bypass_supported
> unless cell_iommu_fixed_mapping_init() succeeds.
>
> Yep. This makes it work for me on cell on top of your v5.

Thanks, this looks good. I've folded it with the slight change of moving
the iommu_bypass_supported setup into cell_iommu_fixed_mapping_init.

2018-12-14 16:47:00

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Dec 14, 2018 at 01:00:26PM +0100, Christian Zigotzky wrote:
> On 12 December 2018 at 3:15PM, Christoph Hellwig wrote:
> > Thanks for bisecting.  I've spent some time going over the conversion
> > but can't really pinpoint it.  I have three little patches that switch
> > parts of the code to the generic version.  This is on top of the
> > last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda).
> >
> > Can you check with whіch one things stop working?
>
> Hello Christoph,
>
> Great news! All your patches work!

No so great because that means I still have no idea what broke..

> I tested all your patches (including the patch '0004-alloc-free.patch'
> today) and the PASEMI onboard ethernet works and the P5020 board boots
> without any problems. Thank you for your work!
> I have a few days off. That means, I will work less and only for the A-EON
> first level Linux support. I can test again on Thursday next week.

Enjoy your days off!

I think I'll need to prepare something new that is better bisectable,
and use that opportunity to reason about the changes a little more.

2018-12-16 17:16:12

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

FYI, given that we are one week before the expected 4.20 release
date and I haven't found the bug plaging Christians setups I think
we need to defer most of this to the next merge window.

I'd still like to get a few bits in earlier, which I will send out
separately now.

2018-12-17 01:16:00

by Michael Ellerman

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Christoph Hellwig <[email protected]> writes:

> FYI, given that we are one week before the expected 4.20 release
> date and I haven't found the bug plaging Christians setups I think
> we need to defer most of this to the next merge window.

OK, sorry I couldn't help. I tried powering up my pasemi board last week
but it just gives me a couple of status leds and nothing else, the fan
never spins up.

> I'd still like to get a few bits in earlier, which I will send out
> separately now.

OK.

cheers

2019-01-03 09:53:31

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christian,

happy new year and I hope you had a few restful deays off.

I've pushed a new tree to:

git://git.infradead.org/users/hch/misc.git powerpc-dma.6

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

Which has been rebased to the latests Linus tree, which has a lot of
changes, and has also changed the patch split a bit to aid bisection.

I think

http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f

might be a good commit to re-start testing, then bisecting up to the
last commit using git bisect.

2019-01-03 23:57:58

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Happy new year for you too. Unfortunately we have some problems with the latest DRM patches. They modified a lot and some graphics cards don’t work anymore. During the holidays we tried to figure out where the problems are but without any success.

I will try to test your patches next week.

Cheers,
Christian

Sent from my iPhone

> On 3. Jan 2019, at 08:36, Christoph Hellwig <[email protected]> wrote:
>
> Hi Christian,
>
> happy new year and I hope you had a few restful deays off.
>
> I've pushed a new tree to:
>
> git://git.infradead.org/users/hch/misc.git powerpc-dma.6
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> Which has been rebased to the latests Linus tree, which has a lot of
> changes, and has also changed the patch split a bit to aid bisection.
>
> I think
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f
>
> might be a good commit to re-start testing, then bisecting up to the
> last commit using git bisect.

2019-01-05 16:05:41

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove
dma_nommu_mmap_coherent)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout c446404b041130fbd9d1772d184f24715cf2362f

Output:

Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent

-----

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots.

-- Christian

2019-01-09 09:34:37

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove
dma_nommu_get_required_mask)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout a64e18ba191ba9102fb174f27d707485ffd9389c

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
boots. I also successfully tested sound, hardware 3D acceleration,
Bluetooth, network, booting with a label etc. The uImages work also in a
virtual e5500 quad-core QEMU machine.

-- Christian


On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
> remove dma_nommu_mmap_coherent)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>
> Output:
>
> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again.
> Example:
>
>   git checkout -b <new-branch-name>
>
> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent
>
> -----
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots.
>
> -- Christian
>


2019-01-11 04:27:24

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove
dma_nommu_dma_supported)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02

Output:

Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b <new-branch-name>

HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported

---

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
boots. I also successfully tested sound, hardware 3D acceleration,
Bluetooth, network, booting with a label etc. The uImages work also in a
virtual e5500 quad-core QEMU machine.

-- Christian


On 09 January 2019 at 10:31AM, Christian Zigotzky wrote:
> Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma:
> remove dma_nommu_get_required_mask)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
> boots. I also successfully tested sound, hardware 3D acceleration,
> Bluetooth, network, booting with a label etc. The uImages work also in
> a virtual e5500 quad-core QEMU machine.
>
> -- Christian
>
>
> On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
>> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
>> remove dma_nommu_mmap_coherent)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>>
>> Output:
>>
>> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in
>> this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again.
>> Example:
>>
>>   git checkout -b <new-branch-name>
>>
>> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent
>>
>> -----
>>
>> Link to the Git:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots.
>>
>> -- Christian
>>
>
>


2019-01-12 18:53:09

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove
swiotlb_dma_supported)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39

Output:

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported

----

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020
board) boots. I also successfully tested sound, hardware 3D
acceleration, Bluetooth, network, booting with a label etc. The uImages
work also in a virtual e5500 quad-core QEMU machine.

-- Christian


On 11 January 2019 at 03:10AM, Christian Zigotzky wrote:
> Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma:
> remove dma_nommu_dma_supported)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
>
> Output:
>
> Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again.
> Example:
>
> git checkout -b <new-branch-name>
>
> HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported
>
> ---
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
> boots. I also successfully tested sound, hardware 3D acceleration,
> Bluetooth, network, booting with a label etc. The uImages work also in
> a virtual e5500 quad-core QEMU machine.
>
> -- Christian
>
>
> On 09 January 2019 at 10:31AM, Christian Zigotzky wrote:
>> Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma:
>> remove dma_nommu_get_required_mask)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
>>
>> Link to the Git:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>> boots. I also successfully tested sound, hardware 3D acceleration,
>> Bluetooth, network, booting with a label etc. The uImages work also
>> in a virtual e5500 quad-core QEMU machine.
>>
>> -- Christian
>>
>>
>> On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
>>> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
>>> remove dma_nommu_mmap_coherent)
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>>>
>>> Output:
>>>
>>> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>>>
>>> You are in 'detached HEAD' state. You can look around, make
>>> experimental
>>> changes and commit them, and you can discard any commits you make in
>>> this
>>> state without impacting any branches by performing another checkout.
>>>
>>> If you want to create a new branch to retain commits you create, you
>>> may
>>> do so (now or later) by using -b with the checkout command again.
>>> Example:
>>>
>>>   git checkout -b <new-branch-name>
>>>
>>> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent
>>>
>>> -----
>>>
>>> Link to the Git:
>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>
>>> Result: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>> boots.
>>>
>>> -- Christian
>>>
>>
>>
>
>


2019-01-15 08:27:46

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
the dma-direct allocator for coherent platforms)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage

Error message:

arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to
`__dma_nommu_alloc_coherent'
arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to
`__dma_nommu_free_coherent'
Makefile:1027: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

-- Christian


On 12 January 2019 at 7:14PM, Christian Zigotzky wrote:
> Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove
> swiotlb_dma_supported)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39
>
> Output:
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again.
> Example:
>
>   git checkout -b <new-branch-name>
>
> HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported
>
> ----
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020
> board) boots. I also successfully tested sound, hardware 3D
> acceleration, Bluetooth, network, booting with a label etc. The
> uImages work also in a virtual e5500 quad-core QEMU machine.
>
> -- Christian
>
>
> On 11 January 2019 at 03:10AM, Christian Zigotzky wrote:
>> Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma:
>> remove dma_nommu_dma_supported)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
>>
>> Output:
>>
>> Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in
>> this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again.
>> Example:
>>
>> git checkout -b <new-branch-name>
>>
>> HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported
>>
>> ---
>>
>> Link to the Git:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>> boots. I also successfully tested sound, hardware 3D acceleration,
>> Bluetooth, network, booting with a label etc. The uImages work also
>> in a virtual e5500 quad-core QEMU machine.
>>
>> -- Christian
>>
>>
>> On 09 January 2019 at 10:31AM, Christian Zigotzky wrote:
>>> Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma:
>>> remove dma_nommu_get_required_mask)
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
>>>
>>> Link to the Git:
>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>
>>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>> boots. I also successfully tested sound, hardware 3D acceleration,
>>> Bluetooth, network, booting with a label etc. The uImages work also
>>> in a virtual e5500 quad-core QEMU machine.
>>>
>>> -- Christian
>>>
>>>
>>> On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
>>>> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
>>>> remove dma_nommu_mmap_coherent)
>>>>
>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>> powerpc-dma.6 a
>>>>
>>>> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>>>>
>>>> Output:
>>>>
>>>> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>>>>
>>>> You are in 'detached HEAD' state. You can look around, make
>>>> experimental
>>>> changes and commit them, and you can discard any commits you make
>>>> in this
>>>> state without impacting any branches by performing another checkout.
>>>>
>>>> If you want to create a new branch to retain commits you create,
>>>> you may
>>>> do so (now or later) by using -b with the checkout command again.
>>>> Example:
>>>>
>>>>   git checkout -b <new-branch-name>
>>>>
>>>> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent
>>>>
>>>> -----
>>>>
>>>> Link to the Git:
>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>
>>>> Result: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>> boots.
>>>>
>>>> -- Christian
>>>>
>>>
>>>
>>
>>
>
>


2019-01-15 09:06:35

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use
the dma_direct mapping routines)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f

Error message:

arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to
`__dma_nommu_alloc_coherent'
arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to
`__dma_nommu_free_coherent'
Makefile:1027: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

-- Christian


On 15 January 2019 at 09:07AM, Christian Zigotzky wrote:
> Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
> the dma-direct allocator for coherent platforms)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage
>
> Error message:
>
> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to
> `__dma_nommu_alloc_coherent'
> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to
> `__dma_nommu_free_coherent'
> Makefile:1027: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
>
> -- Christian
>
>
> On 12 January 2019 at 7:14PM, Christian Zigotzky wrote:
>> Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove
>> swiotlb_dma_supported)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39
>>
>> Output:
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in
>> this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again.
>> Example:
>>
>>   git checkout -b <new-branch-name>
>>
>> HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported
>>
>> ----
>>
>> Link to the Git:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020
>> board) boots. I also successfully tested sound, hardware 3D
>> acceleration, Bluetooth, network, booting with a label etc. The
>> uImages work also in a virtual e5500 quad-core QEMU machine.
>>
>> -- Christian
>>
>>
>> On 11 January 2019 at 03:10AM, Christian Zigotzky wrote:
>>> Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma:
>>> remove dma_nommu_dma_supported)
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
>>>
>>> Output:
>>>
>>> Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'.
>>>
>>> You are in 'detached HEAD' state. You can look around, make
>>> experimental
>>> changes and commit them, and you can discard any commits you make in
>>> this
>>> state without impacting any branches by performing another checkout.
>>>
>>> If you want to create a new branch to retain commits you create, you
>>> may
>>> do so (now or later) by using -b with the checkout command again.
>>> Example:
>>>
>>> git checkout -b <new-branch-name>
>>>
>>> HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported
>>>
>>> ---
>>>
>>> Link to the Git:
>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>
>>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>> boots. I also successfully tested sound, hardware 3D acceleration,
>>> Bluetooth, network, booting with a label etc. The uImages work also
>>> in a virtual e5500 quad-core QEMU machine.
>>>
>>> -- Christian
>>>
>>>
>>> On 09 January 2019 at 10:31AM, Christian Zigotzky wrote:
>>>> Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma:
>>>> remove dma_nommu_get_required_mask)
>>>>
>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>> powerpc-dma.6 a
>>>>
>>>> git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
>>>>
>>>> Link to the Git:
>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>
>>>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>> boots. I also successfully tested sound, hardware 3D acceleration,
>>>> Bluetooth, network, booting with a label etc. The uImages work also
>>>> in a virtual e5500 quad-core QEMU machine.
>>>>
>>>> -- Christian
>>>>
>>>>
>>>> On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
>>>>> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
>>>>> remove dma_nommu_mmap_coherent)
>>>>>
>>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>>> powerpc-dma.6 a
>>>>>
>>>>> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>>>>>
>>>>> Output:
>>>>>
>>>>> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>>>>>
>>>>> You are in 'detached HEAD' state. You can look around, make
>>>>> experimental
>>>>> changes and commit them, and you can discard any commits you make
>>>>> in this
>>>>> state without impacting any branches by performing another checkout.
>>>>>
>>>>> If you want to create a new branch to retain commits you create,
>>>>> you may
>>>>> do so (now or later) by using -b with the checkout command again.
>>>>> Example:
>>>>>
>>>>>   git checkout -b <new-branch-name>
>>>>>
>>>>> HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent
>>>>>
>>>>> -----
>>>>>
>>>>> Link to the Git:
>>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>>
>>>>> Result: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>>> boots.
>>>>>
>>>>> -- Christian
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


2019-01-15 12:34:41

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step: 21074ef03c0816ae158721a78cabe9035938dddd (powerpc/dma: use
the generic direct mapping bypass)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 21074ef03c0816ae158721a78cabe9035938dddd

I was able to compile the kernel for the AmigaOne X1000 (Nemo board with
PA Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet
doesn't work.

dmesg:

[   12.698063] pasemi_mac 0000:00:14.3 enp0s20f3: renamed from eth0
[   16.516966] IPv6: ADDRCONF(NETDEV_UP): enp0s20f3: link is not ready
[   16.521025] pci 0000:00:1a.0: overflow 0x000000026a587802+1646 of DMA
mask ffffffff bus mask 0
[   16.521047] WARNING: CPU: 0 PID: 2318 at kernel/dma/direct.c:43
.dma_direct_map_page+0x11c/0x200
[   16.521049] Modules linked in:
[   16.521056] CPU: 0 PID: 2318 Comm: NetworkManager Not tainted
5.0.0-rc2-2_A-EON_AmigaOne_X1000_Nemo-54576-g21074ef-dirty #1
[   16.521059] NIP:  c00000000010395c LR: c000000000103a30 CTR:
0000000000000000
[   16.521062] REGS: c00000026a1a29a0 TRAP: 0700   Not tainted
(5.0.0-rc2-2_A-EON_AmigaOne_X1000_Nemo-54576-g21074ef-dirty)
[   16.521064] MSR:  900000000202b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI>  CR:
22002442  XER: 20000000
[   16.521074] IRQMASK: 0
               GPR00: c000000000103a30 c00000026a1a2c30
c000000001923f00 0000000000000052
               GPR04: c00000026f206778 c00000026f20d458
c000000001ab1178 7063693a30303030
               GPR08: 0000000000000007 0000000000000000
0000000000000000 0000000000000010
               GPR12: 3a30303a31612e30 c000000001b10000
0000000000a79020 0000000000ace140
               GPR16: 00000000fffdd958 0000000000000000
0000000000000000 c00000026be92220
               GPR20: 0000000000000000 c00000026a470000
0000000000000000 0000000000000000
               GPR24: 0000000000000800 c00000026a1c0000
c00000026bc69280 c00000026a1c0000
               GPR28: c000000277b1f588 000000000000066e
c00000026d3c68b0 0000000000000802
[   16.521111] NIP [c00000000010395c] .dma_direct_map_page+0x11c/0x200
[   16.521114] LR [c000000000103a30] .dma_direct_map_page+0x1f0/0x200
[   16.521116] Call Trace:
[   16.521120] [c00000026a1a2c30] [c000000000103a30]
.dma_direct_map_page+0x1f0/0x200 (unreliable)
[   16.521126] [c00000026a1a2cd0] [c00000000099b84c]
.pasemi_mac_replenish_rx_ring+0x12c/0x2a0
[   16.521131] [c00000026a1a2da0] [c00000000099dcc4]
.pasemi_mac_open+0x384/0x7c0
[   16.521137] [c00000026a1a2e40] [c000000000c6f4e4] .__dev_open+0x134/0x1e0
[   16.521142] [c00000026a1a2ee0] [c000000000c6fa4c]
.__dev_change_flags+0x1bc/0x210
[   16.521147] [c00000026a1a2f90] [c000000000c6fae8]
.dev_change_flags+0x48/0xa0
[   16.521153] [c00000026a1a3030] [c000000000c8c8ec] .do_setlink+0x3dc/0xf60
[   16.521158] [c00000026a1a31b0] [c000000000c8dde4]
.__rtnl_newlink+0x5e4/0x900
[   16.521163] [c00000026a1a35f0] [c000000000c8e16c] .rtnl_newlink+0x6c/0xb0
[   16.521167] [c00000026a1a3680] [c000000000c89898]
.rtnetlink_rcv_msg+0x2e8/0x3d0
[   16.521172] [c00000026a1a3760] [c000000000cc0ff0]
.netlink_rcv_skb+0x120/0x170
[   16.521177] [c00000026a1a3820] [c000000000c87378]
.rtnetlink_rcv+0x28/0x40
[   16.521181] [c00000026a1a38a0] [c000000000cc0458]
.netlink_unicast+0x208/0x2f0
[   16.521186] [c00000026a1a3950] [c000000000cc0a08]
.netlink_sendmsg+0x348/0x460
[   16.521190] [c00000026a1a3a30] [c000000000c387d4] .sock_sendmsg+0x44/0x70
[   16.521195] [c00000026a1a3ab0] [c000000000c3a7fc]
.___sys_sendmsg+0x30c/0x320
[   16.521199] [c00000026a1a3ca0] [c000000000c3c414]
.__sys_sendmsg+0x74/0xf0
[   16.521204] [c00000026a1a3d90] [c000000000cb4e00]
.__se_compat_sys_sendmsg+0x40/0x60
[   16.521210] [c00000026a1a3e20] [c00000000000a21c] system_call+0x5c/0x70
[   16.521212] Instruction dump:
[   16.521215] 60000000 f8610070 3d20ffff 6129fffe 79290020 e8e70000
7fa74840 409d00b8
[   16.521222] 3d420001 892acb59 2f890000 419e00b8 <0fe00000> 382100a0
3860ffff e8010010
[   16.521231] ---[ end trace 2129e4121bbdd0e9 ]---

I wasn't able to compile it for the AmigaOne X5000 (Cyrus+ board with
Qoriq P5020 SoC). Error message:

CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CC      arch/powerpc/sysdev/fsl_pci.o
arch/powerpc/sysdev/fsl_pci.c: In function 'fsl_pci_dma_set_mask':
arch/powerpc/sysdev/fsl_pci.c:142:21: error: 'dma_nommu_ops' undeclared
(first use in this function)
   set_dma_ops(dev, &dma_nommu_ops);
                     ^
arch/powerpc/sysdev/fsl_pci.c:142:21: note: each undeclared identifier
is reported only once for each function it appears in
scripts/Makefile.build:276: recipe for target
'arch/powerpc/sysdev/fsl_pci.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_pci.o] Error 1
scripts/Makefile.build:492: recipe for target 'arch/powerpc/sysdev' failed
make[1]: *** [arch/powerpc/sysdev] Error 2
Makefile:1049: recipe for target 'arch/powerpc' failed
make: *** [arch/powerpc] Error 2

-- Christian


On 15 January 2019 at 09:49AM, Christian Zigotzky wrote:
> Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use
> the dma_direct mapping routines)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f
>
> Error message:
>
> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to
> `__dma_nommu_alloc_coherent'
> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to
> `__dma_nommu_free_coherent'
> Makefile:1027: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
>
> -- Christian
>
>
> On 15 January 2019 at 09:07AM, Christian Zigotzky wrote:
>> Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
>> the dma-direct allocator for coherent platforms)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
>>
>> Link to the Git:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage
>>
>> Error message:
>>
>> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to
>> `__dma_nommu_alloc_coherent'
>> arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to
>> `__dma_nommu_free_coherent'
>> Makefile:1027: recipe for target 'vmlinux' failed
>> make: *** [vmlinux] Error 1
>>
>> -- Christian
>>
>>
>> On 12 January 2019 at 7:14PM, Christian Zigotzky wrote:
>>> Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove
>>> swiotlb_dma_supported)
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39
>>>
>>> Output:
>>>
>>> You are in 'detached HEAD' state. You can look around, make
>>> experimental
>>> changes and commit them, and you can discard any commits you make in
>>> this
>>> state without impacting any branches by performing another checkout.
>>>
>>> If you want to create a new branch to retain commits you create, you
>>> may
>>> do so (now or later) by using -b with the checkout command again.
>>> Example:
>>>
>>>   git checkout -b <new-branch-name>
>>>
>>> HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported
>>>
>>> ----
>>>
>>> Link to the Git:
>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>
>>> Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020
>>> board) boots. I also successfully tested sound, hardware 3D
>>> acceleration, Bluetooth, network, booting with a label etc. The
>>> uImages work also in a virtual e5500 quad-core QEMU machine.
>>>
>>> -- Christian
>>>
>>>
>>> On 11 January 2019 at 03:10AM, Christian Zigotzky wrote:
>>>> Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma:
>>>> remove dma_nommu_dma_supported)
>>>>
>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>> powerpc-dma.6 a
>>>>
>>>> git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
>>>>
>>>> Output:
>>>>
>>>> Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'.
>>>>
>>>> You are in 'detached HEAD' state. You can look around, make
>>>> experimental
>>>> changes and commit them, and you can discard any commits you make
>>>> in this
>>>> state without impacting any branches by performing another checkout.
>>>>
>>>> If you want to create a new branch to retain commits you create,
>>>> you may
>>>> do so (now or later) by using -b with the checkout command again.
>>>> Example:
>>>>
>>>> git checkout -b <new-branch-name>
>>>>
>>>> HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported
>>>>
>>>> ---
>>>>
>>>> Link to the Git:
>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>
>>>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>> boots. I also successfully tested sound, hardware 3D acceleration,
>>>> Bluetooth, network, booting with a label etc. The uImages work also
>>>> in a virtual e5500 quad-core QEMU machine.
>>>>
>>>> -- Christian
>>>>
>>>>
>>>> On 09 January 2019 at 10:31AM, Christian Zigotzky wrote:
>>>>> Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma:
>>>>> remove dma_nommu_get_required_mask)
>>>>>
>>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>>> powerpc-dma.6 a
>>>>>
>>>>> git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
>>>>>
>>>>> Link to the Git:
>>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>>
>>>>> Results: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>>> boots. I also successfully tested sound, hardware 3D acceleration,
>>>>> Bluetooth, network, booting with a label etc. The uImages work
>>>>> also in a virtual e5500 quad-core QEMU machine.
>>>>>
>>>>> -- Christian
>>>>>
>>>>>
>>>>> On 05 January 2019 at 5:03PM, Christian Zigotzky wrote:
>>>>>> Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma:
>>>>>> remove dma_nommu_mmap_coherent)
>>>>>>
>>>>>> git clone git://git.infradead.org/users/hch/misc.git -b
>>>>>> powerpc-dma.6 a
>>>>>>
>>>>>> git checkout c446404b041130fbd9d1772d184f24715cf2362f
>>>>>>
>>>>>> Output:
>>>>>>
>>>>>> Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'.
>>>>>>
>>>>>> You are in 'detached HEAD' state. You can look around, make
>>>>>> experimental
>>>>>> changes and commit them, and you can discard any commits you make
>>>>>> in this
>>>>>> state without impacting any branches by performing another checkout.
>>>>>>
>>>>>> If you want to create a new branch to retain commits you create,
>>>>>> you may
>>>>>> do so (now or later) by using -b with the checkout command again.
>>>>>> Example:
>>>>>>
>>>>>>   git checkout -b <new-branch-name>
>>>>>>
>>>>>> HEAD is now at c446404... powerpc/dma: remove
>>>>>> dma_nommu_mmap_coherent
>>>>>>
>>>>>> -----
>>>>>>
>>>>>> Link to the Git:
>>>>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>>>>
>>>>>> Result: PASEMI onboard ethernet works and the X5000 (P5020 board)
>>>>>> boots.
>>>>>>
>>>>>> -- Christian
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


2019-01-15 14:00:24

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
> Next step: 21074ef03c0816ae158721a78cabe9035938dddd (powerpc/dma: use the
> generic direct mapping bypass)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 21074ef03c0816ae158721a78cabe9035938dddd
>
> I was able to compile the kernel for the AmigaOne X1000 (Nemo board with PA
> Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet doesn't
> work.

Thanks. But we are exactly missing the steps that are relevant. I've
pushed a fixed up powerpc-dma.6 tree, which will only change starting from
the first commit that didn't link.

The first commit that changed from the old one is this one:

http://git.infradead.org/users/hch/misc.git/commitdiff/257002094bc5935dd63207a380d9698ab81f0775

which was that one that your compile failed on first.

Thanks again for all your work!

2019-01-15 16:56:03

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 15, 2019 at 02:56:34PM +0100, Christian Zigotzky wrote:
> On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
>> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
>>> Next step: 21074ef03c0816ae158721a78cabe9035938dddd (powerpc/dma: use the
>>> generic direct mapping bypass)
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> git checkout 21074ef03c0816ae158721a78cabe9035938dddd
>>>
>>> I was able to compile the kernel for the AmigaOne X1000 (Nemo board with PA
>>> Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet doesn't
>>> work.
>> Thanks. But we are exactly missing the steps that are relevant. I've
>> pushed a fixed up powerpc-dma.6 tree, which will only change starting from
>> the first commit that didn't link.
>>
>> The first commit that changed from the old one is this one:
>>
>> http://git.infradead.org/users/hch/misc.git/commitdiff/257002094bc5935dd63207a380d9698ab81f0775
>>
>> which was that one that your compile failed on first.
>>
>> Thanks again for all your work!
>>
> Thank you! I tried the commit 240d7ecd7f6fa62e074e8a835e620047954f0b28
> (powerpc/dma: use the dma-direct allocator for coherent platforms) again.
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
>
> I modified the 'dma.c' patch because of the undefined references to
> '__dma_nommu_free_coherent' and '__dma_nommu_alloc_coherent':

So 257002094bc5935dd63207a380d9698ab81f0775 above is the fixed version
for the commit - this switched the ifdef in dma.c around that I had
inverted. Can you try that one instead? And then move on with the
commits after it in the updated powerpc-dma.6 branch - they are
identical to the original branch except for carrying this fix forward.

2019-01-15 17:17:07

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
>> Next step: 21074ef03c0816ae158721a78cabe9035938dddd (powerpc/dma: use the
>> generic direct mapping bypass)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 21074ef03c0816ae158721a78cabe9035938dddd
>>
>> I was able to compile the kernel for the AmigaOne X1000 (Nemo board with PA
>> Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet doesn't
>> work.
> Thanks. But we are exactly missing the steps that are relevant. I've
> pushed a fixed up powerpc-dma.6 tree, which will only change starting from
> the first commit that didn't link.
>
> The first commit that changed from the old one is this one:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/257002094bc5935dd63207a380d9698ab81f0775
>
> which was that one that your compile failed on first.
>
> Thanks again for all your work!
>
Thank you! I tried the commit 240d7ecd7f6fa62e074e8a835e620047954f0b28
(powerpc/dma: use the dma-direct allocator for coherent platforms) again.

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28

I modified the 'dma.c' patch because of the undefined references to
'__dma_nommu_free_coherent' and '__dma_nommu_alloc_coherent':

---

@@ -163,8 +99,13 @@ static inline void dma_nommu_sync_single(struct
device *dev,
 #endif

 const struct dma_map_ops dma_nommu_ops = {
+       .alloc                          = dma_direct_alloc,
+       .free                           = dma_direct_free,
        .map_sg                         = dma_nommu_map_sg,
        .unmap_sg                       = dma_nommu_unmap_sg,
        .dma_supported                  = dma_direct_supported,

---

The X1000 boots and the PASEMI onboard ethernet works! X5000 (P5020
board): U-Boot loads the kernel and the dtb file. Then the kernel starts
but it doesn't find any hard disks (partitions).

-- Christian


2019-01-17 09:50:57

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Jan 17, 2019 at 10:21:11AM +0100, Christian Zigotzky wrote:
> The X1000 boots and the PASEMI onboard ethernet works!
>
> Bad news for the X5000 (P5020 board). U-Boot loads the kernel and the dtb
> file. Then the kernel starts but it doesn't find any hard disks
> (partitions).

Thanks for bisecting so far, and lets stop here until I manage to
resolve the problem.

Can you send me the .config and the dtb file for this board?

2019-01-17 09:51:40

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 17 January 2019 at 10:31AM, Christoph Hellwig wrote:
> On Thu, Jan 17, 2019 at 10:21:11AM +0100, Christian Zigotzky wrote:
>> The X1000 boots and the PASEMI onboard ethernet works!
>>
>> Bad news for the X5000 (P5020 board). U-Boot loads the kernel and the dtb
>> file. Then the kernel starts but it doesn't find any hard disks
>> (partitions).
> Thanks for bisecting so far, and lets stop here until I manage to
> resolve the problem.
>
> Can you send me the .config and the dtb file for this board?
>
Please find attached the Cyrus kernel config (X5000) and the source
files for the dtb file.

-- Christian


Attachments:
cyrus-5.0-rc2.config (133.13 kB)
cyrus_p5020.eth.dts (3.72 kB)
cyrus-pre.dtsi (3.18 kB)
Download all attachments

2019-01-17 11:45:31

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi All,

I compiled the fixed '257002094bc5935dd63207a380d9698ab81f0775'
(powerpc/dma: use the dma-direct allocator for coherent platforms) today.

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 257002094bc5935dd63207a380d9698ab81f0775

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6


env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage

env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

The X1000 boots and the PASEMI onboard ethernet works!

Bad news for the X5000 (P5020 board). U-Boot loads the kernel and the
dtb file. Then the kernel starts but it doesn't find any hard disks
(partitions).

Cheers,
Christian


On 15 January 2019 at 4:17PM, Christoph Hellwig wrote:

So 257002094bc5935dd63207a380d9698ab81f0775 above is the fixed version
for the commit - this switched the ifdef in dma.c around that I had
inverted.  Can you try that one instead?  And then move on with the
commits after it in the updated powerpc-dma.6 branch - they are
identical to the original branch except for carrying this fix forward.

2019-01-18 08:37:34

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christian,

can you check if the debug printks in this patch trigger?

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
+ }

if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
}
}

+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}


2019-01-18 11:12:46

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

For which commit?

-- Christian

On 18 January 2019 at 09:35AM, Christoph Hellwig wrote:
> Hi Christian,
>
> can you check if the debug printks in this patch trigger?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..e46c9b64ec0d 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> page = NULL;
> }
> }
> - if (!page)
> + if (!page) {
> page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> + if (!page)
> + pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
> + }
>
> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> __free_pages(page, page_order);
> @@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> }
> }
>
> + if (!page) {
> + pr_warn("failed to allocate DMA memory!\n");
> + dump_stack();
> + }
> return page;
> }
>
>


2019-01-18 11:30:50

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
> For which commit?

On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
one you identified as breaking the detection of the SATA disks.

2019-01-18 12:10:21

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout 257002094bc5935dd63207a380d9698ab81f0775


I get the following error message with your patch:

patching file a/kernel/dma/direct.c
Hunk #1 FAILED at 118.
Hunk #2 FAILED at 139.
2 out of 2 hunks FAILED -- saving rejects to file a/kernel/dma/direct.c.rej

-- Christian

On 18 January 2019 at 12:28PM, Christoph Hellwig wrote:
> On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote:
>> For which commit?
> On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first
> one you identified as breaking the detection of the SATA disks.
>


2019-01-18 12:20:52

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>
>
> I get the following error message with your patch:

Hmm. Did I attached the wrong patch? Here is the one I want and just
applied to that revision:

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
+ }

if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
}
}

+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}


2019-01-18 12:48:31

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Sorry, it's not possible to patch
'257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried
it manually but without any success.

-- Christian

On 18 January 2019 at 1:18PM, Christoph Hellwig wrote:
> On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout 257002094bc5935dd63207a380d9698ab81f0775
>>
>>
>> I get the following error message with your patch:
> Hmm. Did I attached the wrong patch? Here is the one I want and just
> applied to that revision:
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..e46c9b64ec0d 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> page = NULL;
> }
> }
> - if (!page)
> + if (!page) {
> page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> + if (!page)
> + pr_warn("failed to allocate memory with gfp 0x%x\n", gfp);
> + }
>
> if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> __free_pages(page, page_order);
> @@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
> }
> }
>
> + if (!page) {
> + pr_warn("failed to allocate DMA memory!\n");
> + dump_stack();
> + }
> return page;
> }
>
>


2019-01-18 12:56:43

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Jan 18, 2019 at 01:46:46PM +0100, Christian Zigotzky wrote:
> Sorry, it's not possible to patch
> '257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried it
> manually but without any success.

Weird:

hch@carbon:~/work/linux$ git checkout 257002094bc5935dd63207a380d9698ab81f0775
HEAD is now at 257002094bc5 powerpc/dma: use the dma-direct allocator for coherent platforms
hch@carbon:~/work/linux$ patch -p1 < dbg.diff
patching file kernel/dma/direct.c

I've pushed the result to

git://git.infradead.org/users/hch/misc.git

as a new powerpc-dma.6-debug branch


Attachments:
(No filename) (607.00 B)
dbg.diff (774.00 B)
Download all attachments

2019-01-18 15:08:40

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hello Christoph,

I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your
Git powerpc-dma.6-debug today.

Unfortunately I don't see any error messages (kernel ring buffer) and I
don't have a RS232 serial null modem cable to get them.

Cheers,
Christian


2019-01-19 11:43:00

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I bought a USB null modem RS-232 serial cable today so I was able to get
some SATA error messages.

Error messages:

[?? 13.468538] fsl-sata ffe220000.sata: Sata FSL Platform/CSB Driver init
[?? 13.475106] fsl-sata ffe220000.sata: failed to start port 0 (errno=-12)
[?? 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init
[?? 13.488267] fsl-sata ffe221000.sata: failed to start port 0 (errno=-12)

---

errno=-12 = Out of memory

Please find attached the complete serial log.

Cheers,
Christian


On 18 January 2019 at 4:06PM, Christian Zigotzky wrote:
> Hello Christoph,
>
> I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from
> your Git powerpc-dma.6-debug today.
>
> Unfortunately I don't see any error messages (kernel ring buffer) and
> I don't have a RS232 serial null modem cable to get them.
>
> Cheers,
> Christian
>
>


Attachments:
PuTTY_serial.log (34.29 kB)

2019-01-19 11:54:59

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I have found a small workaround. If I add 'mem=3500M' to the boot
arguments then it detects the SATA hard disk and boots without any problems.

X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 mem=3500M

Cheers,
Christian


On 19 January 2019 at 12:40PM, Christian Zigotzky wrote:
> Hi Christoph,
>
> I bought a USB null modem RS-232 serial cable today so I was able to
> get some SATA error messages.
>
> Error messages:
>
> [?? 13.468538] fsl-sata ffe220000.sata: Sata FSL Platform/CSB Driver init
> [?? 13.475106] fsl-sata ffe220000.sata: failed to start port 0
> (errno=-12)
> [?? 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init
> [?? 13.488267] fsl-sata ffe221000.sata: failed to start port 0
> (errno=-12)
>
> ---
>
> errno=-12 = Out of memory
>
> Please find attached the complete serial log.
>
> Cheers,
> Christian
>
>
> On 18 January 2019 at 4:06PM, Christian Zigotzky wrote:
>> Hello Christoph,
>>
>> I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from
>> your Git powerpc-dma.6-debug today.
>>
>> Unfortunately I don't see any error messages (kernel ring buffer) and
>> I don't have a RS232 serial null modem cable to get them.
>>
>> Cheers,
>> Christian
>>
>>
>


2019-01-19 13:04:19

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sat, Jan 19, 2019 at 12:52:52PM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> I have found a small workaround. If I add 'mem=3500M' to the boot arguments
> then it detects the SATA hard disk and boots without any problems.
>
> X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 mem=3500M

Interesting. This suggest it is related to the use of ZONE_DMA by
the FSL SOCs that your board uses. Let me investigate this a bit more.

2019-01-19 14:11:13

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sat, Jan 19, 2019 at 02:02:22PM +0100, Christoph Hellwig wrote:
> Interesting. This suggest it is related to the use of ZONE_DMA by
> the FSL SOCs that your board uses. Let me investigate this a bit more.

As a hack to check that theory I've pushed a new commit to the
powerpc-dma.6-debug branch to use old powerpc GFP_DMA selection
with the new dma direct code:

http://git.infradead.org/users/hch/misc.git/commitdiff/5c532d07c2f3c3972104de505d06b8d85f403f06

And another one that drops the addressability checks that powerpc
never had:

http://git.infradead.org/users/hch/misc.git/commitdiff/18e7629b38465ca98f8e7eed639123a13ac3b669

Can you first test with both patches, and then just with the first
in case that worked?


2019-01-21 14:40:11

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hello Christoph,

Thanks for your reply. I successfully compiled a kernel (uImage) for the
X5000 from your Git 'powerpc-dma.6-debug' (both patches) today.

It detects the SATA hard disk drive and boots without any problems. I
will test the first patch in next days.

Thanks for your help,

Christian


On 19 January 2019 at 3:04PM, Christoph Hellwig wrote:
> On Sat, Jan 19, 2019 at 02:02:22PM +0100, Christoph Hellwig wrote:
>> Interesting. This suggest it is related to the use of ZONE_DMA by
>> the FSL SOCs that your board uses. Let me investigate this a bit more.
> As a hack to check that theory I've pushed a new commit to the
> powerpc-dma.6-debug branch to use old powerpc GFP_DMA selection
> with the new dma direct code:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/5c532d07c2f3c3972104de505d06b8d85f403f06
>
> And another one that drops the addressability checks that powerpc
> never had:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/18e7629b38465ca98f8e7eed639123a13ac3b669
>
> Can you first test with both patches, and then just with the first
> in case that worked?
>
>


2019-01-23 14:37:07

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I also compiled a kernel (zImage) for the X1000  from your Git
'powerpc-dma.6-debug' (both patches) today.

It boots and the P.A. Semi Ethernet works!

I will test just the first patch tomorrow.

Thanks,
Christian


On 21 January 2019 at 3:38PM, Christian Zigotzky wrote:
> Hello Christoph,
>
> Thanks for your reply. I successfully compiled a kernel (uImage) for
> the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today.
>
> It detects the SATA hard disk drive and boots without any problems.
>


2019-01-25 13:38:26

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Next step just with the first patch:
5c532d07c2f3c3972104de505d06b8d85f403f06 (use powerpc zone selection)

git clone git://git.infradead.org/users/hch/misc.git -b
powerpc-dma.6-debug a

git checkout 5c532d07c2f3c3972104de505d06b8d85f403f06

Link to the Git:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug

Results:

X5000: The kernel detects the SATA hard disk drive and boots without any
problems.

X1000: The kernel boots and the P.A. Semi Ethernet works!

-- Christian


On 23 January 2019 at 3:34PM, Christian Zigotzky wrote:
> Hi Christoph,
>
> I also compiled a kernel (zImage) for the X1000  from your Git
> 'powerpc-dma.6-debug' (both patches) today.
>
> It boots and the P.A. Semi Ethernet works!
>
> I will test just the first patch tomorrow.
>
> Thanks,
> Christian
>
>
> On 21 January 2019 at 3:38PM, Christian Zigotzky wrote:
>> Hello Christoph,
>>
>> Thanks for your reply. I successfully compiled a kernel (uImage) for
>> the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today.
>>
>> It detects the SATA hard disk drive and boots without any problems.
>>
>
>


2019-01-27 13:17:01

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Christoph,

What shall I do next?

Cheers,
Christian


On 25 January 2019 at 2:37PM, Christian Zigotzky wrote:
> Next step just with the first patch:
> 5c532d07c2f3c3972104de505d06b8d85f403f06 (use powerpc zone selection)
>
> git clone git://git.infradead.org/users/hch/misc.git -b
> powerpc-dma.6-debug a
>
> git checkout 5c532d07c2f3c3972104de505d06b8d85f403f06
>
> Link to the Git:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug
>
> Results:
>
> X5000: The kernel detects the SATA hard disk drive and boots without
> any problems.
>
> X1000: The kernel boots and the P.A. Semi Ethernet works!
>
> -- Christian
>
>
> On 23 January 2019 at 3:34PM, Christian Zigotzky wrote:
>> Hi Christoph,
>>
>> I also compiled a kernel (zImage) for the X1000  from your Git
>> 'powerpc-dma.6-debug' (both patches) today.
>>
>> It boots and the P.A. Semi Ethernet works!
>>
>> I will test just the first patch tomorrow.
>>
>> Thanks,
>> Christian
>>
>>
>> On 21 January 2019 at 3:38PM, Christian Zigotzky wrote:
>>> Hello Christoph,
>>>
>>> Thanks for your reply. I successfully compiled a kernel (uImage) for
>>> the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today.
>>>
>>> It detects the SATA hard disk drive and boots without any problems.
>>>
>>
>>
>
>


2019-01-28 07:06:41

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote:
> Christoph,
>
> What shall I do next?

I'll need to figure out what went wrong with the new zone selection
on powerpc and give you another branch to test.

2019-01-28 16:47:15

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote:
> On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote:
> > Christoph,
> >
> > What shall I do next?
>
> I'll need to figure out what went wrong with the new zone selection
> on powerpc and give you another branch to test.

Can you try the new powerpc-dma.6-debug.2 branch:

git://git.infradead.org/users/hch/misc.git powerpc-dma.6-debug.2

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug.2

2019-01-28 16:54:24

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Thanks a lot! I will test it tomorrow.

— Christian

Sent from my iPhone

> On 28. Jan 2019, at 17:22, Christoph Hellwig <[email protected]> wrote:
>
>> On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote:
>>> On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote:
>>> Christoph,
>>>
>>> What shall I do next?
>>
>> I'll need to figure out what went wrong with the new zone selection
>> on powerpc and give you another branch to test.
>
> Can you try the new powerpc-dma.6-debug.2 branch:
>
> git://git.infradead.org/users/hch/misc.git powerpc-dma.6-debug.2
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug.2


2019-01-29 15:04:49

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I compiled kernels for the X5000 and X1000 from your new branch
'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi
Ethernet works!

Cheers,
Christian


On 28 January 2019 at 5:52PM, Christian Zigotzky wrote:
> Thanks a lot! I will test it tomorrow.
>
> — Christian
>
> Sent from my iPhone
>
>> On 28. Jan 2019, at 17:22, Christoph Hellwig <[email protected]> wrote:
>>
>>> On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote:
>>>> On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote:
>>>> Christoph,
>>>>
>>>> What shall I do next?
>>> I'll need to figure out what went wrong with the new zone selection
>>> on powerpc and give you another branch to test.
>> Can you try the new powerpc-dma.6-debug.2 branch:
>>
>> git://git.infradead.org/users/hch/misc.git powerpc-dma.6-debug.2
>>
>> Gitweb:
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug.2
>


2019-01-29 16:17:00

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> I compiled kernels for the X5000 and X1000 from your new branch
> 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet
> works!

Thanks for testing! I'll prepare a new series that adds the other
patches on top of this one.

2019-01-29 16:36:43

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Jan 29, 2019 at 05:14:11PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote:
> > Hi Christoph,
> >
> > I compiled kernels for the X5000 and X1000 from your new branch
> > 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet
> > works!
>
> Thanks for testing! I'll prepare a new series that adds the other
> patches on top of this one.

And that was easier than I thought - we just had a few patches left
in powerpc-dma.6, so I've rebased that branch on top of
powerpc-dma.6-debug.2:

git://git.infradead.org/users/hch/misc.git powerpc-dma.6

Gitweb:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

I hope the other patches are simple enough, so just testing the full
branch checkout should be fine for now.

2019-01-30 04:42:55

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Thanks a lot for the updates. I will test the full branch tomorrow.

Cheers,
Christian

Sent from my iPhone

> On 29. Jan 2019, at 17:34, Christoph Hellwig <[email protected]> wrote:
>
>> On Tue, Jan 29, 2019 at 05:14:11PM +0100, Christoph Hellwig wrote:
>>> On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote:
>>> Hi Christoph,
>>>
>>> I compiled kernels for the X5000 and X1000 from your new branch
>>> 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet
>>> works!
>>
>> Thanks for testing! I'll prepare a new series that adds the other
>> patches on top of this one.
>
> And that was easier than I thought - we just had a few patches left
> in powerpc-dma.6, so I've rebased that branch on top of
> powerpc-dma.6-debug.2:
>
> git://git.infradead.org/users/hch/misc.git powerpc-dma.6
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> I hope the other patches are simple enough, so just testing the full
> branch checkout should be fine for now.

2019-01-31 12:49:32

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I compiled kernels for the X5000 and X1000 from your branch
'powerpc-dma.6' today.

Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
doesn't work.

Error messages (X1000):

[   17.371736] pci 0000:00:1a.0: overflow 0x00000002691bf802+1646 of DMA
mask ffffffff bus mask 0
[   17.371760] WARNING: CPU: 0 PID: 2496 at kernel/dma/direct.c:43
.dma_direct_map_page+0x11c/0x200
[   17.371762] Modules linked in:
[   17.371769] CPU: 0 PID: 2496 Comm: NetworkManager Not tainted
5.0.0-rc4-3_A-EON_AmigaOne_X1000_Nemo-54580-g8d7a724-dirty #2
[   17.371772] NIP:  c00000000010395c LR: c000000000103a30 CTR:
c000000000726f70
[   17.371775] REGS: c00000026900e9a0 TRAP: 0700   Not tainted
(5.0.0-rc4-3_A-EON_AmigaOne_X1000_Nemo-54580-g8d7a724-dirty)
[   17.371777] MSR:  9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR:
24002222  XER: 20000000
[   17.371786] IRQMASK: 0
               GPR00: c000000000103a30 c00000026900ec30
c000000001923f00 0000000000000052
               GPR04: c00000026f206778 c00000026f20d458
0000000000000000 0000000000000346
               GPR08: 0000000000000007 0000000000000000
0000000000000000 0000000000000010
               GPR12: 0000000022002444 c000000001b10000
0000000000000000 0000000000000000
               GPR16: 0000000010382410 0000000000000000
0000000000000000 c00000026bd9d820
               GPR20: 0000000000000000 c00000026919c000
0000000000000000 0000000000000000
               GPR24: 0000000000000800 c000000269190000
c0000002692a4180 c000000269190000
               GPR28: c000000277ada1c8 000000000000066e
c00000026d3c68b0 0000000000000802
[   17.371823] NIP [c00000000010395c] .dma_direct_map_page+0x11c/0x200
[   17.371827] LR [c000000000103a30] .dma_direct_map_page+0x1f0/0x200
[   17.371829] Call Trace:
[   17.371833] [c00000026900ec30] [c000000000103a30]
.dma_direct_map_page+0x1f0/0x200 (unreliable)
[   17.371840] [c00000026900ecd0] [c00000000099b7ec]
.pasemi_mac_replenish_rx_ring+0x12c/0x2a0
[   17.371846] [c00000026900eda0] [c00000000099dc64]
.pasemi_mac_open+0x384/0x7c0
[   17.371853] [c00000026900ee40] [c000000000c6f484] .__dev_open+0x134/0x1e0
[   17.371858] [c00000026900eee0] [c000000000c6f9ec]
.__dev_change_flags+0x1bc/0x210
[   17.371863] [c00000026900ef90] [c000000000c6fa88]
.dev_change_flags+0x48/0xa0
[   17.371869] [c00000026900f030] [c000000000c8c88c] .do_setlink+0x3dc/0xf60
[   17.371875] [c00000026900f1b0] [c000000000c8dd84]
.__rtnl_newlink+0x5e4/0x900
[   17.371880] [c00000026900f5f0] [c000000000c8e10c] .rtnl_newlink+0x6c/0xb0
[   17.371885] [c00000026900f680] [c000000000c89838]
.rtnetlink_rcv_msg+0x2e8/0x3d0
[   17.371891] [c00000026900f760] [c000000000cc0f90]
.netlink_rcv_skb+0x120/0x170
[   17.371896] [c00000026900f820] [c000000000c87318]
.rtnetlink_rcv+0x28/0x40
[   17.371901] [c00000026900f8a0] [c000000000cc03f8]
.netlink_unicast+0x208/0x2f0
[   17.371906] [c00000026900f950] [c000000000cc09a8]
.netlink_sendmsg+0x348/0x460
[   17.371911] [c00000026900fa30] [c000000000c38774] .sock_sendmsg+0x44/0x70
[   17.371915] [c00000026900fab0] [c000000000c3a79c]
.___sys_sendmsg+0x30c/0x320
[   17.371920] [c00000026900fca0] [c000000000c3c3b4]
.__sys_sendmsg+0x74/0xf0
[   17.371926] [c00000026900fd90] [c000000000cb4da0]
.__se_compat_sys_sendmsg+0x40/0x60
[   17.371932] [c00000026900fe20] [c00000000000a21c] system_call+0x5c/0x70
[   17.371934] Instruction dump:
[   17.371937] 60000000 f8610070 3d20ffff 6129fffe 79290020 e8e70000
7fa74840 409d00b8
[   17.371946] 3d420001 892acb59 2f890000 419e00b8 <0fe00000> 382100a0
3860ffff e8010010
[   17.371954] ---[ end trace a81f3c344f625f76 ]---
[   17.396654] IPv6: ADDRCONF(NETDEV_UP): enp0s20f3: link is not ready

--------

Additionally, Xorg doesn't start on a virtual e5500 QEMU machine
anymore. I tested with the following QEMU command:

./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel
/home/christian/Downloads/vmlinux-5.0-rc4-3-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0
-drive
format=raw,file=/home/christian/Downloads/Fienix-Beta120418.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw
es1370 -smp 4

Cheers,
Christian


On 30 January 2019 at 05:40AM, Christian Zigotzky wrote:
> Hi Christoph,
>
> Thanks a lot for the updates. I will test the full branch tomorrow.
>
> Cheers,
> Christian
>
> Sent from my iPhone
>
>> On 29. Jan 2019, at 17:34, Christoph Hellwig <[email protected]> wrote:
>>
>>> On Tue, Jan 29, 2019 at 05:14:11PM +0100, Christoph Hellwig wrote:
>>>> On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote:
>>>> Hi Christoph,
>>>>
>>>> I compiled kernels for the X5000 and X1000 from your new branch
>>>> 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet
>>>> works!
>>> Thanks for testing! I'll prepare a new series that adds the other
>>> patches on top of this one.
>> And that was easier than I thought - we just had a few patches left
>> in powerpc-dma.6, so I've rebased that branch on top of
>> powerpc-dma.6-debug.2:
>>
>> git://git.infradead.org/users/hch/misc.git powerpc-dma.6
>>
>> Gitweb:
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> I hope the other patches are simple enough, so just testing the full
>> branch checkout should be fine for now.



2019-02-01 08:05:20

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6'
> today.
>
> Gitweb:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't
> work.

Oh. Can you try with just the next one and then two patches applied
over the working setup? That is first:

http://git.infradead.org/users/hch/misc.git/commitdiff/b50f42f0fe12965ead395c76bcb6a14f00cdf65b

then also with:

http://git.infradead.org/users/hch/misc.git/commitdiff/21fe52470a483afbb1726741118abef8602dde4d

2019-02-01 17:52:10

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I will try it at the weekend.

Thanks,
Christian

Sent from my iPhone

> On 1. Feb 2019, at 09:04, Christoph Hellwig <[email protected]> wrote:
>
>> On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote:
>> Hi Christoph,
>>
>> I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6'
>> today.
>>
>> Gitweb:
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't
>> work.
>
> Oh. Can you try with just the next one and then two patches applied
> over the working setup? That is first:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>
> then also with:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/21fe52470a483afbb1726741118abef8602dde4d

2019-02-03 17:08:46

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma:
use the dma_direct mapping routines)

git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a

git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b

Results: The X1000 and X5000 boot but unfortunately the P.A. Semi
Ethernet doesn't work.

-- Christian


On 01 February 2019 at 5:54PM, Christian Zigotzky wrote:
> Hi Christoph,
>
> I will try it at the weekend.
>
> Thanks,
> Christian
>
> Sent from my iPhone
>
>> On 1. Feb 2019, at 09:04, Christoph Hellwig <[email protected]> wrote:
>>
>>> On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote:
>>> Hi Christoph,
>>>
>>> I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6'
>>> today.
>>>
>>> Gitweb:
>>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>>>
>>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>>
>>> The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't
>>> work.
>> Oh. Can you try with just the next one and then two patches applied
>> over the working setup? That is first:
>>
>> http://git.infradead.org/users/hch/misc.git/commitdiff/b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>>
>> then also with:
>>
>> http://git.infradead.org/users/hch/misc.git/commitdiff/21fe52470a483afbb1726741118abef8602dde4d



2019-02-04 07:57:32

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote:
> OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use
> the dma_direct mapping routines)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>
> Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
> doesn't work.

Are there any interesting messages in the boot log? Can you send me
the dmesg?

2019-02-04 14:21:21

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 04 February 2019 at 08:56AM, Christoph Hellwig wrote:
> On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote:
>> OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use
>> the dma_direct mapping routines)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>>
>> Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
>> doesn't work.
> Are there any interesting messages in the boot log? Can you send me
> the dmesg?
>
Here you are: http://www.xenosoft.de/dmesg_X1000_with_DMA_updates.txt

-- Christian


2019-02-04 14:25:40

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Mon, Feb 04, 2019 at 01:13:54PM +0100, Christian Zigotzky wrote:
>>> Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
>>> doesn't work.
>> Are there any interesting messages in the boot log? Can you send me
>> the dmesg?
>>
> Here you are: http://www.xenosoft.de/dmesg_X1000_with_DMA_updates.txt

It seems like the pasemi driver fails to set a DMA mask, but seems
otherwise 64-bit DMA capable. The old PPC code didn't verify the
dma mask during the map operations, but the x86-derived generic
code does.

This patch just sets the DMA mask.

Olof: does this look ok? The DMA device seems to not directly
bound by the net driver, but not really used by anything else in tree
either..

diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
index d21041554507..d98bd447c536 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = -ENODEV;
goto out;
}
+ dma_set_mask(&mac->dma_pdev->dev, DMA_BIT_MASK(32));

mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
if (!mac->iob_pdev) {

2019-02-06 13:46:28

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 04 February 2019 at 01:38PM, Christoph Hellwig wrote:
>
> It seems like the pasemi driver fails to set a DMA mask, but seems
> otherwise 64-bit DMA capable. The old PPC code didn't verify the
> dma mask during the map operations, but the x86-derived generic
> code does.
>
> This patch just sets the DMA mask.
>
> Olof: does this look ok? The DMA device seems to not directly
> bound by the net driver, but not really used by anything else in tree
> either..
>
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index d21041554507..d98bd447c536 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> err = -ENODEV;
> goto out;
> }
> + dma_set_mask(&mac->dma_pdev->dev, DMA_BIT_MASK(32));
>
> mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
> if (!mac->iob_pdev) {
>
Hello Christoph,

I patched the source code from the Git 'powerpc-dma.6' with your patch
today. Unfortunately the P.A. Semi Ethernet doesn't work with the
patched Git kernel.

After that I tried it with the patch applied over the working setup
again (powerpc/dma: use the dma_direct mapping routines). Unfortunately
after compiling
and booting, the P.A. Semi Ethernet doesn't work either.

Cheers,
Christian


2019-02-06 15:36:31

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Wed, Feb 06, 2019 at 02:45:34PM +0100, Christian Zigotzky wrote:
> I patched the source code from the Git 'powerpc-dma.6' with your patch
> today. Unfortunately the P.A. Semi Ethernet doesn't work with the patched
> Git kernel.
>
> After that I tried it with the patch applied over the working setup again
> (powerpc/dma: use the dma_direct mapping routines). Unfortunately after
> compiling
> and booting, the P.A. Semi Ethernet doesn't work either.

The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
remember correctly. powerpc/dma: use the dma_direct mapping routines
was the one that you said makes the pasemi ethernet stop working.

Can you post the dmesg from the failing runs?

2019-02-06 15:41:37

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
> The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
> ("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
> remember correctly. powerpc/dma: use the dma_direct mapping routines
> was the one that you said makes the pasemi ethernet stop working.
>
> Can you post the dmesg from the failing runs?

But I just noticed I sent you a wrong patch - the pasemi ethernet
should set a 64-bit DMA mask, not 32-bit. Updated version below,
32-bit would just keep the previous status quo.

commit 6c8f88045dee35933337b9ce2ea5371eee37073a
Author: Christoph Hellwig <[email protected]>
Date: Mon Feb 4 13:38:22 2019 +0100

pasemi WIP

diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
index 8a31a02c9f47..2d7d1589490a 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = -ENODEV;
goto out;
}
+ dma_set_mask(&mac->dma_pdev->dev, DMA_BIT_MASK(64));

mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
if (!mac->iob_pdev) {

2019-02-07 04:37:25

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

I also didn’t notice the 32-bit DMA mask in your patch. I have to read your patches and descriptions carefully in the future. I will test your new patch at the weekend.

Thanks,
Christian

Sent from my iPhone

> On 6. Feb 2019, at 16:16, Christoph Hellwig <[email protected]> wrote:
>
>> On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
>> The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
>> ("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
>> remember correctly. powerpc/dma: use the dma_direct mapping routines
>> was the one that you said makes the pasemi ethernet stop working.
>>
>> Can you post the dmesg from the failing runs?
>
> But I just noticed I sent you a wrong patch - the pasemi ethernet
> should set a 64-bit DMA mask, not 32-bit. Updated version below,
> 32-bit would just keep the previous status quo.
>
> commit 6c8f88045dee35933337b9ce2ea5371eee37073a
> Author: Christoph Hellwig <[email protected]>
> Date: Mon Feb 4 13:38:22 2019 +0100
>
> pasemi WIP
>
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index 8a31a02c9f47..2d7d1589490a 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> err = -ENODEV;
> goto out;
> }
> + dma_set_mask(&mac->dma_pdev->dev, DMA_BIT_MASK(64));
>
> mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
> if (!mac->iob_pdev) {

2019-02-08 09:02:54

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Your new patch fixes the problems with the P.A. Semi Ethernet! :-)

Thanks,
Christian


On 07 February 2019 at 05:34AM, Christian Zigotzky wrote:
> Hi Christoph,
>
> I also didn’t notice the 32-bit DMA mask in your patch. I have to read your patches and descriptions carefully in the future. I will test your new patch at the weekend.
>
> Thanks,
> Christian
>
> Sent from my iPhone
>
>> On 6. Feb 2019, at 16:16, Christoph Hellwig <[email protected]> wrote:
>>
>>> On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
>>> The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
>>> ("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
>>> remember correctly. powerpc/dma: use the dma_direct mapping routines
>>> was the one that you said makes the pasemi ethernet stop working.
>>>
>>> Can you post the dmesg from the failing runs?
>> But I just noticed I sent you a wrong patch - the pasemi ethernet
>> should set a 64-bit DMA mask, not 32-bit. Updated version below,
>> 32-bit would just keep the previous status quo.
>>
>> commit 6c8f88045dee35933337b9ce2ea5371eee37073a
>> Author: Christoph Hellwig <[email protected]>
>> Date: Mon Feb 4 13:38:22 2019 +0100
>>
>> pasemi WIP
>>
>> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
>> index 8a31a02c9f47..2d7d1589490a 100644
>> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
>> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
>> @@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>> err = -ENODEV;
>> goto out;
>> }
>> + dma_set_mask(&mac->dma_pdev->dev, DMA_BIT_MASK(64));
>>
>> mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
>> if (!mac->iob_pdev) {



2019-02-08 09:20:03

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> Your new patch fixes the problems with the P.A. Semi Ethernet! :-)

Thanks a lot once again for testing!

Now can you test with this patch and the whole series?

I've updated the powerpc-dma.6 branch to include this fix.

2019-02-08 11:00:05

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

OK, I will test it.

— Christian

Sent from my iPhone

> On 8. Feb 2019, at 10:18, Christoph Hellwig <[email protected]> wrote:
>
>> On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote:
>> Hi Christoph,
>>
>> Your new patch fixes the problems with the P.A. Semi Ethernet! :-)
>
> Thanks a lot once again for testing!
>
> Now can you test with this patch and the whole series?
>
> I've updated the powerpc-dma.6 branch to include this fix.

2019-02-10 12:01:05

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

On 08 February 2019 at 10:18AM, Christoph Hellwig wrote:
> On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote:
>> Hi Christoph,
>>
>> Your new patch fixes the problems with the P.A. Semi Ethernet! :-)
> Thanks a lot once again for testing!
>
> Now can you test with this patch and the whole series?
>
> I've updated the powerpc-dma.6 branch to include this fix.
>
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!

I also tested it in a virtual e5500 QEMU machine today. Unfortunately
the kernel crashes.

Log:

[   54.624330] BUG: Unable to handle kernel data access at
0xc06c008a0013014a
[   54.625640] Faulting instruction address: 0xc000000000027e7c
[   54.626140] Oops: Kernel access of bad area, sig: 11 [#1]
[   54.626456] BE SMP NR_CPUS=4 QEMU e500
[   54.626876] Modules linked in:
[   54.627284] CPU: 1 PID: 1876 Comm: systemd-journal Not tainted
5.0.0-rc5-DMA_A1-X5000-54581-gda1d065-dirty #1
[   54.627819] NIP:  c000000000027e7c LR: c0000000000b5264 CTR:
0000000000000000
[   54.628173] REGS: c00000007ffeb700 TRAP: 0300   Not tainted
(5.0.0-rc5-DMA_A1-X5000-54581-gda1d065-dirty)
[   54.628607] MSR:  0000000080009000 <EE,ME>  CR: 44008486 XER: 00000000
[   54.629023] DEAR: c06c008a0013014a ESR: 0000000000800000 IRQMASK: 0
[   54.629023] GPR00: 0000000000005254 c00000007ffeb990 c0000000016b2000
c06c008a0013014a
[   54.629023] GPR04: c00000007c54f8c0 0000000000000058 0000000000000006
0000000000000000
[   54.629023] GPR08: 0000000000000000 000000007c54f8c0 006c008a0013014a
c00000007c86c000
[   54.629023] GPR12: 0000000028002482 c00000003ffff8c0 0000000000000000
c000000078dfaa70
[   54.629023] GPR16: c000000078366c00 0000000000000000 000000000000005e
0000000000000000
[   54.629023] GPR20: 0000000000000000 c00000007c54f8c0 0000000000000007
c000000078dfa000
[   54.629023] GPR24: 0000000000000000 0000000000000047 0000000000000000
80000000003f6470
[   54.629023] GPR28: c00000007928d470 c000000078801dc0 000000000000005e
c000000078dfa7c0
[   54.632572] NIP [c000000000027e7c] .memcpy+0x1fc/0x288
[   54.632886] LR [c0000000000b5264] .swiotlb_tbl_sync_single+0xb0/0xe4
[   54.633221] Call Trace:
[   54.633513] [c00000007ffeb990] [c00000007ffeba70] 0xc00000007ffeba70
(unreliable)
[   54.633988] [c00000007ffeba00] [c0000000000b41e4]
.dma_direct_sync_single_for_cpu+0x58/0x6c
[   54.634436] [c00000007ffeba70] [c000000000788da4]
.e1000_clean_rx_irq+0x1bc/0x4c8
[   54.634857] [c00000007ffebb90] [c00000000078667c]
.e1000_clean+0x714/0x8d4
[   54.635263] [c00000007ffebcc0] [c000000000a3f15c]
.net_rx_action+0x11c/0x2a4
[   54.635712] [c00000007ffebdb0] [c000000000c48c20]
.__do_softirq+0x150/0x2a8
[   54.636211] [c00000007ffebeb0] [c000000000064184] .irq_exit+0x6c/0xc4
[   54.636533] [c00000007ffebf20] [c000000000004124] .__do_irq+0x80/0x94
[   54.636985] [c00000007ffebf90] [c00000000000eca0] .call_do_irq+0x14/0x24
[   54.637371] [c00000007c86fd80] [c0000000000041c0] .do_IRQ+0x88/0xc4
[   54.637737] [c00000007c86fe20] [c000000000012920]
exc_0x500_common+0xd8/0xdc
[   54.638104] Instruction dump:
[   54.638451] e861fff8 4e800020 7cd01120 7ca62850 38e00000 28a50010
409f0010 88040000
[   54.638887] 98030000 38e70001 409e0010 7c07222e <7c071b2e> 38e70002
409d000c 7c07202e
[   54.639594] ---[ end trace a4861de7e4c199f7 ]---
[   54.639873]
[   55.640484] Kernel panic - not syncing: Aiee, killing interrupt handler!
[   55.641556] Rebooting in 180 seconds..

-----

I tested with the following QEMU commands:

./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048  -nographic -kernel
/home/christian/Downloads/vmlinux-5.0-rc5-2-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0
-nic user,model=e1000 -drive
format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio
-append "rw root=/dev/vda" -smp 4

./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel
/home/christian/Downloads/vmlinux-5.0-rc5-2-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0
-drive
format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw
es1370 -smp 4

The RC5 of kernel 5.0 boots without any problems in this virtual machine.

Cheers,
Christian


2019-02-11 07:23:04

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi Christoph,

Mario successfully tested a kernel from your Git [1] on his T2080rdb today.

Link to the log:
https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt

He wrote:

Please, note that all of the above kernel runs just fine with the T2080rdb, however did not had the time to test extensively (tested: login into MATE graphical desktop environment, used ArctiFox for opening couple of websites, then played Neverball).

——

Cheers,
Christian

[1] http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6

2019-02-11 07:38:30

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
> I tested the whole series today. The kernels boot and the P.A. Semi
> Ethernet works! :-) Thanks a lot!
>
> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
> kernel crashes.

This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.

I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")

and added it to the powerpc-dma.6 tree, please retry with that one.

2019-02-12 12:54:41

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>> I tested the whole series today. The kernels boot and the P.A. Semi
>> Ethernet works! :-) Thanks a lot!
>>
>> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
>> kernel crashes.
> This looks like a patch I fixed in mainline a while ago, but which
> the powerpc tree didn't have yet.
>
> I've cherry picked this commit
> ("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
>
> and added it to the powerpc-dma.6 tree, please retry with that one.
>
Hello Christoph,

Have you added it to the powerpc-dma.6 tree yet? The last commit was 4
days ago.

Thanks,
Christian


2019-02-12 15:26:22

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
> On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
>> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>>> I tested the whole series today. The kernels boot and the P.A. Semi
>>> Ethernet works! :-) Thanks a lot!
>>>
>>> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
>>> kernel crashes.
>> This looks like a patch I fixed in mainline a while ago, but which
>> the powerpc tree didn't have yet.
>>
>> I've cherry picked this commit
>> ("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
>>
>> and added it to the powerpc-dma.6 tree, please retry with that one.
>>
> Hello Christoph,
>
> Have you added it to the powerpc-dma.6 tree yet? The last commit was 4 days
> ago.

I added it, but forgot to push it out. It is there now, sorry:

http://git.infradead.org/users/hch/misc.git/commitdiff/2cf0745b7420af4a3e871d5a970a45662dfae69c

2019-02-12 20:06:10

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
> On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
>> On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
>>> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>>>> I tested the whole series today. The kernels boot and the P.A. Semi
>>>> Ethernet works! :-) Thanks a lot!
>>>>
>>>> I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
>>>> kernel crashes.
>>> This looks like a patch I fixed in mainline a while ago, but which
>>> the powerpc tree didn't have yet.
>>>
>>> I've cherry picked this commit
>>> ("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
>>>
>>> and added it to the powerpc-dma.6 tree, please retry with that one.
>>>
>> Hello Christoph,
>>
>> Have you added it to the powerpc-dma.6 tree yet? The last commit was 4 days
>> ago.
> I added it, but forgot to push it out. It is there now, sorry:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/2cf0745b7420af4a3e871d5a970a45662dfae69c
>
Hi Christoph

Many thanks! Your Git kernel works in a virtual e5500 machine now! :-)

I think we have reached the end of testing! All things are working with
your DMA updates.

I am looking forward to test your DMA changes in the next merge window
again. :-)

Cheers
Christian


2019-02-12 20:09:00

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

On 12 February 2019 at 8:31PM, Christian Zigotzky wrote:
> On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
>> On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
>>> On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
>>>> On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
>>>>> I tested the whole series today. The kernels boot and the P.A. Semi
>>>>> Ethernet works! :-) Thanks a lot!
>>>>>
>>>>> I also tested it in a virtual e5500 QEMU machine today.
>>>>> Unfortunately the
>>>>> kernel crashes.
>>>> This looks like a patch I fixed in mainline a while ago, but which
>>>> the powerpc tree didn't have yet.
>>>>
>>>> I've cherry picked this commit
>>>> ("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
>>>>
>>>> and added it to the powerpc-dma.6 tree, please retry with that one.
>>>>
>>> Hello Christoph,
>>>
>>> Have you added it to the powerpc-dma.6 tree yet? The last commit was
>>> 4 days
>>> ago.
>> I added it, but forgot to push it out.  It is there now, sorry:
>>
>> http://git.infradead.org/users/hch/misc.git/commitdiff/2cf0745b7420af4a3e871d5a970a45662dfae69c
>>
>>
> Hi Christoph
>
> Many thanks! Your Git kernel works in a virtual e5500 machine now! :-)
>
> I think we have reached the end of testing! All things are working
> with your DMA updates.
>
> I am looking forward to testing your DMA changes in the next merge
> window again. :-)
>
> Cheers
> Christian
>
>
Edit: typo


2019-02-12 20:10:17

by Christoph Hellwig

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Great! I owe you a night worth of beers at a conference or if
you come anywhere near Innsbruck!

2019-11-05 08:10:04

by Christian Zigotzky

[permalink] [raw]
Subject: Bug 205201 - overflow of DMA mask and bus mask

Hi All,

We still have DMA problems with some PCI devices. Since the PowerPC
updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if
we want to work with our PCI devices. The FSL P5020 and P5040 have these
problems currently.

Error message:

[   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of
DMA mask ffffffff bus mask df000000

All 5.x Linux kernels can't initialize a SCSI PCI card anymore so
booting of a Linux userland isn't possible.

PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The
kernel 4.20 works with all PCI devices without limitation of RAM.

We created a bug report a month ago. [2]

Thanks,
Christian

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205201


2019-11-05 16:30:06

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
> Hi All,
>
> We still have DMA problems with some PCI devices. Since the PowerPC updates
> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
> work with our PCI devices. The FSL P5020 and P5040 have these problems
> currently.
>
> Error message:
>
> [?? 25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of DMA
> mask ffffffff bus mask df000000
>
> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting
> of a Linux userland isn't possible.
>
> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel
> 4.20 works with all PCI devices without limitation of RAM.

Can you send me the .config and a dmesg? And in the meantime try the
patch below?

---
From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001
From: Nicolas Saenz Julienne <[email protected]>
Date: Fri, 18 Oct 2019 13:00:43 +0200
Subject: dma-direct: check for overflows on 32 bit DMA addresses

As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
possible for a device configured with 32 bit DMA addresses and a partial
DMA mapping located at the end of the address space to overflow. It
happens when a higher physical address, not DMAable, is translated to
it's DMA counterpart.

For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
an interconnect capable of addressing the lower 1 GB of physical memory
with a DMA offset of 0xc0000000. It transpires that, any attempt to
translate physical addresses higher than the first GB will result in an
overflow which dma_capable() can't detect as it only checks for
addresses bigger then the maximum allowed DMA address.

Fix this by verifying in dma_capable() if the DMA address range provided
is at any point lower than the minimum possible DMA address on the bus.

Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
include/linux/dma-direct.h | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index adf993a3bd58..6ad9e9ea7564 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -3,6 +3,7 @@
#define _LINUX_DMA_DIRECT_H 1

#include <linux/dma-mapping.h>
+#include <linux/memblock.h> /* for min_low_pfn */
#include <linux/mem_encrypt.h>

#ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
@@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
if (!dev->dma_mask)
return false;

+#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
+ /* Check if DMA address overflowed */
+ if (min(addr, addr + size - 1) <
+ __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
+ return false;
+#endif
+
return addr + size - 1 <=
min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
}
--
2.20.1

2019-11-06 14:11:51

by Robin Murphy

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 05/11/2019 16:28, Christoph Hellwig wrote:
> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>> Hi All,
>>
>> We still have DMA problems with some PCI devices. Since the PowerPC updates
>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
>> work with our PCI devices. The FSL P5020 and P5040 have these problems
>> currently.
>>
>> Error message:
>>
>> [   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of DMA
>> mask ffffffff bus mask df000000

Hmm, that bus mask looks pretty wacky - are you able to figure out where
that's coming from?

Robin.

>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting
>> of a Linux userland isn't possible.
>>
>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel
>> 4.20 works with all PCI devices without limitation of RAM.
>
> Can you send me the .config and a dmesg? And in the meantime try the
> patch below?
>
> ---
> From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001
> From: Nicolas Saenz Julienne <[email protected]>
> Date: Fri, 18 Oct 2019 13:00:43 +0200
> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>
> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
> possible for a device configured with 32 bit DMA addresses and a partial
> DMA mapping located at the end of the address space to overflow. It
> happens when a higher physical address, not DMAable, is translated to
> it's DMA counterpart.
>
> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
> an interconnect capable of addressing the lower 1 GB of physical memory
> with a DMA offset of 0xc0000000. It transpires that, any attempt to
> translate physical addresses higher than the first GB will result in an
> overflow which dma_capable() can't detect as it only checks for
> addresses bigger then the maximum allowed DMA address.
>
> Fix this by verifying in dma_capable() if the DMA address range provided
> is at any point lower than the minimum possible DMA address on the bus.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
> include/linux/dma-direct.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index adf993a3bd58..6ad9e9ea7564 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -3,6 +3,7 @@
> #define _LINUX_DMA_DIRECT_H 1
>
> #include <linux/dma-mapping.h>
> +#include <linux/memblock.h> /* for min_low_pfn */
> #include <linux/mem_encrypt.h>
>
> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
> if (!dev->dma_mask)
> return false;
>
> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + /* Check if DMA address overflowed */
> + if (min(addr, addr + size - 1) <
> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
> + return false;
> +#endif
> +
> return addr + size - 1 <=
> min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
> }
>

2019-11-07 09:54:30

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>> Hi All,
>>
>> We still have DMA problems with some PCI devices. Since the PowerPC updates
>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to
>> work with our PCI devices. The FSL P5020 and P5040 have these problems
>> currently.
>>
>> Error message:
>>
>> [   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096 of DMA
>> mask ffffffff bus mask df000000
>>
>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting
>> of a Linux userland isn't possible.
>>
>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel
>> 4.20 works with all PCI devices without limitation of RAM.
> Can you send me the .config and a dmesg? And in the meantime try the
> patch below?
>
> ---
> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001
> From: Nicolas Saenz Julienne <[email protected]>
> Date: Fri, 18 Oct 2019 13:00:43 +0200
> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>
> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
> possible for a device configured with 32 bit DMA addresses and a partial
> DMA mapping located at the end of the address space to overflow. It
> happens when a higher physical address, not DMAable, is translated to
> it's DMA counterpart.
>
> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
> an interconnect capable of addressing the lower 1 GB of physical memory
> with a DMA offset of 0xc0000000. It transpires that, any attempt to
> translate physical addresses higher than the first GB will result in an
> overflow which dma_capable() can't detect as it only checks for
> addresses bigger then the maximum allowed DMA address.
>
> Fix this by verifying in dma_capable() if the DMA address range provided
> is at any point lower than the minimum possible DMA address on the bus.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
> include/linux/dma-direct.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index adf993a3bd58..6ad9e9ea7564 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -3,6 +3,7 @@
> #define _LINUX_DMA_DIRECT_H 1
>
> #include <linux/dma-mapping.h>
> +#include <linux/memblock.h> /* for min_low_pfn */
> #include <linux/mem_encrypt.h>
>
> #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
> if (!dev->dma_mask)
> return false;
>
> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + /* Check if DMA address overflowed */
> + if (min(addr, addr + size - 1) <
> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
> + return false;
> +#endif
> +
> return addr + size - 1 <=
> min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
> }
Hello Christoph,

Thanks a lot for your patch! Unfortunately this patch doesn't solve the
issue.

Error messages:

[    6.041163] bttv: driver version 0.9.19 loaded
[    6.041167] bttv: using 8 buffers with 2080k (520 pages) each for capture
[    6.041559] bttv: Bt8xx card found (0)
[    6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19,
latency: 128, mmio: 0xc20001000
[    6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV
Station RDS [card=53,insmod option]
[    6.042216] bttv: 0: tuner type=5
[    6.111994] bttv: 0: audio absent, no audio device found!
[    6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to
100ms)
[    6.200005] bttv: PLL set ok
[    6.209351] bttv: 0: registered device video0
[    6.211576] bttv: 0: registered device vbi0
[    6.214897] bttv: 0: registered device radio0
[  114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of
DMA mask ffffffff bus mask df000000
[  114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types
tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom
videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm
btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc
[  114.219012] [c0000001ecddf720] [80000000008ff6e8]
.buffer_prepare+0x150/0x268 [bttv]
[  114.219029] [c0000001ecddf860] [80000000008fff6c]
.bttv_qbuf+0x50/0x64 [bttv]

-----

Trace:

[  462.783184] Call Trace:
[  462.783187] [c0000001c6c67420] [c0000000000b3358]
.report_addr+0xb8/0xc0 (unreliable)
[  462.783192] [c0000001c6c67490] [c0000000000b351c]
.dma_direct_map_page+0xf0/0x128
[  462.783195] [c0000001c6c67530] [c0000000000b35b0]
.dma_direct_map_sg+0x5c/0xac
[  462.783205] [c0000001c6c675e0] [8000000000862e88]
.__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg]
[  462.783220] [c0000001c6c676b0] [8000000000854274]
.videobuf_iolock+0x98/0xb4 [videobuf_core]
[  462.783271] [c0000001c6c67720] [80000000008686e8]
.buffer_prepare+0x150/0x268 [bttv]
[  462.783276] [c0000001c6c677c0] [8000000000854afc]
.videobuf_qbuf+0x2b8/0x428 [videobuf_core]
[  462.783288] [c0000001c6c67860] [8000000000868f6c]
.bttv_qbuf+0x50/0x64 [bttv]
[  462.783383] [c0000001c6c678e0] [80000000007bf208] .v4l_qbuf+0x54/0x60
[videodev]
[  462.783402] [c0000001c6c67970] [80000000007c1eac]
.__video_do_ioctl+0x30c/0x3f8 [videodev]
[  462.783421] [c0000001c6c67a80] [80000000007c3c08]
.video_usercopy+0x18c/0x3dc [videodev]
[  462.783440] [c0000001c6c67c00] [80000000007bb14c]
.v4l2_ioctl+0x60/0x78 [videodev]
[  462.783460] [c0000001c6c67c90] [80000000007d3c48]
.v4l2_compat_ioctl32+0x9b4/0x1850 [videodev]
[  462.783468] [c0000001c6c67d70] [c0000000001ad9cc]
.__se_compat_sys_ioctl+0x284/0x127c
[  462.783473] [c0000001c6c67e20] [c00000000000067c] system_call+0x60/0x6c
[  462.783475] Instruction dump:
[  462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5
39200001 60000000
[  462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> 38210070
e8010010 7c0803a6
[  462.783490] ---[ end trace b677d4a00458e277 ]---

-----

dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813

Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500
board (CPU: P5040 and P5020):
https://bugzilla.kernel.org/attachment.cgi?id=285815

Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201

Thanks for your help,

Christian

2019-11-10 07:36:03

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
> On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote:
>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>>> Hi All,
>>>
>>> We still have DMA problems with some PCI devices. Since the PowerPC
>>> updates
>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we
>>> want to
>>> work with our PCI devices. The FSL P5020 and P5040 have these problems
>>> currently.
>>>
>>> Error message:
>>>
>>> [   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096
>>> of DMA
>>> mask ffffffff bus mask df000000
>>>
>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so
>>> booting
>>> of a Linux userland isn't possible.
>>>
>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The
>>> kernel
>>> 4.20 works with all PCI devices without limitation of RAM.
>> Can you send me the .config and a dmesg?  And in the meantime try the
>> patch below?
>>
>> ---
>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001
>> From: Nicolas Saenz Julienne <[email protected]>
>> Date: Fri, 18 Oct 2019 13:00:43 +0200
>> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>>
>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is
>> possible for a device configured with 32 bit DMA addresses and a partial
>> DMA mapping located at the end of the address space to overflow. It
>> happens when a higher physical address, not DMAable, is translated to
>> it's DMA counterpart.
>>
>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
>> an interconnect capable of addressing the lower 1 GB of physical memory
>> with a DMA offset of 0xc0000000. It transpires that, any attempt to
>> translate physical addresses higher than the first GB will result in an
>> overflow which dma_capable() can't detect as it only checks for
>> addresses bigger then the maximum allowed DMA address.
>>
>> Fix this by verifying in dma_capable() if the DMA address range provided
>> is at any point lower than the minimum possible DMA address on the bus.
>>
>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>> ---
>>   include/linux/dma-direct.h | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
>> index adf993a3bd58..6ad9e9ea7564 100644
>> --- a/include/linux/dma-direct.h
>> +++ b/include/linux/dma-direct.h
>> @@ -3,6 +3,7 @@
>>   #define _LINUX_DMA_DIRECT_H 1
>>     #include <linux/dma-mapping.h>
>> +#include <linux/memblock.h> /* for min_low_pfn */
>>   #include <linux/mem_encrypt.h>
>>     #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev,
>> dma_addr_t addr, size_t size)
>>       if (!dev->dma_mask)
>>           return false;
>>   +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> +    /* Check if DMA address overflowed */
>> +    if (min(addr, addr + size - 1) <
>> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
>> +        return false;
>> +#endif
>> +
>>       return addr + size - 1 <=
>>           min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
>>   }
> Hello Christoph,
>
> Thanks a lot for your patch! Unfortunately this patch doesn't solve
> the issue.
>
> Error messages:
>
> [    6.041163] bttv: driver version 0.9.19 loaded
> [    6.041167] bttv: using 8 buffers with 2080k (520 pages) each for
> capture
> [    6.041559] bttv: Bt8xx card found (0)
> [    6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19,
> latency: 128, mmio: 0xc20001000
> [    6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV
> Station RDS [card=53,insmod option]
> [    6.042216] bttv: 0: tuner type=5
> [    6.111994] bttv: 0: audio absent, no audio device found!
> [    6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to
> 100ms)
> [    6.200005] bttv: PLL set ok
> [    6.209351] bttv: 0: registered device video0
> [    6.211576] bttv: 0: registered device vbi0
> [    6.214897] bttv: 0: registered device radio0
> [  114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of
> DMA mask ffffffff bus mask df000000
> [  114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types
> tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom
> videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm
> btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc
> [  114.219012] [c0000001ecddf720] [80000000008ff6e8]
> .buffer_prepare+0x150/0x268 [bttv]
> [  114.219029] [c0000001ecddf860] [80000000008fff6c]
> .bttv_qbuf+0x50/0x64 [bttv]
>
> -----
>
> Trace:
>
> [  462.783184] Call Trace:
> [  462.783187] [c0000001c6c67420] [c0000000000b3358]
> .report_addr+0xb8/0xc0 (unreliable)
> [  462.783192] [c0000001c6c67490] [c0000000000b351c]
> .dma_direct_map_page+0xf0/0x128
> [  462.783195] [c0000001c6c67530] [c0000000000b35b0]
> .dma_direct_map_sg+0x5c/0xac
> [  462.783205] [c0000001c6c675e0] [8000000000862e88]
> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg]
> [  462.783220] [c0000001c6c676b0] [8000000000854274]
> .videobuf_iolock+0x98/0xb4 [videobuf_core]
> [  462.783271] [c0000001c6c67720] [80000000008686e8]
> .buffer_prepare+0x150/0x268 [bttv]
> [  462.783276] [c0000001c6c677c0] [8000000000854afc]
> .videobuf_qbuf+0x2b8/0x428 [videobuf_core]
> [  462.783288] [c0000001c6c67860] [8000000000868f6c]
> .bttv_qbuf+0x50/0x64 [bttv]
> [  462.783383] [c0000001c6c678e0] [80000000007bf208]
> .v4l_qbuf+0x54/0x60 [videodev]
> [  462.783402] [c0000001c6c67970] [80000000007c1eac]
> .__video_do_ioctl+0x30c/0x3f8 [videodev]
> [  462.783421] [c0000001c6c67a80] [80000000007c3c08]
> .video_usercopy+0x18c/0x3dc [videodev]
> [  462.783440] [c0000001c6c67c00] [80000000007bb14c]
> .v4l2_ioctl+0x60/0x78 [videodev]
> [  462.783460] [c0000001c6c67c90] [80000000007d3c48]
> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev]
> [  462.783468] [c0000001c6c67d70] [c0000000001ad9cc]
> .__se_compat_sys_ioctl+0x284/0x127c
> [  462.783473] [c0000001c6c67e20] [c00000000000067c]
> system_call+0x60/0x6c
> [  462.783475] Instruction dump:
> [  462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5
> 39200001 60000000
> [  462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000> 38210070
> e8010010 7c0803a6
> [  462.783490] ---[ end trace b677d4a00458e277 ]---
>
> -----
>
> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813
>
> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500
> board (CPU: P5040 and P5020):
> https://bugzilla.kernel.org/attachment.cgi?id=285815
>
> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201
>
> Thanks for your help,
>
> Christian

Christoph,

Do you have another patch for testing or shall I bisect?

Thanks,
Christian

2019-11-11 08:13:32

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
> On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
>> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
>>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>>>> Hi All,
>>>>
>>>> We still have DMA problems with some PCI devices. Since the PowerPC
>>>> updates
>>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we
>>>> want to
>>>> work with our PCI devices. The FSL P5020 and P5040 have these problems
>>>> currently.
>>>>
>>>> Error message:
>>>>
>>>> [   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096
>>>> of DMA
>>>> mask ffffffff bus mask df000000
>>>>
>>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so
>>>> booting
>>>> of a Linux userland isn't possible.
>>>>
>>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The
>>>> kernel
>>>> 4.20 works with all PCI devices without limitation of RAM.
>>> Can you send me the .config and a dmesg?  And in the meantime try the
>>> patch below?
>>>
>>> ---
>>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001
>>> From: Nicolas Saenz Julienne <[email protected]>
>>> Date: Fri, 18 Oct 2019 13:00:43 +0200
>>> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>>>
>>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation
>>> it is
>>> possible for a device configured with 32 bit DMA addresses and a
>>> partial
>>> DMA mapping located at the end of the address space to overflow. It
>>> happens when a higher physical address, not DMAable, is translated to
>>> it's DMA counterpart.
>>>
>>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
>>> an interconnect capable of addressing the lower 1 GB of physical memory
>>> with a DMA offset of 0xc0000000. It transpires that, any attempt to
>>> translate physical addresses higher than the first GB will result in an
>>> overflow which dma_capable() can't detect as it only checks for
>>> addresses bigger then the maximum allowed DMA address.
>>>
>>> Fix this by verifying in dma_capable() if the DMA address range
>>> provided
>>> is at any point lower than the minimum possible DMA address on the bus.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>>> ---
>>>   include/linux/dma-direct.h | 8 ++++++++
>>>   1 file changed, 8 insertions(+)
>>>
>>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
>>> index adf993a3bd58..6ad9e9ea7564 100644
>>> --- a/include/linux/dma-direct.h
>>> +++ b/include/linux/dma-direct.h
>>> @@ -3,6 +3,7 @@
>>>   #define _LINUX_DMA_DIRECT_H 1
>>>     #include <linux/dma-mapping.h>
>>> +#include <linux/memblock.h> /* for min_low_pfn */
>>>   #include <linux/mem_encrypt.h>
>>>     #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
>>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device
>>> *dev, dma_addr_t addr, size_t size)
>>>       if (!dev->dma_mask)
>>>           return false;
>>>   +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> +    /* Check if DMA address overflowed */
>>> +    if (min(addr, addr + size - 1) <
>>> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
>>> +        return false;
>>> +#endif
>>> +
>>>       return addr + size - 1 <=
>>>           min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
>>>   }
>> Hello Christoph,
>>
>> Thanks a lot for your patch! Unfortunately this patch doesn't solve
>> the issue.
>>
>> Error messages:
>>
>> [    6.041163] bttv: driver version 0.9.19 loaded
>> [    6.041167] bttv: using 8 buffers with 2080k (520 pages) each for
>> capture
>> [    6.041559] bttv: Bt8xx card found (0)
>> [    6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19,
>> latency: 128, mmio: 0xc20001000
>> [    6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1
>> TV Station RDS [card=53,insmod option]
>> [    6.042216] bttv: 0: tuner type=5
>> [    6.111994] bttv: 0: audio absent, no audio device found!
>> [    6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up
>> to 100ms)
>> [    6.200005] bttv: PLL set ok
>> [    6.209351] bttv: 0: registered device video0
>> [    6.211576] bttv: 0: registered device vbi0
>> [    6.214897] bttv: 0: registered device radio0
>> [  114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096 of
>> DMA mask ffffffff bus mask df000000
>> [  114.218848] Modules linked in: rfcomm bnep tuner_simple
>> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x
>> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb
>> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc
>> [  114.219012] [c0000001ecddf720] [80000000008ff6e8]
>> .buffer_prepare+0x150/0x268 [bttv]
>> [  114.219029] [c0000001ecddf860] [80000000008fff6c]
>> .bttv_qbuf+0x50/0x64 [bttv]
>>
>> -----
>>
>> Trace:
>>
>> [  462.783184] Call Trace:
>> [  462.783187] [c0000001c6c67420] [c0000000000b3358]
>> .report_addr+0xb8/0xc0 (unreliable)
>> [  462.783192] [c0000001c6c67490] [c0000000000b351c]
>> .dma_direct_map_page+0xf0/0x128
>> [  462.783195] [c0000001c6c67530] [c0000000000b35b0]
>> .dma_direct_map_sg+0x5c/0xac
>> [  462.783205] [c0000001c6c675e0] [8000000000862e88]
>> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg]
>> [  462.783220] [c0000001c6c676b0] [8000000000854274]
>> .videobuf_iolock+0x98/0xb4 [videobuf_core]
>> [  462.783271] [c0000001c6c67720] [80000000008686e8]
>> .buffer_prepare+0x150/0x268 [bttv]
>> [  462.783276] [c0000001c6c677c0] [8000000000854afc]
>> .videobuf_qbuf+0x2b8/0x428 [videobuf_core]
>> [  462.783288] [c0000001c6c67860] [8000000000868f6c]
>> .bttv_qbuf+0x50/0x64 [bttv]
>> [  462.783383] [c0000001c6c678e0] [80000000007bf208]
>> .v4l_qbuf+0x54/0x60 [videodev]
>> [  462.783402] [c0000001c6c67970] [80000000007c1eac]
>> .__video_do_ioctl+0x30c/0x3f8 [videodev]
>> [  462.783421] [c0000001c6c67a80] [80000000007c3c08]
>> .video_usercopy+0x18c/0x3dc [videodev]
>> [  462.783440] [c0000001c6c67c00] [80000000007bb14c]
>> .v4l2_ioctl+0x60/0x78 [videodev]
>> [  462.783460] [c0000001c6c67c90] [80000000007d3c48]
>> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev]
>> [  462.783468] [c0000001c6c67d70] [c0000000001ad9cc]
>> .__se_compat_sys_ioctl+0x284/0x127c
>> [  462.783473] [c0000001c6c67e20] [c00000000000067c]
>> system_call+0x60/0x6c
>> [  462.783475] Instruction dump:
>> [  462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5
>> 39200001 60000000
>> [  462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000>
>> 38210070 e8010010 7c0803a6
>> [  462.783490] ---[ end trace b677d4a00458e277 ]---
>>
>> -----
>>
>> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813
>>
>> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500
>> board (CPU: P5040 and P5020):
>> https://bugzilla.kernel.org/attachment.cgi?id=285815
>>
>> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201
>>
>> Thanks for your help,
>>
>> Christian
>
> Christoph,
>
> Do you have another patch for testing or shall I bisect?
>
> Thanks,
> Christian

Hi Christoph,

I have seen that I have activated the kernel config option
CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't
work if this kernel option is enabled.

+#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
+    /* Check if DMA address overflowed */
+    if (min(addr, addr + size - 1) <
+        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
+        return false;
+#endif

I will delete the lines with ifndef and endif and will try it again.

Cheers,
Christian

2019-11-11 08:18:43

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
> On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
>> On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
>>> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
>>>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>>>>> Hi All,
>>>>>
>>>>> We still have DMA problems with some PCI devices. Since the
>>>>> PowerPC updates
>>>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we
>>>>> want to
>>>>> work with our PCI devices. The FSL P5020 and P5040 have these
>>>>> problems
>>>>> currently.
>>>>>
>>>>> Error message:
>>>>>
>>>>> [   25.654852] bttv 1000:04:05.0: overflow 0x00000000fe077000+4096
>>>>> of DMA
>>>>> mask ffffffff bus mask df000000
>>>>>
>>>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so
>>>>> booting
>>>>> of a Linux userland isn't possible.
>>>>>
>>>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1].
>>>>> The kernel
>>>>> 4.20 works with all PCI devices without limitation of RAM.
>>>> Can you send me the .config and a dmesg?  And in the meantime try the
>>>> patch below?
>>>>
>>>> ---
>>>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00
>>>> 2001
>>>> From: Nicolas Saenz Julienne <[email protected]>
>>>> Date: Fri, 18 Oct 2019 13:00:43 +0200
>>>> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>>>>
>>>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation
>>>> it is
>>>> possible for a device configured with 32 bit DMA addresses and a
>>>> partial
>>>> DMA mapping located at the end of the address space to overflow. It
>>>> happens when a higher physical address, not DMAable, is translated to
>>>> it's DMA counterpart.
>>>>
>>>> For example the Raspberry Pi 4, configurable up to 4 GB of memory, has
>>>> an interconnect capable of addressing the lower 1 GB of physical
>>>> memory
>>>> with a DMA offset of 0xc0000000. It transpires that, any attempt to
>>>> translate physical addresses higher than the first GB will result
>>>> in an
>>>> overflow which dma_capable() can't detect as it only checks for
>>>> addresses bigger then the maximum allowed DMA address.
>>>>
>>>> Fix this by verifying in dma_capable() if the DMA address range
>>>> provided
>>>> is at any point lower than the minimum possible DMA address on the
>>>> bus.
>>>>
>>>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>>>> ---
>>>>   include/linux/dma-direct.h | 8 ++++++++
>>>>   1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
>>>> index adf993a3bd58..6ad9e9ea7564 100644
>>>> --- a/include/linux/dma-direct.h
>>>> +++ b/include/linux/dma-direct.h
>>>> @@ -3,6 +3,7 @@
>>>>   #define _LINUX_DMA_DIRECT_H 1
>>>>     #include <linux/dma-mapping.h>
>>>> +#include <linux/memblock.h> /* for min_low_pfn */
>>>>   #include <linux/mem_encrypt.h>
>>>>     #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
>>>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device
>>>> *dev, dma_addr_t addr, size_t size)
>>>>       if (!dev->dma_mask)
>>>>           return false;
>>>>   +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>> +    /* Check if DMA address overflowed */
>>>> +    if (min(addr, addr + size - 1) <
>>>> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
>>>> +        return false;
>>>> +#endif
>>>> +
>>>>       return addr + size - 1 <=
>>>>           min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
>>>>   }
>>> Hello Christoph,
>>>
>>> Thanks a lot for your patch! Unfortunately this patch doesn't solve
>>> the issue.
>>>
>>> Error messages:
>>>
>>> [    6.041163] bttv: driver version 0.9.19 loaded
>>> [    6.041167] bttv: using 8 buffers with 2080k (520 pages) each for
>>> capture
>>> [    6.041559] bttv: Bt8xx card found (0)
>>> [    6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19,
>>> latency: 128, mmio: 0xc20001000
>>> [    6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1
>>> TV Station RDS [card=53,insmod option]
>>> [    6.042216] bttv: 0: tuner type=5
>>> [    6.111994] bttv: 0: audio absent, no audio device found!
>>> [    6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up
>>> to 100ms)
>>> [    6.200005] bttv: PLL set ok
>>> [    6.209351] bttv: 0: registered device video0
>>> [    6.211576] bttv: 0: registered device vbi0
>>> [    6.214897] bttv: 0: registered device radio0
>>> [  114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096
>>> of DMA mask ffffffff bus mask df000000
>>> [  114.218848] Modules linked in: rfcomm bnep tuner_simple
>>> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x
>>> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb
>>> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc
>>> [  114.219012] [c0000001ecddf720] [80000000008ff6e8]
>>> .buffer_prepare+0x150/0x268 [bttv]
>>> [  114.219029] [c0000001ecddf860] [80000000008fff6c]
>>> .bttv_qbuf+0x50/0x64 [bttv]
>>>
>>> -----
>>>
>>> Trace:
>>>
>>> [  462.783184] Call Trace:
>>> [  462.783187] [c0000001c6c67420] [c0000000000b3358]
>>> .report_addr+0xb8/0xc0 (unreliable)
>>> [  462.783192] [c0000001c6c67490] [c0000000000b351c]
>>> .dma_direct_map_page+0xf0/0x128
>>> [  462.783195] [c0000001c6c67530] [c0000000000b35b0]
>>> .dma_direct_map_sg+0x5c/0xac
>>> [  462.783205] [c0000001c6c675e0] [8000000000862e88]
>>> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg]
>>> [  462.783220] [c0000001c6c676b0] [8000000000854274]
>>> .videobuf_iolock+0x98/0xb4 [videobuf_core]
>>> [  462.783271] [c0000001c6c67720] [80000000008686e8]
>>> .buffer_prepare+0x150/0x268 [bttv]
>>> [  462.783276] [c0000001c6c677c0] [8000000000854afc]
>>> .videobuf_qbuf+0x2b8/0x428 [videobuf_core]
>>> [  462.783288] [c0000001c6c67860] [8000000000868f6c]
>>> .bttv_qbuf+0x50/0x64 [bttv]
>>> [  462.783383] [c0000001c6c678e0] [80000000007bf208]
>>> .v4l_qbuf+0x54/0x60 [videodev]
>>> [  462.783402] [c0000001c6c67970] [80000000007c1eac]
>>> .__video_do_ioctl+0x30c/0x3f8 [videodev]
>>> [  462.783421] [c0000001c6c67a80] [80000000007c3c08]
>>> .video_usercopy+0x18c/0x3dc [videodev]
>>> [  462.783440] [c0000001c6c67c00] [80000000007bb14c]
>>> .v4l2_ioctl+0x60/0x78 [videodev]
>>> [  462.783460] [c0000001c6c67c90] [80000000007d3c48]
>>> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev]
>>> [  462.783468] [c0000001c6c67d70] [c0000000001ad9cc]
>>> .__se_compat_sys_ioctl+0x284/0x127c
>>> [  462.783473] [c0000001c6c67e20] [c00000000000067c]
>>> system_call+0x60/0x6c
>>> [  462.783475] Instruction dump:
>>> [  462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020 3c82ffc5
>>> 39200001 60000000
>>> [  462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000>
>>> 38210070 e8010010 7c0803a6
>>> [  462.783490] ---[ end trace b677d4a00458e277 ]---
>>>
>>> -----
>>>
>>> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813
>>>
>>> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500
>>> board (CPU: P5040 and P5020):
>>> https://bugzilla.kernel.org/attachment.cgi?id=285815
>>>
>>> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201
>>>
>>> Thanks for your help,
>>>
>>> Christian
>>
>> Christoph,
>>
>> Do you have another patch for testing or shall I bisect?
>>
>> Thanks,
>> Christian
>
> Hi Christoph,
>
> I have seen that I have activated the kernel config option
> CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't
> work if this kernel option is enabled.
>
> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
> +    /* Check if DMA address overflowed */
> +    if (min(addr, addr + size - 1) <
> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
> +        return false;
> +#endif
>
> I will delete the lines with ifndef and endif and will try it again.
>
> Cheers,
> Christian

Christoph,

I have seen that the patch above isn't from you. It's from Nicolas Saenz
Julienne.

Cheers,
Christian

2019-11-11 12:26:10

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 11 November 2019 at 09:16 am, Christian Zigotzky wrote:
> On 11 November 2019 at 09:12 am, Christian Zigotzky wrote:
>> On 10 November 2019 at 08:27 am, Christian Zigotzky wrote:
>>> On 07 November 2019 at 10:53 am, Christian Zigotzky wrote:
>>>> On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote:
>>>>> On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> We still have DMA problems with some PCI devices. Since the
>>>>>> PowerPC updates
>>>>>> 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if
>>>>>> we want to
>>>>>> work with our PCI devices. The FSL P5020 and P5040 have these
>>>>>> problems
>>>>>> currently.
>>>>>>
>>>>>> Error message:
>>>>>>
>>>>>> [   25.654852] bttv 1000:04:05.0: overflow
>>>>>> 0x00000000fe077000+4096 of DMA
>>>>>> mask ffffffff bus mask df000000
>>>>>>
>>>>>> All 5.x Linux kernels can't initialize a SCSI PCI card anymore so
>>>>>> booting
>>>>>> of a Linux userland isn't possible.
>>>>>>
>>>>>> PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1].
>>>>>> The kernel
>>>>>> 4.20 works with all PCI devices without limitation of RAM.
>>>>> Can you send me the .config and a dmesg?  And in the meantime try the
>>>>> patch below?
>>>>>
>>>>> ---
>>>>> >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00
>>>>> 2001
>>>>> From: Nicolas Saenz Julienne <[email protected]>
>>>>> Date: Fri, 18 Oct 2019 13:00:43 +0200
>>>>> Subject: dma-direct: check for overflows on 32 bit DMA addresses
>>>>>
>>>>> As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation
>>>>> it is
>>>>> possible for a device configured with 32 bit DMA addresses and a
>>>>> partial
>>>>> DMA mapping located at the end of the address space to overflow. It
>>>>> happens when a higher physical address, not DMAable, is translated to
>>>>> it's DMA counterpart.
>>>>>
>>>>> For example the Raspberry Pi 4, configurable up to 4 GB of memory,
>>>>> has
>>>>> an interconnect capable of addressing the lower 1 GB of physical
>>>>> memory
>>>>> with a DMA offset of 0xc0000000. It transpires that, any attempt to
>>>>> translate physical addresses higher than the first GB will result
>>>>> in an
>>>>> overflow which dma_capable() can't detect as it only checks for
>>>>> addresses bigger then the maximum allowed DMA address.
>>>>>
>>>>> Fix this by verifying in dma_capable() if the DMA address range
>>>>> provided
>>>>> is at any point lower than the minimum possible DMA address on the
>>>>> bus.
>>>>>
>>>>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>>>>> ---
>>>>>   include/linux/dma-direct.h | 8 ++++++++
>>>>>   1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
>>>>> index adf993a3bd58..6ad9e9ea7564 100644
>>>>> --- a/include/linux/dma-direct.h
>>>>> +++ b/include/linux/dma-direct.h
>>>>> @@ -3,6 +3,7 @@
>>>>>   #define _LINUX_DMA_DIRECT_H 1
>>>>>     #include <linux/dma-mapping.h>
>>>>> +#include <linux/memblock.h> /* for min_low_pfn */
>>>>>   #include <linux/mem_encrypt.h>
>>>>>     #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA
>>>>> @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device
>>>>> *dev, dma_addr_t addr, size_t size)
>>>>>       if (!dev->dma_mask)
>>>>>           return false;
>>>>>   +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>>> +    /* Check if DMA address overflowed */
>>>>> +    if (min(addr, addr + size - 1) <
>>>>> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn <<
>>>>> PAGE_SHIFT)))
>>>>> +        return false;
>>>>> +#endif
>>>>> +
>>>>>       return addr + size - 1 <=
>>>>>           min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
>>>>>   }
>>>> Hello Christoph,
>>>>
>>>> Thanks a lot for your patch! Unfortunately this patch doesn't solve
>>>> the issue.
>>>>
>>>> Error messages:
>>>>
>>>> [    6.041163] bttv: driver version 0.9.19 loaded
>>>> [    6.041167] bttv: using 8 buffers with 2080k (520 pages) each
>>>> for capture
>>>> [    6.041559] bttv: Bt8xx card found (0)
>>>> [    6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19,
>>>> latency: 128, mmio: 0xc20001000
>>>> [    6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1
>>>> TV Station RDS [card=53,insmod option]
>>>> [    6.042216] bttv: 0: tuner type=5
>>>> [    6.111994] bttv: 0: audio absent, no audio device found!
>>>> [    6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up
>>>> to 100ms)
>>>> [    6.200005] bttv: PLL set ok
>>>> [    6.209351] bttv: 0: registered device video0
>>>> [    6.211576] bttv: 0: registered device vbi0
>>>> [    6.214897] bttv: 0: registered device radio0
>>>> [  114.218806] bttv 1000:04:05.0: overflow 0x00000000ff507000+4096
>>>> of DMA mask ffffffff bus mask df000000
>>>> [  114.218848] Modules linked in: rfcomm bnep tuner_simple
>>>> tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x
>>>> tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb
>>>> btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc
>>>> [  114.219012] [c0000001ecddf720] [80000000008ff6e8]
>>>> .buffer_prepare+0x150/0x268 [bttv]
>>>> [  114.219029] [c0000001ecddf860] [80000000008fff6c]
>>>> .bttv_qbuf+0x50/0x64 [bttv]
>>>>
>>>> -----
>>>>
>>>> Trace:
>>>>
>>>> [  462.783184] Call Trace:
>>>> [  462.783187] [c0000001c6c67420] [c0000000000b3358]
>>>> .report_addr+0xb8/0xc0 (unreliable)
>>>> [  462.783192] [c0000001c6c67490] [c0000000000b351c]
>>>> .dma_direct_map_page+0xf0/0x128
>>>> [  462.783195] [c0000001c6c67530] [c0000000000b35b0]
>>>> .dma_direct_map_sg+0x5c/0xac
>>>> [  462.783205] [c0000001c6c675e0] [8000000000862e88]
>>>> .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg]
>>>> [  462.783220] [c0000001c6c676b0] [8000000000854274]
>>>> .videobuf_iolock+0x98/0xb4 [videobuf_core]
>>>> [  462.783271] [c0000001c6c67720] [80000000008686e8]
>>>> .buffer_prepare+0x150/0x268 [bttv]
>>>> [  462.783276] [c0000001c6c677c0] [8000000000854afc]
>>>> .videobuf_qbuf+0x2b8/0x428 [videobuf_core]
>>>> [  462.783288] [c0000001c6c67860] [8000000000868f6c]
>>>> .bttv_qbuf+0x50/0x64 [bttv]
>>>> [  462.783383] [c0000001c6c678e0] [80000000007bf208]
>>>> .v4l_qbuf+0x54/0x60 [videodev]
>>>> [  462.783402] [c0000001c6c67970] [80000000007c1eac]
>>>> .__video_do_ioctl+0x30c/0x3f8 [videodev]
>>>> [  462.783421] [c0000001c6c67a80] [80000000007c3c08]
>>>> .video_usercopy+0x18c/0x3dc [videodev]
>>>> [  462.783440] [c0000001c6c67c00] [80000000007bb14c]
>>>> .v4l2_ioctl+0x60/0x78 [videodev]
>>>> [  462.783460] [c0000001c6c67c90] [80000000007d3c48]
>>>> .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev]
>>>> [  462.783468] [c0000001c6c67d70] [c0000000001ad9cc]
>>>> .__se_compat_sys_ioctl+0x284/0x127c
>>>> [  462.783473] [c0000001c6c67e20] [c00000000000067c]
>>>> system_call+0x60/0x6c
>>>> [  462.783475] Instruction dump:
>>>> [  462.783477] 40fe0044 60000000 892255d0 2f890000 40fe0020
>>>> 3c82ffc5 39200001 60000000
>>>> [  462.783483] 38842029 992255d0 485ad0d9 60000000 <0fe00000>
>>>> 38210070 e8010010 7c0803a6
>>>> [  462.783490] ---[ end trace b677d4a00458e277 ]---
>>>>
>>>> -----
>>>>
>>>> dmesg fsl p5040: https://bugzilla.kernel.org/attachment.cgi?id=285813
>>>>
>>>> Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500
>>>> board (CPU: P5040 and P5020):
>>>> https://bugzilla.kernel.org/attachment.cgi?id=285815
>>>>
>>>> Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=205201
>>>>
>>>> Thanks for your help,
>>>>
>>>> Christian
>>>
>>> Christoph,
>>>
>>> Do you have another patch for testing or shall I bisect?
>>>
>>> Thanks,
>>> Christian
>>
>> Hi Christoph,
>>
>> I have seen that I have activated the kernel config option
>> CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch
>> won't work if this kernel option is enabled.
>>
>> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> +    /* Check if DMA address overflowed */
>> +    if (min(addr, addr + size - 1) <
>> +        __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
>> +        return false;
>> +#endif
>>
>> I will delete the lines with ifndef and endif and will try it again.
>>
>> Cheers,
>> Christian
>
> Christoph,
>
> I have seen that the patch above isn't from you. It's from Nicolas
> Saenz Julienne.
>
> Cheers,
> Christian

Christoph,

Now, I can definitely say that this patch does not solve the issue.

Do you have another patch for testing or shall I bisect?

Thanks,
Christian

2019-11-12 14:45:02

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
> Now, I can definitely say that this patch does not solve the issue.
>
> Do you have another patch for testing or shall I bisect?

I'm still interested in the .config and dmesg. Especially if the
board is using arch/powerpc/sysdev/fsl_pci.c, which is the only
place inside the powerpc arch code doing funny things with the
bus_dma_mask, which Robin pointed out looks fishy.

>
> Thanks,
> Christian
---end quoted text---

2019-11-12 22:59:31

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
> On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
>> Now, I can definitely say that this patch does not solve the issue.
>>
>> Do you have another patch for testing or shall I bisect?
> I'm still interested in the .config and dmesg. Especially if the
> board is using arch/powerpc/sysdev/fsl_pci.c, which is the only
> place inside the powerpc arch code doing funny things with the
> bus_dma_mask, which Robin pointed out looks fishy.
>
Here you are:

.config: https://bugzilla.kernel.org/attachment.cgi?id=285815

dmesg: https://bugzilla.kernel.org/attachment.cgi?id=285813

Thanks

2019-11-13 10:18:04

by Christian Zigotzky

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

Hello Christoph,

I have found the issue. :-)

GFP_DMA32 was renamed to GFP_DMA in the PowerPC updates 4.21-1 in
December last year.

Some PCI devices still use GFP_DMA32 (grep -r GFP_DMA32 *). I renamed
GFP_DMA32 to GFP_DMA in the file
"drivers/media/v4l2-core/videobuf-dma-sg.c". After compiling the RC7 of
kernel 5.4 my TV card works again.

Cheers,
Christian


On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote:
> On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote:
>> Now, I can definitely say that this patch does not solve the issue.
>>
>> Do you have another patch for testing or shall I bisect?
> I'm still interested in the .config and dmesg. Especially if the
> board is using arch/powerpc/sysdev/fsl_pci.c, which is the only
> place inside the powerpc arch code doing funny things with the
> bus_dma_mask, which Robin pointed out looks fishy.
>
>> Thanks,
>> Christian
> ---end quoted text---
>

2019-11-13 11:03:19

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

Interesting. Give me some time to come up with a real fix, as drivers
really should not mess with GFP flags for these allocations, and even
if they did swiotlb is supposed to take care of any resulting problems.

2019-11-21 17:28:46

by Christoph Hellwig

[permalink] [raw]
Subject: Re: Bug 205201 - overflow of DMA mask and bus mask

On Wed, Nov 06, 2019 at 02:09:26PM +0000, Robin Murphy wrote:
> Hmm, that bus mask looks pretty wacky - are you able to figure out where
> that's coming from?

arch/powerpc/sysdev/fsl_pci.c:pci_dma_dev_setup_swiotlb().

2019-12-19 13:57:13

by Christian Zigotzky

[permalink] [raw]
Subject: Re: use generic DMA mapping code in powerpc V4

Hi All,

We still have some issues with PCI cards in our FSL P5020 and P5040
systems since the DMA mapping updates. [1, 2]

We have to limit the RAM to 3500MB for some problematic PCI cards.
(kernel boot argument 'mem=3500M')

The problematic DMA mapping code was added with the PowerPC updates
4.21-1 to the official kernel source code last year. [3]

We have created a bug report. [4]

The old 4.x kernels aren't affected because they use the old DMA code.

Please check the new DMA code again.

Thanks,
Christian

[1]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58&p=49486#p49486
[2]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4349&start=50#p49099
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2
[4] https://bugzilla.kernel.org/show_bug.cgi?id=205201


On 28 November 2018 at 4:55 pm, Christian Zigotzky wrote:
> On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
>> Nothing specific yet.
>>
>> I'm a bit worried it might break one of the many old obscure platforms
>> we have that aren't well tested.
>>
> Please don't apply the new DMA mapping code if you don't be sure if it
> works on all supported PowerPC machines. Is the new DMA mapping code
> really necessary? It's not really nice, to rewrote code if the old
> code works perfect. We must not forget, that we work for the end
> users. Does the end user have advantages with this new code? Is it
> faster? The old code works without any problems. I am also worried
> about this code. How can I test this new DMA mapping code?
>
> Thanks
>
>