| Message ID | 109e9ddbde4334d0da34f331797236309d789353.1491999859.git.dwmw2@infradead.org (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse <dwmw2@infradead.org> wrote: > From: David Woodhouse <dwmw@amazon.co.uk> > > Now that we eliminated the different behaviour in separately-reviewable > commits, we can switch IA64 to the generic implementation. > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Well it builds and boots on my last remaining ia64 machine. No warnings or weird stuff in the console log. So you can mark the three ia64 patches Tested-by: Tony Luck <tony.luck@intel.com> and bundle them with the others rather than through the ia64 tree. -Tony
On Wed, 12 Apr 2017, Tony Luck wrote: > On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse <dwmw2@infradead.org> wrote: > > From: David Woodhouse <dwmw@amazon.co.uk> > > > > Now that we eliminated the different behaviour in separately-reviewable > > commits, we can switch IA64 to the generic implementation. > > > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> > > Well it builds and boots on my last remaining ia64 machine. Does that mean ia64 reached the 'NCR Voyager' stage and can be scheduled for removal? Thanks, tglx
On Wed, 2017-04-12 at 14:47 -0700, Tony Luck wrote: > On Wed, Apr 12, 2017 at 5:26 AM, David Woodhouse <dwmw2@infradead.org> wrote: > > > > From: David Woodhouse <dwmw@amazon.co.uk> > > > > Now that we eliminated the different behaviour in separately-reviewable > > commits, we can switch IA64 to the generic implementation. > > > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> > > Well it builds and boots on my last remaining ia64 machine. No warnings > or weird stuff in the console log. So you can mark the three ia64 patches Thanks. The interesting test is whether you can correctly map PCI BARs through /proc/bus/pci and /sys/bus/pci? And if you find a prefetchable BAR you can scribble on, does the box explode if you do it both WC and UC at the same time? http://david.woodhou.se/pcimmap_copy.c should validate WC mappings and look something like this... [fedora@ip-172-31-55-194 ~]$ sudo ./pcimmap_copy /sys/bus/pci/devices/0000\:00\:1e.0/resource4 0 Copied 1000 loops in 0.354437301s [fedora@ip-172-31-55-194 ~]$ sudo ./pcimmap_copy /sys/bus/pci/devices/0000\:00\:1e.0/resource4_wc 0 Copied 1000 loops in 0.057309254s
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h index fc60b3d..6459f2d 100644 --- a/arch/ia64/include/asm/pci.h +++ b/arch/ia64/include/asm/pci.h @@ -51,6 +51,7 @@ extern unsigned long ia64_max_iommu_merge_mask; #define PCI_DMA_BUS_IS_PHYS (ia64_max_iommu_merge_mask == ~0UL) #define HAVE_PCI_MMAP +#define ARCH_GENERIC_PCI_MMAP_RESOURCE #define arch_can_pci_mmap_wc() 1 #define HAVE_PCI_LEGACY diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c index 7438e8c..4068bde 100644 --- a/arch/ia64/pci/pci.c +++ b/arch/ia64/pci/pci.c @@ -418,36 +418,6 @@ pcibios_align_resource (void *data, const struct resource *res, return res->start; } -int -pci_mmap_page_range (struct pci_dev *dev, int bar, - struct vm_area_struct *vma, - enum pci_mmap_state mmap_state, int write_combine) -{ - /* - * I/O space cannot be accessed via normal processor loads and - * stores on this platform. - */ - if (mmap_state == pci_mmap_io) - /* - * XXX we could relax this for I/O spaces for which ACPI - * indicates that the space is 1-to-1 mapped. But at the - * moment, we don't support multiple PCI address spaces and - * the legacy I/O space is not 1-to-1 mapped, so this is moot. - */ - return -EINVAL; - - if (write_combine) - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot); - else - vma->vm_page_prot = pgprot_device(vma->vm_page_prot); - - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff, - vma->vm_end - vma->vm_start, vma->vm_page_prot)) - return -EAGAIN; - - return 0; -} - /** * ia64_pci_get_legacy_mem - generic legacy mem routine * @bus: bus to get legacy memory base address for