From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:23:42
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.
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:23:43
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:23:55
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 <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
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(-)
@@ -47,7 +47,7 @@ static int __init warp_probe(void)if(!of_machine_is_compatible("pika,warp"))return0;-/* For __dma_alloc_coherent */+/* For __dma_nommu_alloc_coherent */ISA_DMA_THRESHOLD=~0L;return1;
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:23:57
These methods are optional, no need to implement no-op versions.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 16 ----------------
1 file changed, 16 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:23:59
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:00
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 <hch@lst.de>
---
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(-)
@@ -6,12 +6,30 @@*bussesusingtheiommuinfrastructure*/+#include<linux/dma-direct.h>+#include<linux/pci.h>#include<asm/iommu.h>/**Genericiommuimplementation*/+/*+*Thecoherentmaskmaybesmallerthantherealmask,checkifwecan+*reallyuseadirectwindow.+*/+staticinlinebooldma_iommu_alloc_bypass(structdevice*dev)+{+returndev->archdata.iommu_bypass&&+dma_nommu_dma_supported(dev,dev->coherent_dma_mask);+}++staticinlinebooldma_iommu_map_bypass(structdevice*dev,+unsignedlongattrs)+{+returndev->archdata.iommu_bypass;+}+/* Allocates a contiguous real buffer and creates mappings over it.*Returnsthevirtualaddressofthebufferandsetsdma_handle*tothedmaaddress(mapping)ofthefirstpage.
@@ -29,7 +50,11 @@ static void dma_iommu_free_coherent(struct device *dev, size_t size,void*vaddr,dma_addr_tdma_handle,unsignedlongattrs){-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
@@ -68,10 +99,20 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,intnelems,enumdma_data_directiondirection,unsignedlongattrs){-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);}+staticbooldma_iommu_bypass_supported(structdevice*dev,u64mask)+{+structpci_dev*pdev=to_pci_dev(dev);+structpci_controller*phb=pci_bus_to_host(pdev->bus);++returnphb->controller_ops.iommu_bypass_supported&&+phb->controller_ops.iommu_bypass_supported(pdev,mask);+}+/* We support DMA to/from any memory page via the iommu */intdma_iommu_dma_supported(structdevice*dev,u64mask){
@@ -83,22 +124,39 @@ int dma_iommu_dma_supported(struct device *dev, u64 mask)return0;}+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");+return1;+}+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);return0;-}else-return1;+}++dev_dbg(dev,"iommu: not 64-bit, using default ops\n");+dev->archdata.iommu_bypass=false;+return1;}u64dma_iommu_get_required_mask(structdevice*dev){structiommu_table*tbl=get_iommu_table_base(dev);u64mask;+if(!tbl)return0;+if(dev_is_pci(dev)){+u64bypass_mask=dma_nommu_get_required_mask(dev);++if(dma_iommu_bypass_supported(dev,bypass_mask))+returnbypass_mask;+}+mask=1ULL<(fls_long(tbl->it_offset+tbl->it_size)-1);mask+=mask-1;
@@ -1193,87 +1193,40 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)iommu_add_device(&dev->dev);}-staticintdma_set_mask_pSeriesLP(structdevice*dev,u64dma_mask)+staticbooliommu_bypass_supported_pSeriesLP(structpci_dev*pdev,u64dma_mask){-boolddw_enabled=false;-structdevice_node*pdn,*dn;-structpci_dev*pdev;+structdevice_node*dn=pci_device_to_OF_node(pdev),*pdn;const__be32*dma_window=NULL;u64dma_offset;-if(!dev->dma_mask)-return-EIO;--if(!dev_is_pci(dev))-gotocheck_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))+returnfalse;-/*-*thedevicetreemightcontainthedma-windowproperties-*per-deviceandnotnecessarilyforthebus.Soweneedto-*searchupwardsinthetreeuntilweeitherhitadma-window-*property,ORfindaparentwithatablealreadyallocated.-*/-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);+/*+*thedevicetreemightcontainthedma-windowproperties+*per-deviceandnotnecessarilyforthebus.Soweneedto+*searchupwardsinthetreeuntilweeitherhitadma-window+*property,ORfindaparentwithatablealreadyallocated.+*/+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;-return0;-}--staticu64dma_get_required_mask_pSeriesLP(structdevice*dev)-{-if(!dev->dma_mask)-return0;--if(!disable_ddw&&dev_is_pci(dev)){-structpci_dev*pdev=to_pci_dev(dev);-structdevice_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))-returnDMA_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);+returntrue;+}}-returndma_iommu_get_required_mask(dev);+returnfalse;}staticintiommu_mem_notifier(structnotifier_block*nb,unsignedlongaction,
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:17
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 <hch@lst.de>
---
arch/powerpc/platforms/cell/iommu.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:21
This gets rid of a lot of clumsy code and finally allows us to mark
dma_iommu_ops const.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
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(-)
@@ -20,14 +20,15 @@*/staticinlinebooldma_iommu_alloc_bypass(structdevice*dev){-returndev->archdata.iommu_bypass&&+returndev->archdata.iommu_bypass&&!iommu_fixed_is_weak&&dma_nommu_dma_supported(dev,dev->coherent_dma_mask);}staticinlinebooldma_iommu_map_bypass(structdevice*dev,unsignedlongattrs){-returndev->archdata.iommu_bypass;+returndev->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)returndma_addr==IOMMU_MAPPING_ERROR;}-structdma_map_opsdma_iommu_ops={+conststructdma_map_opsdma_iommu_ops={.alloc=dma_iommu_alloc_coherent,.free=dma_iommu_free_coherent,.mmap=dma_nommu_mmap_coherent,
@@ -546,7 +546,7 @@ static unsigned long cell_dma_nommu_offset;staticunsignedlongdma_iommu_fixed_base;/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */-staticintiommu_fixed_is_weak;+booliommu_fixed_is_weak;staticstructiommu_table*cell_get_iommu_table(structdevice*dev){
@@ -953,22 +864,10 @@ static u64 cell_iommu_get_fixed_address(struct device *dev)returndev_addr;}-staticintdma_suported_and_switch(structdevice*dev,u64dma_mask)+staticboolcell_pci_iommu_bypass_supported(structpci_dev*pdev,u64mask){-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);-return1;-}--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);-return1;-}--return0;+returnmask==DMA_BIT_MASK(64)&&+cell_iommu_get_fixed_address(&pdev->dev)!=OF_BAD_ADDR;}staticvoidinsert_16M_pte(unsignedlongaddr,unsignedlong*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);-return0;}
@@ -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);-staticu64cell_dma_get_required_mask(structdevice*dev)-{-conststructdma_map_ops*dma_ops;--if(!dev->dma_mask)-return0;--if(!iommu_fixed_disabled&&-cell_iommu_get_fixed_address(dev)!=OF_BAD_ADDR)-returnDMA_BIT_MASK(64);--dma_ops=get_dma_ops(dev);-if(dma_ops->get_required_mask)-returndma_ops->get_required_mask(dev);--WARN_ONCE(1,"no get_required_mask in %p ops",dma_ops);--returnDMA_BIT_MASK(64);-}-staticint__initcell_iommu_init(void){structdevice_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)-gotobail;+gotodone;/* Create an iommu for each /axon node. */for_each_node_by_name(np,"axon"){
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:22
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 <hch@lst.de>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 ---------
1 file changed, 9 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:23
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 <hch@lst.de>
---
arch/powerpc/sysdev/dart_iommu.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
@@ -390,27 +383,16 @@ static bool dart_device_on_pcie(struct device *dev)returnfalse;}-staticintdart_dma_set_mask(structdevice*dev,u64dma_mask)+staticvoidpci_dma_dev_setup_dart(structpci_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-*devicestoimproveperformances.However,thatonlyworks-*fordevicesconnectedtoU4ownPCIeinterface,notbridged-*throughhypertransport.Weneedthedevicetosupportat-*least40bitsofaddresses.-*/-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;-return0;+staticbooliommu_bypass_supported_dart(structpci_dev*dev,u64mask)+{+returndart_is_u4&&dart_device_on_pcie(&dev->dev);}void__initiommu_init_early_dart(structpci_controller_ops*controller_ops)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:26
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 <hch@lst.de>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 ++---------------------
1 file changed, 2 insertions(+), 26 deletions(-)
@@ -1745,31 +1745,6 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev*/}-staticboolpnv_pci_ioda_pe_single_vendor(structpnv_ioda_pe*pe)-{-unsignedshortvendor=0;-structpci_dev*pdev;--if(pe->device_count==1)-returntrue;--/* pe->pdev should be set if it's a single device, pe->pbus if not */-if(!pe->pbus)-returntrue;--list_for_each_entry(pdev,&pe->pbus->devices,bus_list){-if(!vendor){-vendor=pdev->vendor;-continue;-}--if(pdev->vendor!=vendor)-returnfalse;-}--returntrue;-}-/**ReconfigureTVE#0tobeusableas64-bitDMAspace.*
@@ -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);
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:29
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 <hch@lst.de>
---
arch/powerpc/Kconfig | 4 ---
arch/powerpc/kernel/dma.c | 68 ++-------------------------------------
2 files changed, 2 insertions(+), 70 deletions(-)
@@ -114,51 +114,6 @@ void __dma_nommu_free_coherent(struct device *dev, size_t size,}#endif /* !CONFIG_NOT_COHERENT_CACHE */-staticvoid*dma_nommu_alloc_coherent(structdevice*dev,size_tsize,-dma_addr_t*dma_handle,gfp_tflag,-unsignedlongattrs)-{-structiommu_table*iommu;--/* The coherent mask may be smaller than the real mask, check if-*wecanreallyusethedirectops-*/-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)-returnNULL;--/* Try to use the iommu */-returniommu_alloc_coherent(dev,iommu,size,dma_handle,-dev->coherent_dma_mask,flag,-dev_to_node(dev));-}--staticvoiddma_nommu_free_coherent(structdevice*dev,size_tsize,-void*vaddr,dma_addr_tdma_handle,-unsignedlongattrs)-{-structiommu_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-*placesohowcomewearefreeing?-*/-if(WARN_ON(!iommu))-return;-iommu_free_coherent(iommu,size,vaddr,dma_handle);-}-intdma_nommu_mmap_coherent(structdevice*dev,structvm_area_struct*vma,void*cpu_addr,dma_addr_thandle,size_tsize,unsignedlongattrs)
@@ -1814,89 +1814,45 @@ static int pnv_pci_ioda_dma_64bit_bypass(struct pnv_ioda_pe *pe)return-EIO;}-staticintpnv_pci_ioda_dma_set_mask(structpci_dev*pdev,u64dma_mask)+staticboolpnv_pci_ioda_iommu_bypass_supported(structpci_dev*pdev,+u64dma_mask){structpci_controller*hose=pci_bus_to_host(pdev->bus);structpnv_phb*phb=hose->private_data;structpci_dn*pdn=pci_get_pdn(pdev);structpnv_ioda_pe*pe;-uint64_ttop;-boolbypass=false;-s64rc;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);+u64top=pe->tce_bypass_base+memblock_end_of_DRAM()-1;+if(dma_mask>=top)+returntrue;}-if(bypass){-dev_info(&pdev->dev,"Using 64-bit DMA iommu bypass\n");-set_dma_ops(&pdev->dev,&dma_nommu_ops);-}else{-/*-*Ifthedevicecan'tsettheTCEbypassbitbutstillwants-*toaccess4GBormore,onPHB3wecanreconfigureTVE#0to-*bypassthe32-bitregionandbeusablefor64-bitDMAs.-*Thedeviceneedstobeabletoaddressallofthisspace.-*/-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)-returnrc;-/* 4GB offset bypasses 32-bit space */-set_dma_offset(&pdev->dev,(1ULL<<32));-set_dma_ops(&pdev->dev,&dma_nommu_ops);-}elseif(dma_mask>>32&&dma_mask!=DMA_BIT_MASK(64)){-/*-*FailtherequestifaDMAmaskbetween32and64bits-*wasrequestedbutcouldn'tbefulfilled.Ideallywe-*woulddothisfor64-bitsbuthistoricallywehave-*alwaysfallenbackto32-bits.-*/-return-ENOMEM;-}else{-dev_info(&pdev->dev,"Using 32-bit DMA via iommu\n");-set_dma_ops(&pdev->dev,&dma_iommu_ops);-}+/*+*Ifthedevicecan'tsettheTCEbypassbitbutstillwants+*toaccess4GBormore,onPHB3wecanreconfigureTVE#0to+*bypassthe32-bitregionandbeusablefor64-bitDMAs.+*Thedeviceneedstobeabletoaddressallofthisspace.+*/+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 */+s64rc=pnv_pci_ioda_dma_64bit_bypass(pe);+if(rc)+returnrc;+/* 4GB offset bypasses 32-bit space */+set_dma_offset(&pdev->dev,(1ULL<<32));+returntrue;}-*pdev->dev.dma_mask=dma_mask;--/* Update peer npu devices */-pnv_npu_try_dma_set_bypass(pdev,bypass);--return0;-}--staticu64pnv_pci_ioda_dma_get_required_mask(structpci_dev*pdev)-{-structpci_controller*hose=pci_bus_to_host(pdev->bus);-structpnv_phb*phb=hose->private_data;-structpci_dn*pdn=pci_get_pdn(pdev);-structpnv_ioda_pe*pe;-u64end,mask;-if(WARN_ON(!pdn||pdn->pe_number==IODA_INVALID_PE))-return0;--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;--returnmask;+returnfalse;}staticvoidpnv_ioda_setup_bus_dma(structpnv_ioda_pe*pe,
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:35
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:35
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 <hch@lst.de>
---
drivers/misc/cxl/vphb.c | 12 ------------
1 file changed, 12 deletions(-)
@@ -11,17 +11,6 @@#include<misc/cxl.h>#include"cxl.h"-staticintcxl_dma_set_mask(structpci_dev*pdev,u64dma_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;-return0;-}-staticintcxl_pci_probe_mode(structpci_bus*bus){returnPCI_PROBE_NORMAL;
@@ -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,};staticintppc_swiotlb_bus_notify(structnotifier_block*nb,unsignedlongaction,void*data){structdevice*dev=data;-structdev_archdata*sd;/* We are only intereted in device addition */if(action!=BUS_NOTIFY_ADD_DEVICE)return0;-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);
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:45
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 <hch@lst.de>
---
arch/powerpc/sysdev/fsl_pci.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:51
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 <hch@lst.de>
---
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(-)
@@ -544,6 +544,7 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)staticunsignedlongcell_dma_nommu_offset;staticunsignedlongdma_iommu_fixed_base;+staticboolcell_iommu_enabled;/* iommu_fixed_is_weak is set if booted with iommu_fixed=weak */booliommu_fixed_is_weak;
@@ -599,11 +598,11 @@ static int cell_of_bus_notify(struct notifier_block *nb, unsigned long action,if(action!=BUS_NOTIFY_ADD_DEVICE)return0;-/* 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);-return0;}
@@ -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*tohandlelinkingthemtotherightDMAoperations
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:24:54
- 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 <hch@lst.de>
---
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
@@ -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 */-externvoid*__dma_nommu_alloc_coherent(structdevice*dev,size_tsize,-dma_addr_t*dma_handle,gfp_tflag,-unsignedlongattrs);-externvoid__dma_nommu_free_coherent(structdevice*dev,size_tsize,-void*vaddr,dma_addr_tdma_handle,-unsignedlongattrs);-intdma_nommu_map_sg(structdevice*dev,structscatterlist*sgl,-intnents,enumdma_data_directiondirection,-unsignedlongattrs);-dma_addr_tdma_nommu_map_page(structdevice*dev,structpage*page,-unsignedlongoffset,size_tsize,-enumdma_data_directiondir,unsignedlongattrs);-intdma_nommu_dma_supported(structdevice*dev,u64mask);-u64dma_nommu_get_required_mask(structdevice*dev);--#ifdef CONFIG_NOT_COHERENT_CACHE-/*-*DMA-consistentmappingfunctionsforPowerPCsthatdon'tsupport-*cachesnooping.Theseallocate/freearegionofuncachedmapped-*memoryspaceforusewithDMAdevices.Alternatively,youcould-*allocatethespace"normally"andusethecachemanagementfunctions-*toensureitisconsistent.-*/-structdevice;-externvoid__dma_sync(void*vaddr,size_tsize,intdirection);-externvoid__dma_sync_page(structpage*page,unsignedlongoffset,-size_tsize,intdirection);-externunsignedlong__dma_get_coherent_pfn(unsignedlongcpu_addr);--#else /* ! CONFIG_NOT_COHERENT_CACHE */-/*-*Cachecoherentcores.-*/--#define __dma_sync(addr, size, rw) ((void)0)-#define __dma_sync_page(pg, off, sz, rw) ((void)0)--#endif /* ! CONFIG_NOT_COHERENT_CACHE */-staticinlineunsignedlongdevice_to_mask(structdevice*dev){if(dev->dma_mask&&*dev->dma_mask)
@@ -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);returnNOTIFY_DONE;}
@@ -47,7 +47,7 @@ static int __init warp_probe(void)if(!of_machine_is_compatible("pika,warp"))return0;-/* For __dma_nommu_alloc_coherent */+/* For arch_dma_alloc */ISA_DMA_THRESHOLD=~0L;return1;
@@ -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);return0;}
@@ -727,7 +727,7 @@ static int __init cell_iommu_init_disabled(void)unsignedlongbase=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();
@@ -362,7 +362,7 @@ static int pcmcia_notify(struct notifier_block *nb, unsigned long action,return0;/* We use the direct ops for localbus */-dev->dma_ops=&dma_nommu_ops;+dev->dma_ops=&dma_direct_ops;return0;}
@@ -1197,7 +1197,6 @@ static bool iommu_bypass_supported_pSeriesLP(struct pci_dev *pdev, u64 dma_mask){structdevice_node*dn=pci_device_to_OF_node(pdev),*pdn;const__be32*dma_window=NULL;-u64dma_offset;/* only attempt to use a new window if 64-bit DMA is requested */if(dma_mask<DMA_BIT_MASK(64))
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:00
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:02
Use the standard portable helper instead of the powerpc specific one,
which is about to go away.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -42,7 +42,7 @@ static u64 __maybe_unused get_pfn_limit(struct device *dev)intdma_nommu_dma_supported(structdevice*dev,u64mask){#ifdef CONFIG_PPC64-u64limit=get_dma_offset(dev)+(memblock_end_of_DRAM()-1);+u64limit=phys_to_dma(dev,(memblock_end_of_DRAM()-1));/* Limit fits in the mask, we are good */if(mask>=limit)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:05
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 <hch@lst.de>
---
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(-)
@@ -400,14 +401,16 @@ EXPORT_SYMBOL(__dma_sync_page);/**ReturnthePFNforagivencpuvirtualaddressreturnedby-*__dma_nommu_alloc_coherent.Thisisusedbydma_mmap_coherent()+*__dma_nommu_alloc_coherent.*/-unsignedlong__dma_get_coherent_pfn(unsignedlongcpu_addr)+longarch_dma_coherent_to_pfn(structdevice*dev,void*vaddr,+dma_addr_tdma_addr){/* This should always be populated, so we don't test every*level.Ifthatfails,we'llhaveanicecrashwhich*willbeasgoodasaBUG_ON()*/+unsignedlongcpu_addr=(unsignedlong)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);
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:09
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 <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/dma-direct.h | 8 ++++++--
arch/powerpc/include/asm/dma-mapping.h | 16 ----------------
2 files changed, 6 insertions(+), 18 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:36
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 <hch@lst.de>
---
arch/powerpc/include/asm/dma-direct.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-14 08:25:44
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-27 07:42:56
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
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-11-28 11:05:24
Christoph Hellwig [off-list ref] 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:
quoted
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
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
From: Christian Zigotzky <hidden> Date: 2018-11-28 16:07:54
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
From: Christian Zigotzky <hidden> Date: 2018-11-28 20:03:26
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.
From: Michal Suchánek <hidden> Date: 2018-11-28 20:35:14
On Wed, 28 Nov 2018 16:55:30 +0100
Christian Zigotzky [off-list ref] wrote:
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
quoted
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
From: Christian Zigotzky <hidden> Date: 2018-11-29 12:06:03
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Christoph Hellwig [off-list ref] writes:
quoted
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
From: Christian Zigotzky <hidden> Date: 2018-11-29 15:30:30
On 29 November 2018 at 1:05PM, Christian Zigotzky wrote:
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
quoted
Christoph Hellwig [off-list ref] writes:
quoted
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
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-29 17:02:09
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.
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-29 17:03:05
quoted
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.
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
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-30 10:53:49
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?
From: Christian Zigotzky <hidden> Date: 2018-11-30 12:24:03
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 <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Links:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/146701.htmlhttps://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
From: Christoph Hellwig <hch@lst.de> Date: 2018-11-30 13:11:00
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:
quoted
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.
quoted
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.
From: Christian Zigotzky <hidden> Date: 2018-11-30 15:30:16
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:
quoted
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
From: Christian Zigotzky <hidden> Date: 2018-12-04 07:31:13
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
From: Christian Zigotzky <hidden> Date: 2018-12-04 09:53:46
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
From: Christoph Hellwig <hch@lst.de> Date: 2018-12-04 14:24:33
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 ?
From: Christian Zigotzky <hidden> Date: 2018-12-05 10:04:45
On 04 December 2018 at 3:24PM, Christoph Hellwig wrote:
On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote:
quoted
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
From: Christoph Hellwig <hch@lst.de> Date: 2018-12-05 14:05:53
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
From: Christian Zigotzky <hidden> Date: 2018-12-06 10:56:06
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
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:09:42
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:
quoted hunk
AMIGAONE select NOT_COHERENT_CACHE, so we better allow it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/platforms/Kconfig.cputype | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:09:57
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:
quoted hunk
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 <hch@lst.de>
---
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(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:10:33
ping?
On Wed, Nov 14, 2018 at 09:22:47AM +0100, Christoph Hellwig wrote:
quoted hunk
These methods are optional, no need to implement no-op versions.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 16 ----------------
1 file changed, 16 deletions(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:10:46
ping?
On Wed, Nov 14, 2018 at 09:22:46AM +0100, Christoph Hellwig wrote:
quoted hunk
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 <hch@lst.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
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(-)
@@ -47,7 +47,7 @@ static int __init warp_probe(void)if(!of_machine_is_compatible("pika,warp"))return0;-/* For __dma_alloc_coherent */+/* For __dma_nommu_alloc_coherent */ISA_DMA_THRESHOLD=~0L;return1;
--
2.19.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:11:11
ping?
On Wed, Nov 14, 2018 at 09:22:59AM +0100, Christoph Hellwig wrote:
quoted hunk
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 <hch@lst.de>
---
drivers/misc/cxl/vphb.c | 12 ------------
1 file changed, 12 deletions(-)
@@ -11,17 +11,6 @@#include<misc/cxl.h>#include"cxl.h"-staticintcxl_dma_set_mask(structpci_dev*pdev,u64dma_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;-return0;-}-staticintcxl_pci_probe_mode(structpci_bus*bus){returnPCI_PROBE_NORMAL;
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:12:02
ping?
On Wed, Nov 14, 2018 at 09:22:54AM +0100, Christoph Hellwig wrote:
quoted hunk
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 <hch@lst.de>
---
arch/powerpc/sysdev/dart_iommu.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
From: Christoph Hellwig <hch@infradead.org> Date: 2018-12-06 14:13:10
ping?
On Wed, Nov 14, 2018 at 09:22:48AM +0100, Christoph Hellwig wrote:
quoted hunk
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 <hch@lst.de>
---
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(-)
From: Christian Zigotzky <hidden> Date: 2018-12-06 17:11:10
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 [off-list ref] wrote:
quoted
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
From: Christian Zigotzky <hidden> Date: 2018-12-07 07:49:09
Good to know. Sorry because of the email.
Sent from my iPhone
On 6. Dec 2018, at 20:36, Christoph Hellwig [off-list ref] wrote:
quoted
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.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-12-07 12:18:25
Christoph Hellwig [off-list ref] 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:
quoted
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 <hch@lst.de>
---
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(-)
From: Christian Zigotzky <hidden> Date: 2018-12-07 13:45:12
On 06 December 2018 at 11:55AM, Christian Zigotzky wrote:
On 05 December 2018 at 3:05PM, Christoph Hellwig wrote:
quoted
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
From: Christoph Hellwig <hch@lst.de> Date: 2018-12-07 14:09:14
On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote:
Christoph Hellwig [off-list ref] writes:
quoted
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.
From: Christian Zigotzky <hidden> Date: 2018-12-07 15:05:01
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 [off-list ref] wrote:
quoted
On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote:
Christoph Hellwig [off-list ref] writes:
quoted
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.
From: Christian Zigotzky <hidden> Date: 2018-12-07 18:33:14
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 [off-list ref] wrote:
quoted
On 06 December 2018 at 11:55AM, Christian Zigotzky wrote:
quoted
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
From: Christian Zigotzky <hidden> Date: 2018-12-08 10:29:13
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