lib: move GENERIC_IOMAP to lib/Kconfig
Subsystems (15)
PATCH 1/10 lib: move GENERIC_IOMAP to lib/Kconfig
In reply to a message not in the archivedefine GENERIC_IOMAP in a central location instead of all architectures. This will be helpful for the follow-up patch which makes it select other configs. Code is also a bit shorter this way.
--- arch/alpha/Kconfig | 4 ---- arch/cris/Kconfig | 5 +---- arch/hexagon/Kconfig | 4 +--- arch/ia64/Kconfig | 5 +---- arch/m68k/Kconfig | 4 +--- arch/openrisc/Kconfig | 3 --- arch/powerpc/platforms/Kconfig | 3 --- arch/score/Kconfig | 4 +--- arch/sh/Kconfig | 3 --- arch/unicore32/Kconfig | 4 +--- arch/x86/Kconfig | 4 +--- lib/Kconfig | 3 +++ 12 files changed, 10 insertions(+), 36 deletions(-)
arch/alpha/Kconfig +0 -4
@@ -70,10 +70,6 @@ config GENERIC_ISA_DMA bool default y -config GENERIC_IOMAP - bool - default n - source "init/Kconfig" source "kernel/Kconfig.freezer"
arch/cris/Kconfig +1 -4
@@ -19,10 +19,6 @@ config GENERIC_CMOS_UPDATE config ARCH_USES_GETTIMEOFFSET def_bool n -config GENERIC_IOMAP - bool - default y - config ARCH_HAS_ILOG2_U32 bool default n
@@ -52,6 +48,7 @@ config CRIS select HAVE_IDE select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_SHOW + select GENERIC_IOMAP config HZ int
arch/hexagon/Kconfig +1 -3
@@ -26,6 +26,7 @@ config HEXAGON select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK select NO_IOPORT + select GENERIC_IOMAP # mostly generic routines, with some accelerated ones ---help--- Qualcomm Hexagon is a processor architecture designed for high
@@ -73,9 +74,6 @@ config GENERIC_CSUM config GENERIC_IRQ_PROBE def_bool y -config GENERIC_IOMAP - def_bool y - #config ZONE_DMA # bool # default y
arch/ia64/Kconfig +1 -4
@@ -29,6 +29,7 @@ config IA64 select GENERIC_IRQ_SHOW select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_HAVE_NMI_SAFE_CMPXCHG + select GENERIC_IOMAP default y help The Itanium Processor Family is Intel's 64-bit successor to
@@ -102,10 +103,6 @@ config EFI bool default y -config GENERIC_IOMAP - bool - default y - config ARCH_CLOCKSOURCE_DATA def_bool y
arch/m68k/Kconfig +1 -3
@@ -38,9 +38,6 @@ config GENERIC_CALIBRATE_DELAY bool default y -config GENERIC_IOMAP - def_bool MMU - config TIME_LOW_RES bool default y
@@ -73,6 +70,7 @@ source "kernel/Kconfig.freezer" config MMU bool "MMU-based Paged Memory Management Support" default y + select GENERIC_IOMAP help Select if you want MMU-based virtualised addressing space support by paged memory management. If unsure, say 'Y'.
arch/openrisc/Kconfig +0 -3
@@ -38,9 +38,6 @@ config RWSEM_XCHGADD_ALGORITHM config GENERIC_HWEIGHT def_bool y -config GENERIC_IOMAP - def_bool y - config NO_IOPORT def_bool y
arch/powerpc/platforms/Kconfig +0 -3
@@ -175,9 +175,6 @@ config PPC_INDIRECT_MMIO config PPC_IO_WORKAROUNDS bool -config GENERIC_IOMAP - bool - source "drivers/cpufreq/Kconfig" menu "CPU Frequency drivers"
arch/score/Kconfig +1 -3
@@ -4,6 +4,7 @@ config SCORE def_bool y select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_SHOW + select GENERIC_IOMAP choice prompt "System type"
@@ -33,9 +34,6 @@ endmenu config CPU_SCORE7 bool -config GENERIC_IOMAP - def_bool y - config NO_DMA bool default y
arch/sh/Kconfig +0 -3
@@ -84,9 +84,6 @@ config GENERIC_GPIO config GENERIC_CALIBRATE_DELAY bool -config GENERIC_IOMAP - bool - config GENERIC_CLOCKEVENTS def_bool y
arch/unicore32/Kconfig +1 -3
@@ -12,6 +12,7 @@ config UNICORE32 select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW select ARCH_WANT_FRAME_POINTERS + select GENERIC_IOMAP help UniCore-32 is 32-bit Instruction Set Architecture, including a series of low-power-consumption RISC chip
@@ -30,9 +31,6 @@ config GENERIC_CLOCKEVENTS config GENERIC_CSUM def_bool y -config GENERIC_IOMAP - def_bool y - config NO_IOPORT bool
arch/x86/Kconfig +1 -3
@@ -75,6 +75,7 @@ config X86 select HAVE_BPF_JIT if (X86_64 && NET) select CLKEVT_I8253 select ARCH_HAVE_NMI_SAFE_CMPXCHG + select GENERIC_IOMAP config INSTRUCTION_DECODER def_bool (KPROBES || PERF_EVENTS)
@@ -140,9 +141,6 @@ config NEED_SG_DMA_LENGTH config GENERIC_ISA_DMA def_bool ISA_DMA_API -config GENERIC_IOMAP - def_bool y - config GENERIC_BUG def_bool y depends on BUG
lib/Kconfig +3 -0
@@ -19,6 +19,9 @@ config RATIONAL config GENERIC_FIND_FIRST_BIT bool +config GENERIC_IOMAP + bool + config CRC_CCITT tristate "CRC-CCITT functions" help
Signature · 1 line
1.7.5.53.gc233e
PATCH 2/10 lib: add GENERIC_PCI_IOMAP
In reply to a message not in the archiveMany architectures want a generic pci_iomap but not the rest of iomap.c. Split that to a separate .c file and add a new config symbol. select automatically by GENERIC_IOMAP.
--- include/asm-generic/io.h | 5 +-- include/asm-generic/iomap.h | 7 +---- include/asm-generic/pci_iomap.h | 26 +++++++++++++++++++++ lib/Kconfig | 4 +++ lib/Makefile | 1 + lib/iomap.c | 38 +----------------------------- lib/pci_iomap.c | 48 +++++++++++++++++++++++++++++++++++++++ 7 files changed, 85 insertions(+), 44 deletions(-) create mode 100644 include/asm-generic/pci_iomap.h create mode 100644 lib/pci_iomap.c
include/asm-generic/io.h +2 -3
@@ -19,6 +19,8 @@#include <asm-generic/iomap.h> #endif +#include <asm-generic/pci_iomap.h> +#ifndef mmiowb#define mmiowb () do {} while (0)#endif
@@ -283,9 +285,6 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)#define __io_virt (x) ((void __force *) (x))#ifndef CONFIG_GENERIC_IOMAP -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);static inline void pci_iounmap (struct pci_dev *dev,void __iomem *p) { }
include/asm-generic/iomap.h +2 -5
@@ -69,16 +69,13 @@ extern void ioport_unmap(void __iomem *);#ifdef CONFIG_PCI /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);#else struct pci_dev ; -static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -return NULL ; -}static inline void pci_iounmap (struct pci_dev *dev,void __iomem *addr) { }#endif +#include <asm-generic/pci_iomap.h> +#endif
include/asm-generic/pci_iomap.h new file +26 -0
@@ -0,0 +1,26 @@ +/* Generic I/O port emulation, based on MN10300 code +* +* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public Licence +* as published by the Free Software Foundation; either version +* 2 of the Licence, or (at your option) any later version. +*/ +#ifndef __ASM_GENERIC_PCI_IOMAP_H +#define __ASM_GENERIC_PCI_IOMAP_H + +#ifdef CONFIG_PCI +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev ; +extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max); +#else +struct pci_dev ; +static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) +{ +return NULL ; +} +#endif + +#endif /* __ASM_GENERIC_IO_H */
lib/Kconfig +4 -0
@@ -19,8 +19,12 @@ config RATIONAL config GENERIC_FIND_FIRST_BIT bool +config GENERIC_PCI_IOMAP + bool + config GENERIC_IOMAP bool + select GENERIC_PCI_IOMAP config CRC_CCITT tristate "CRC-CCITT functions"
lib/Makefile +1 -0
@@ -33,6 +33,7 @@ endif lib-$(CONFIG_HOTPLUG) += kobject_uevent.o obj-$(CONFIG_GENERIC_IOMAP) += iomap.o +obj-$(CONFIG_GENERIC_PCI_IOMAP) += pci_iomap.o obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o obj-$(CONFIG_CHECK_SIGNATURE) += check_signature.o obj-$(CONFIG_DEBUG_LOCKING_API_SELFTESTS) += locking-selftest.o
lib/iomap.c +2 -36
@@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);#endif /* CONFIG_HAS_IOPORT */ #ifdef CONFIG_PCI -/** -* pci_iomap - create a virtual mapping cookie for a PCI BAR -* @dev: PCI device that owns the BAR -* @bar: BAR number -* @maxlen: length of the memory to map -* -* Using this function you will get a __iomem address to your device BAR. -* You can access it using ioread*() and iowrite*(). These functions hide -* the details if this is a MMIO or PIO address space and will just do what -* you expect from them in the correct way. -* -* @maxlen specifies the maximum length to map. If you want to get access to -* the complete BAR without checking for its length first, pass %0 here. -* */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} - +/* Hide the details if this is a MMIO or PIO address space and just do what +* you expect in the correct way. */ void pci_iounmap (struct pci_dev *dev,void __iomem * addr) { IO_COND(addr, /* nothing */, iounmap(addr)); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);#endif /* CONFIG_PCI */
lib/pci_iomap.c new file +48 -0
48 lines not on this page · raw message
Signature · 1 line
1.7.5.53.gc233e
PATCH 3/10 alpha: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivealpha copied pci_iomap from generic code to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag, that turns out to be done correctly by the generic code since arch/alpha/include/asm/io.h defines ioremap_nocache same as ioremap.
--- arch/alpha/Kconfig | 1 + arch/alpha/kernel/pci.c | 26 +------------------------- 2 files changed, 2 insertions(+), 25 deletions(-)
arch/alpha/Kconfig +1 -0
@@ -315,6 +315,7 @@ config ISA_DMA_API config PCI bool depends on !ALPHA_JENSEN + select GENERIC_PCI_IOMAP default y help Find out whether you have a PCI motherboard. PCI is the name of a
arch/alpha/kernel/pci.c +1 -25
@@ -508,30 +508,7 @@ sys_pciconfig_iobase(long which, unsigned long bus, unsigned long dfn)return -EOPNOTSUPP ; } -/* Create an __iomem token from a PCI BAR. Copied from lib/iomap.c with -no changes, since we don't want the other things in that object file. */ - -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -/* Not checking IORESOURCE_CACHEABLE because alpha does -not distinguish between ioremap and ioremap_nocache. */ -return ioremap (start, len); - } -return NULL ; -} - -/* Destroy that token. Not copied from lib/iomap.c. */ +/* Destroy an __iomem token. Not copied from lib/iomap.c. */ void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {
@@ -539,7 +516,6 @@ void pci_iounmap(struct pci_dev *dev, void __iomem * addr)iounmap (addr); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);/* FIXME: Some boxes have multiple ISA bridges! */
Signature · 1 line
1.7.5.53.gc233e
PATCH 4/10 arm: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivearm copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
--- arch/arm/Kconfig | 1 + arch/arm/include/asm/io.h | 2 +- arch/arm/mm/iomap.c | 21 --------------------- 3 files changed, 2 insertions(+), 22 deletions(-)
arch/arm/Kconfig +1 -0
@@ -30,6 +30,7 @@ config ARM select HAVE_SPARSE_IRQ select GENERIC_IRQ_SHOW select CPU_PM if (SUSPEND || CPU_IDLE) + select GENERIC_PCI_IOMAP help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and
arch/arm/include/asm/io.h +1 -1
@@ -27,6 +27,7 @@#include <asm/byteorder.h> #include <asm/memory.h> #include <asm/system.h> +#include <asm-generic/pci_iomap.h> /* * ISA I/O bus memory addresses are 1:1 with the physical address.
@@ -306,7 +307,6 @@ extern void ioport_unmap(void __iomem *addr);struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen);extern void pci_iounmap (struct pci_dev *dev,void __iomem *addr);/*
arch/arm/mm/iomap.c +0 -21
@@ -35,27 +35,6 @@ EXPORT_SYMBOL(pcibios_min_mem);unsigned int pci_flags =PCI_REASSIGN_ALL_RSRC ;EXPORT_SYMBOL (pci_flags); -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -return NULL ; -} -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) { if ((unsigned long)addr >= VMALLOC_START &&
Signature · 1 line
1.7.5.53.gc233e
PATCH 5/10 microblaze: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivemicroblaze copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag, that turns out to be done correctly by the generic code since arch/microblaze/include/asm/io.h defines ioremap_nocache same as ioremap.
--- arch/microblaze/Kconfig | 1 + arch/microblaze/pci/iomap.c | 19 ------------------- 2 files changed, 1 insertions(+), 19 deletions(-)
arch/microblaze/Kconfig +1 -0
@@ -17,6 +17,7 @@ config MICROBLAZE select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_PROBE select GENERIC_IRQ_SHOW + select GENERIC_PCI_IOMAP config SWAP def_bool n
arch/microblaze/pci/iomap.c +0 -19
@@ -10,25 +10,6 @@#include <asm/io.h> #include <asm/pci-bridge.h> -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len) -return NULL ; -if (max && len > max) - len = max; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) -return ioremap (start, len); -/* What? */ -return NULL ; -} -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) {if (isa_vaddr_is_ioport (addr))
Signature · 1 line
1.7.5.53.gc233e
PATCH 6/10 mips: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivemips copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
--- arch/mips/Kconfig | 1 + arch/mips/lib/iomap-pci.c | 26 -------------------------- 2 files changed, 1 insertions(+), 26 deletions(-)
arch/mips/Kconfig +1 -0
@@ -2317,6 +2317,7 @@ config PCI bool "Support for PCI controller" depends on HW_HAS_PCI select PCI_DOMAINS + select GENERIC_PCI_IOMAP help Find out whether you have a PCI motherboard. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff inside
arch/mips/lib/iomap-pci.c +0 -26
@@ -40,32 +40,6 @@ static void __iomem *ioport_map_pci(struct pci_dev *dev,return (void __iomem *) (ctrl->io_map_base + port); } -/* -* Create a virtual mapping cookie for a PCI BAR (memory or IO) -*/ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map_pci (dev, start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} - -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {iounmap (addr);
Signature · 1 line
1.7.5.53.gc233e
PATCH 7/10 parisc: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archiveparisc copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
--- arch/parisc/Kconfig | 1 + arch/parisc/lib/iomap.c | 23 ----------------------- 2 files changed, 1 insertions(+), 23 deletions(-)
arch/parisc/Kconfig +1 -0
@@ -14,6 +14,7 @@ config PARISC select GENERIC_ATOMIC64 if !64BIT select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_PROBE + select GENERIC_PCI_IOMAP select IRQ_PER_CPU select ARCH_HAVE_NMI_SAFE_CMPXCHG
arch/parisc/lib/iomap.c +0 -23
@@ -436,28 +436,6 @@ void ioport_unmap(void __iomem *addr) } } -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {if (!INDIRECT_ADDR (addr)) {
@@ -483,5 +461,4 @@ EXPORT_SYMBOL(iowrite16_rep);EXPORT_SYMBOL (iowrite32_rep);EXPORT_SYMBOL (ioport_map);EXPORT_SYMBOL (ioport_unmap); -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);
Signature · 1 line
1.7.5.53.gc233e
PATCH 8/10 powerpc: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivepowerpc copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code since arch/powerpc/include/asm/io.h
defines ioremap_nocache same as ioremap.
--- arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/iomap.c | 19 ------------------- 2 files changed, 1 insertions(+), 19 deletions(-)
arch/powerpc/Kconfig +1 -0
@@ -710,6 +710,7 @@ config PCI default PCI_PERMEDIA if !4xx && !CPM2 && !8xx default PCI_QSPAN if !4xx && !CPM2 && 8xx select ARCH_SUPPORTS_MSI + select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff inside
arch/powerpc/kernel/iomap.c +0 -19
@@ -119,24 +119,6 @@ EXPORT_SYMBOL(ioport_map);EXPORT_SYMBOL (ioport_unmap);#ifdef CONFIG_PCI -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len) -return NULL ; -if (max && len > max) - len = max; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) -return ioremap (start, len); -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) {if (isa_vaddr_is_ioport (addr))
@@ -146,6 +128,5 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr) iounmap(addr); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);#endif /* CONFIG_PCI */
Signature · 1 line
1.7.5.53.gc233e
PATCH 9/10 sh: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivesh copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
--- arch/sh/Kconfig | 1 + arch/sh/drivers/pci/pci.c | 23 ----------------------- 2 files changed, 1 insertions(+), 23 deletions(-)
arch/sh/Kconfig +1 -0
@@ -857,6 +857,7 @@ config PCI bool "PCI support" depends on SYS_SUPPORTS_PCI select PCI_DOMAINS + select GENERIC_PCI_IOMAP help Find out whether you have a PCI motherboard. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff inside
arch/sh/drivers/pci/pci.c +0 -23
@@ -393,29 +393,6 @@ static void __iomem *ioport_map_pci(struct pci_dev *dev,return (void __iomem *)(chan->io_map_base + port); } -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (unlikely (!len || !start)) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; - -if (flags &IORESOURCE_IO ) -return ioport_map_pci (dev, start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } - -return NULL ; -} -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) {iounmap (addr);
Signature · 1 line
1.7.5.53.gc233e
PATCH 10/10 sparc: switch to GENERIC_PCI_IOMAP
In reply to a message not in the archivesparc copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
--- arch/sparc/Kconfig | 1 + arch/sparc/include/asm/io_32.h | 5 ++++- arch/sparc/include/asm/io_64.h | 5 ++++- arch/sparc/lib/iomap.c | 23 ----------------------- 4 files changed, 9 insertions(+), 25 deletions(-)
arch/sparc/Kconfig +1 -0
@@ -28,6 +28,7 @@ config SPARC select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_SHOW select USE_GENERIC_SMP_HELPERS if SMP + select GENERIC_PCI_IOMAP config SPARC32 def_bool !64BIT
arch/sparc/include/asm/io_32.h +4 -1
@@ -8,6 +8,10 @@#include <asm/page.h> /* IO address mapping routines need this */ #include <asm/system.h> +#ifdef __KERNEL__ +#include <asm-generic/pci_iomap.h> +#endif +#define page_to_phys (page) (page_to_pfn(page) << PAGE_SHIFT)static inline u32 flip_dword (u32 l)
@@ -324,7 +328,6 @@ extern void ioport_unmap(void __iomem *);/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);/*
arch/sparc/include/asm/io_64.h +4 -1
@@ -9,6 +9,10 @@#include <asm/system.h> #include <asm/asi.h> +#ifdef __KERNEL__ +#include <asm-generic/pci_iomap.h> +#endif +/* PC crapola... */ #define __SLOW_DOWN_IO do { } while (0)#define SLOW_DOWN_IO do { } while (0)
@@ -514,7 +518,6 @@ extern void ioport_unmap(void __iomem *);/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);static inline int sbus_can_dma_64bit (void )
arch/sparc/lib/iomap.c +0 -23
@@ -18,31 +18,8 @@ void ioport_unmap(void __iomem *addr)EXPORT_SYMBOL (ioport_map);EXPORT_SYMBOL (ioport_unmap); -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {/* nothing to do */ } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);
Signature · 1 line
1.7.5.53.gc233e
Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 6 lines · On Thursday 24 November 2011 22:17:02 Michael S. Tsirkin wrote:
Many architectures want a generic
pci_iomapbut not the rest ofiomap.c. Split that to a separate .c file and add a new config symbol. select automatically byGENERIC_IOMAP.Signed-off-by Michael S. Tsirkin <[email protected]>
Very nice!
Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinHi Michael,
Quoted 15 lines · On Thu, 24 Nov 2011 22:17:02 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
include/asm-generic/io.h +2
-0@@ -19,6 +19,8 @@#include <asm-generic/iomap.h> #endif +#include <asm-generic/pci_iomap.h> +#ifndef mmiowb#define mmiowb () do {} while (0)#endif
include/asm-generic/io.h static inline void writesb(const void __iomem *addr, const void *buf, int len) · line 290
Quoted 9 lines
include/asm-generic/io.h +0
-3@@ -283,9 +285,6 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)#define __io_virt (x) ((void __force *) (x))#ifndef CONFIG_GENERIC_IOMAP -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);static inline void pci_iounmap (struct pci_dev *dev,void __iomem *p) { }
Just wondering why you move pci_iomap but not pic_iounmap. And also if pci_iounmap is meant to stay here, then the "struct pci_dev" should probably stay as well.
include/asm-generic/iomap.h extern void ioport_unmap(void __iomem *); · line 72
Quoted 10 lines
include/asm-generic/iomap.h +0
-1@@ -69,16 +69,13 @@ extern void ioport_unmap(void __iomem *);#ifdef CONFIG_PCI /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);
Ditto with pci_iounmap. Also the comment above really belongs with pci_iomap.
Quoted 12 lines
include/asm-generic/pci_iomap.h new file +6
-0@@ -0,0 +1,26 @@ +/* Generic I/O port emulation, based on MN10300 code +* +* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or
include/asm-generic/pci_iomap.h line 16
Quoted 10 lines
include/asm-generic/pci_iomap.h new file +10
-0+* modify it under the terms of the GNU General Public Licence +* as published by the Free Software Foundation; either version +* 2 of the Licence, or (at your option) any later version. +*/ +#ifndef __ASM_GENERIC_PCI_IOMAP_H +#define __ASM_GENERIC_PCI_IOMAP_H + +#ifdef CONFIG_PCI +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev ;
You could move this struct declaration above the ifdef and remove the duplicate below.
Quoted 51 lines
include/asm-generic/pci_iomap.h new file +10
-0+extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max); +#else +struct pci_dev ; +static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) +{ +return NULL ; +} +#endif + +#endif /* __ASM_GENERIC_IO_H */ lib/iomap.c +0
-33@@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);#endif /* CONFIG_HAS_IOPORT */ #ifdef CONFIG_PCI -/** -* pci_iomap - create a virtual mapping cookie for a PCI BAR -* @dev: PCI device that owns the BAR -* @bar: BAR number -* @maxlen: length of the memory to map -* -* Using this function you will get a __iomem address to your device BAR. -* You can access it using ioread*() and iowrite*(). These functions hide -* the details if this is a MMIO or PIO address space and will just do what -* you expect from them in the correct way. -* -* @maxlen specifies the maximum length to map. If you want to get access to -* the complete BAR without checking for its length first, pass %0 here. -* */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ;
lib/iomap.c EXPORT_SYMBOL(ioport_unmap); · line 251
Quoted 10 lines
lib/iomap.c +2
-3-} - +/* Hide the details if this is a MMIO or PIO address space and just do what +* you expect in the correct way. */ void pci_iounmap (struct pci_dev *dev,void __iomem * addr) { IO_COND(addr, /* nothing */, iounmap(addr)); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);
Ditto with pci_iounmap
Quoted 6 lines
lib/pci_iomap.c new file +0
-0
lib/pci_iomap.c line 9
Quoted 9 lines
lib/pci_iomap.c new file +9
-0@@ -0,0 +1,48 @@ +/* +* Implement the default iomap interfaces +* +* (C) Copyright 2004 Linus Torvalds +*/ +#include <linux/pci.h> +#include <linux/io.h> + +#include <linux/module.h>
If this is relative to (at least) v3.2-rc1, then you should use export.h instead of module.h
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
Hi Michael,
Quoted 2 lines · On Fri, 25 Nov 2011 11:54:55 +1100 Stephen Rothwell <[email protected]>…
Just wondering why you move
pci_iomapbut notpic_iounmap.
I figured this out. Arches have their own.
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
Quoted 6 lines · Michael S. Tsirkin
define
GENERIC_IOMAPin a central location instead of all architectures. This will be helpful for the follow-up patch which makes it select other configs. Code is also a bit shorter this way.Signed-off-by Michael S. Tsirkin <[email protected]>
For the CRIS part:
/^JN - Jesper Nilsson
Signature · 1 line
Jesper Nilsson -- [email protected]
Re: [PATCH-RFC 02/10] lib: add GENERIC_PCI_IOMAP
In reply to Stephen RothwellQuoted 20 lines · Stephen Rothwell
Hi Michael,
Quoted 17 lines · On Thu, 24 Nov 2011 22:17:02 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
include/asm-generic/io.h +2
-0@@ -19,6 +19,8 @@#include <asm-generic/iomap.h> #endif +#include <asm-generic/pci_iomap.h> +#ifndef mmiowb#define mmiowb () do {} while (0)#endif @@ -283,9 +285,6 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)#define __io_virt (x) ((void __force *) (x))
Quoted 9 lines
include/asm-generic/io.h static inline void writesb(const void __iomem *addr, const void *buf, int len) · line 290
Quoted 7 lines
include/asm-generic/io.h +0
-3#ifndef CONFIG_GENERIC_IOMAP -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);static inline void pci_iounmap (struct pci_dev *dev,void __iomem *p) { }Just wondering why you move
pci_iomapbut notpic_iounmap.
unmap is implemented significantly different between architectures.
Quoted 3 lines
And also if
pci_iounmapis meant to stay here, then the "structpci_dev" should probably stay as well.
Right. I'll fix that.
Quoted 4 lines
Quoted 4 lines
include/asm-generic/iomap.h +0
-0
Quoted 8 lines
include/asm-generic/iomap.h extern void ioport_unmap(void __iomem *); · line 72
Quoted 6 lines
include/asm-generic/iomap.h +0
-1@@ -69,16 +69,13 @@ extern void ioport_unmap(void __iomem *);#ifdef CONFIG_PCI /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);Ditto with
pci_iounmap.
Answered above :)
Quoted 1 line
Also the comment above really belongs with
pci_iomap.
Right, I'll correct the comment.
Quoted 17 lines
Quoted 17 lines
include/asm-generic/pci_iomap.h new file +11
-0@@ -0,0 +1,26 @@ +/* Generic I/O port emulation, based on MN10300 code +* +* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public Licence +* as published by the Free Software Foundation; either version +* 2 of the Licence, or (at your option) any later version. +*/ +#ifndef __ASM_GENERIC_PCI_IOMAP_H
Quoted 8 lines
include/asm-generic/pci_iomap.h line 16
Quoted 5 lines
include/asm-generic/pci_iomap.h new file +5
-0+#define __ASM_GENERIC_PCI_IOMAP_H + +#ifdef CONFIG_PCI +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +struct pci_dev ;You could move this struct declaration above the ifdef and remove the duplicate below.
Good point. Will do.
Quoted 55 lines
Quoted 55 lines
include/asm-generic/pci_iomap.h new file +10
-0+extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max); +#else +struct pci_dev ; +static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) +{ +return NULL ; +} +#endif + +#endif /* __ASM_GENERIC_IO_H */ lib/iomap.c +2
-35@@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);#endif /* CONFIG_HAS_IOPORT */ #ifdef CONFIG_PCI -/** -* pci_iomap - create a virtual mapping cookie for a PCI BAR -* @dev: PCI device that owns the BAR -* @bar: BAR number -* @maxlen: length of the memory to map -* -* Using this function you will get a __iomem address to your device BAR. -* You can access it using ioread*() and iowrite*(). These functions hide -* the details if this is a MMIO or PIO address space and will just do what -* you expect from them in the correct way. -* -* @maxlen specifies the maximum length to map. If you want to get access to -* the complete BAR without checking for its length first, pass %0 here. -* */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} - +/* Hide the details if this is a MMIO or PIO address space and just do what +* you expect in the correct way. */
Quoted 8 lines
lib/iomap.c EXPORT_SYMBOL(ioport_unmap); · line 251
Quoted 6 lines
lib/iomap.c +0
-1void pci_iounmap (struct pci_dev *dev,void __iomem * addr) { IO_COND(addr, /* nothing */, iounmap(addr)); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);Ditto with
pci_iounmap
Answered above.
Quoted 10 lines
Quoted 10 lines
lib/pci_iomap.c new file +4
-0@@ -0,0 +1,48 @@ +/* +* Implement the default iomap interfaces +* +* (C) Copyright 2004 Linus Torvalds
Quoted 8 lines
lib/pci_iomap.c line 9
Quoted 5 lines
lib/pci_iomap.c new file +5
-0+*/ +#include <linux/pci.h> +#include <linux/io.h> + +#include <linux/module.h> If this is relative to (at least) v3.2-rc1, then you should use
export.hinstead ofmodule.h
I just copied lib/iomap.c
Will fix, thanks for the comments.
Quoted 4 lines
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
PATCH v2 2/10 lib: add GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinMany architectures want a generic pci_iomap but not the rest of iomap.c. Split that to a separate .c file and add a new config symbol. select automatically by GENERIC_IOMAP.
---
Here's an updated version (just this one patch was changed). Changes from v1:
minor tweaks to address comments by Stephen Rothwell
include/asm-generic/io.h | 4 +- include/asm-generic/iomap.h | 9 ++----- include/asm-generic/pci_iomap.h | 25 ++++++++++++++++++++ lib/Kconfig | 4 +++ lib/Makefile | 1 + lib/iomap.c | 38 +----------------------------- lib/pci_iomap.c | 48 +++++++++++++++++++++++++++++++++++++++ 7 files changed, 85 insertions(+), 44 deletions(-) create mode 100644 include/asm-generic/pci_iomap.h create mode 100644 lib/pci_iomap.c
include/asm-generic/io.h +2 -2
@@ -19,6 +19,8 @@#include <asm-generic/iomap.h> #endif +#include <asm-generic/pci_iomap.h> +#ifndef mmiowb#define mmiowb () do {} while (0)#endif
@@ -283,9 +285,7 @@ static inline void writesb(const void __iomem *addr, const void *buf, int len)#define __io_virt (x) ((void __force *) (x))#ifndef CONFIG_GENERIC_IOMAP -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);static inline void pci_iounmap (struct pci_dev *dev,void __iomem *p) { }
include/asm-generic/iomap.h +3 -6
@@ -67,18 +67,15 @@ extern void ioport_unmap(void __iomem *);#endif #ifdef CONFIG_PCI -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +/* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);#else struct pci_dev ; -static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -return NULL ; -}static inline void pci_iounmap (struct pci_dev *dev,void __iomem *addr) { }#endif +#include <asm-generic/pci_iomap.h> +#endif
include/asm-generic/pci_iomap.h new file +25 -0
@@ -0,0 +1,25 @@ +/* Generic I/O port emulation, based on MN10300 code +* +* Copyright (C) 2007 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public Licence +* as published by the Free Software Foundation; either version +* 2 of the Licence, or (at your option) any later version. +*/ +#ifndef __ASM_GENERIC_PCI_IOMAP_H +#define __ASM_GENERIC_PCI_IOMAP_H + +struct pci_dev ; +#ifdef CONFIG_PCI +/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ +extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max); +#else +static inline void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) +{ +return NULL ; +} +#endif + +#endif /* __ASM_GENERIC_IO_H */
lib/Kconfig +4 -0
@@ -19,8 +19,12 @@ config RATIONAL config GENERIC_FIND_FIRST_BIT bool +config GENERIC_PCI_IOMAP + bool + config GENERIC_IOMAP bool + select GENERIC_PCI_IOMAP config CRC_CCITT tristate "CRC-CCITT functions"
lib/Makefile +1 -0
@@ -33,6 +33,7 @@ endif lib-$(CONFIG_HOTPLUG) += kobject_uevent.o obj-$(CONFIG_GENERIC_IOMAP) += iomap.o +obj-$(CONFIG_GENERIC_PCI_IOMAP) += pci_iomap.o obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o obj-$(CONFIG_CHECK_SIGNATURE) += check_signature.o obj-$(CONFIG_DEBUG_LOCKING_API_SELFTESTS) += locking-selftest.o
lib/iomap.c +2 -36
@@ -242,45 +242,11 @@ EXPORT_SYMBOL(ioport_unmap);#endif /* CONFIG_HAS_IOPORT */ #ifdef CONFIG_PCI -/** -* pci_iomap - create a virtual mapping cookie for a PCI BAR -* @dev: PCI device that owns the BAR -* @bar: BAR number -* @maxlen: length of the memory to map -* -* Using this function you will get a __iomem address to your device BAR. -* You can access it using ioread*() and iowrite*(). These functions hide -* the details if this is a MMIO or PIO address space and will just do what -* you expect from them in the correct way. -* -* @maxlen specifies the maximum length to map. If you want to get access to -* the complete BAR without checking for its length first, pass %0 here. -* */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} - +/* Hide the details if this is a MMIO or PIO address space and just do what +* you expect in the correct way. */ void pci_iounmap (struct pci_dev *dev,void __iomem * addr) { IO_COND(addr, /* nothing */, iounmap(addr)); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);#endif /* CONFIG_PCI */
lib/pci_iomap.c new file +48 -0
48 lines not on this page · raw message
Signature · 1 line
1.7.5.53.gc233e
Quoted 4 lines · Michael S. Tsirkin
define
GENERIC_IOMAPin a central location instead of all architectures. This will be helpful for the follow-up patch which makes it select other configs. Code is also a bit shorter this way.
For the Hexagon config,
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 6 lines · Michael S. Tsirkin
mips copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>---
Sorry to nag, any ACKs/NACKs on the mips part?
I intend to send this to Linus if there are no
objections. Thanks!
Quoted 55 lines
arch/mips/Kconfig | 1 + arch/mips/lib/iomap-pci.c | 26 -------------------------- 2 files changed, 1 insertions(+), 26 deletions(-)arch/mips/Kconfig +1
-0@@ -2317,6 +2317,7 @@ config PCI bool "Support for PCI controller" depends on HW_HAS_PCI select PCI_DOMAINS + select GENERIC_PCI_IOMAP help Find out whether you have a PCI motherboard. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff insidearch/mips/lib/iomap-pci.c +0
-26@@ -40,32 +40,6 @@ static void __iomem *ioport_map_pci(struct pci_dev *dev,return (void __iomem *) (ctrl->io_map_base + port); } -/* -* Create a virtual mapping cookie for a PCI BAR (memory or IO) -*/ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map_pci (dev, start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} - -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {iounmap (addr);Signature · 1 line
1.7.5.53.gc233e
Re: [PATCH-RFC 08/10] powerpc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 10 lines · Michael S. Tsirkin
powerpc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code sincearch/powerpc/include/asm/io.h
definesioremap_nocachesame as ioremap.Signed-off-by Michael S. Tsirkin <[email protected]>
Sorry to nag, any ACKs/NACKs on the powerpc changes? I intend to send this to Linus if there are no objections. Thanks!
Quoted 55 lines
--- arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/iomap.c | 19 ------------------- 2 files changed, 1 insertions(+), 19 deletions(-)arch/powerpc/Kconfig +1
-0@@ -710,6 +710,7 @@ config PCI default PCI_PERMEDIA if !4xx && !CPM2 && !8xx default PCI_QSPAN if !4xx && !CPM2 && 8xx select ARCH_SUPPORTS_MSI + select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff insidearch/powerpc/kernel/iomap.c +0
-19@@ -119,24 +119,6 @@ EXPORT_SYMBOL(ioport_map);EXPORT_SYMBOL (ioport_unmap);#ifdef CONFIG_PCI -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len) -return NULL ; -if (max && len > max) - len = max; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) -return ioremap (start, len); -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) {if (isa_vaddr_is_ioport (addr))@@ -146,6 +128,5 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr) iounmap(addr); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);#endif /* CONFIG_PCI */ Signature · 1 line
1.7.5.53.gc233e
PATCH 4/10 arm: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 6 lines · Michael S. Tsirkin
arm copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>---
Sorry to nag, any ACKs/NACKs on the arm part?
I intend to send this to Linus if there are no
objections. Thanks!
Quoted 71 lines
arch/arm/Kconfig | 1 + arch/arm/include/asm/io.h | 2 +- arch/arm/mm/iomap.c | 21 --------------------- 3 files changed, 2 insertions(+), 22 deletions(-)arch/arm/Kconfig +1
-0@@ -30,6 +30,7 @@ config ARM select HAVE_SPARSE_IRQ select GENERIC_IRQ_SHOW select CPU_PM if (SUSPEND || CPU_IDLE) + select GENERIC_PCI_IOMAP help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications andarch/arm/include/asm/io.h +1
-1@@ -27,6 +27,7 @@#include <asm/byteorder.h> #include <asm/memory.h> #include <asm/system.h> +#include <asm-generic/pci_iomap.h> /* * ISA I/O bus memory addresses are 1:1 with the physical address. @@ -306,7 +307,6 @@ extern void ioport_unmap(void __iomem *addr);struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen);extern void pci_iounmap (struct pci_dev *dev,void __iomem *addr);/* arch/arm/mm/iomap.c +0
-21@@ -35,27 +35,6 @@ EXPORT_SYMBOL(pcibios_min_mem);unsigned int pci_flags =PCI_REASSIGN_ALL_RSRC ;EXPORT_SYMBOL (pci_flags); -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -return NULL ; -} -EXPORT_SYMBOL (pci_iomap); -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) { if ((unsigned long)addr >= VMALLOC_START &&Signature · 1 line
1.7.5.53.gc233e
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!
Quoted 58 lines
--- arch/parisc/Kconfig | 1 + arch/parisc/lib/iomap.c | 23 ----------------------- 2 files changed, 1 insertions(+), 23 deletions(-)arch/parisc/Kconfig +1
-0@@ -14,6 +14,7 @@ config PARISC select GENERIC_ATOMIC64 if !64BIT select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_PROBE + select GENERIC_PCI_IOMAP select IRQ_PER_CPU select ARCH_HAVE_NMI_SAFE_CMPXCHGarch/parisc/lib/iomap.c +0
-23@@ -436,28 +436,6 @@ void ioport_unmap(void __iomem *addr) } } -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {if (!INDIRECT_ADDR (addr)) {@@ -483,5 +461,4 @@ EXPORT_SYMBOL(iowrite16_rep);EXPORT_SYMBOL (iowrite32_rep);EXPORT_SYMBOL (ioport_map);EXPORT_SYMBOL (ioport_unmap); -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);Signature · 1 line
1.7.5.53.gc233e
Re: [PATCH-RFC 03/10] alpha: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 10 lines · Michael S. Tsirkin
alpha copied
pci_iomapfrom generic code to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.The only difference is handling of nocache flag, that turns out to be done correctly by the generic code since
arch/alpha/include/asm/io.hdefinesioremap_nocachesame as ioremap.Signed-off-by Michael S. Tsirkin <[email protected]>
Sorry to nag - any ACKs/NACKs on the alpha changes
(both this, and 'alpha: drop pci_iomap/pci_iounmap from pci-noop.c')? I intend to send this to Linus if there are no objections. Thanks!
Quoted 63 lines
--- arch/alpha/Kconfig | 1 + arch/alpha/kernel/pci.c | 26 +------------------------- 2 files changed, 2 insertions(+), 25 deletions(-)arch/alpha/Kconfig +1
-0@@ -315,6 +315,7 @@ config ISA_DMA_API config PCI bool depends on !ALPHA_JENSEN + select GENERIC_PCI_IOMAP default y help Find out whether you have a PCI motherboard. PCI is the name of aarch/alpha/kernel/pci.c +1
-25@@ -508,30 +508,7 @@ sys_pciconfig_iobase(long which, unsigned long bus, unsigned long dfn)return -EOPNOTSUPP ; } -/* Create an __iomem token from a PCI BAR. Copied from lib/iomap.c with -no changes, since we don't want the other things in that object file. */ - -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -/* Not checking IORESOURCE_CACHEABLE because alpha does -not distinguish between ioremap and ioremap_nocache. */ -return ioremap (start, len); - } -return NULL ; -} - -/* Destroy that token. Not copied from lib/iomap.c. */ +/* Destroy an __iomem token. Not copied from lib/iomap.c. */ void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {@@ -539,7 +516,6 @@ void pci_iounmap(struct pci_dev *dev, void __iomem * addr)iounmap (addr); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);/* FIXME: Some boxes have multiple ISA bridges! */ Signature · 1 line
1.7.5.53.gc233e
James Bottomley
maintainerRe: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 10 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!
Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer IORESOURCE_MEM over IORESOURCE_IO when both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.
James
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 8 lines · James Bottomley
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>
Quoted 7 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
I think it's trivial but I don't have the setup to even compile it so depend on someone to ack.
Quoted 9 lines
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEMoverIORESOURCE_IOwhen both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.James
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Signature · 1 line
MST
James Bottomley
maintainerRe: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 28 lines · Michael S. Tsirkin
Quoted 8 lines · James Bottomley
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>Quoted 7 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
I think it's trivial but I don't have the setup to even compile it so depend on someone to ack.
Quoted 8 lines
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEMoverIORESOURCE_IOwhen both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.
Quoted 4 lines
Quoted 1 line
James
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Could be ... I know we've had issues in the past with standard drivers like the sym53c8xx which map via both and operate far less efficiently over I/O ... but that could have been different bars I suppose (it's so long ago that I can't remember).
James
PATCH v2 10/10 sparc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. Tsirkinsparc copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
---
Changes from v1:
remove ifdef __KERNEL__ from files
not exported to userspace.
arch/sparc/Kconfig | 1 + arch/sparc/include/asm/io_32.h | 2 +- arch/sparc/include/asm/io_64.h | 2 +- arch/sparc/lib/iomap.c | 23 ----------------------- 4 files changed, 3 insertions(+), 25 deletions(-)
arch/sparc/Kconfig +1 -0
@@ -28,6 +28,7 @@ config SPARC select HAVE_GENERIC_HARDIRQS select GENERIC_IRQ_SHOW select USE_GENERIC_SMP_HELPERS if SMP + select GENERIC_PCI_IOMAP config SPARC32 def_bool !64BIT
arch/sparc/include/asm/io_32.h +1 -1
@@ -7,6 +7,7 @@#include <asm/page.h> /* IO address mapping routines need this */ #include <asm/system.h> +#include <asm-generic/pci_iomap.h> #define page_to_phys (page) (page_to_pfn(page) << PAGE_SHIFT)
@@ -324,7 +325,6 @@ extern void ioport_unmap(void __iomem *);/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);/*
arch/sparc/include/asm/io_64.h +1 -1
@@ -8,6 +8,7 @@#include <asm/page.h> /* IO address mapping routines need this */ #include <asm/system.h> #include <asm/asi.h> +#include <asm-generic/pci_iomap.h> /* PC crapola... */ #define __SLOW_DOWN_IO do { } while (0)
@@ -514,7 +515,6 @@ extern void ioport_unmap(void __iomem *);/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ struct pci_dev ; -extern void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max);extern void pci_iounmap (struct pci_dev *dev,void __iomem *);static inline int sbus_can_dma_64bit (void )
arch/sparc/lib/iomap.c +0 -23
@@ -18,31 +18,8 @@ void ioport_unmap(void __iomem *addr)EXPORT_SYMBOL (ioport_map);EXPORT_SYMBOL (ioport_unmap); -/* Create a virtual mapping cookie for a PCI BAR (memory or IO) */ -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long maxlen) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len || !start) -return NULL ; -if (maxlen && len > maxlen) - len = maxlen; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) { -if (flags &IORESOURCE_CACHEABLE ) -return ioremap (start, len); -return ioremap_nocache (start, len); - } -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem * addr) {/* nothing to do */ } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);
Signature · 1 line
1.7.5.53.gc233e
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to James BottomleyQuoted 31 lines · James Bottomley
Quoted 30 lines · Michael S. Tsirkin
Quoted 8 lines · James Bottomley
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>Quoted 7 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
I think it's trivial but I don't have the setup to even compile it so depend on someone to ack.
Quoted 9 lines
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEMoverIORESOURCE_IOwhen both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.James
Quoted 7 lines
Quoted 2 lines
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Could be ... I know we've had issues in the past with standard drivers like the sym53c8xx which map via both and operate far less efficiently over I/O ... but that could have been different bars I suppose (it's so long ago that I can't remember).
Probably, it looks like it has both mmio and io:
drivers/scsi/sym53c8xx_2/sym_glue.c
#ifdef CONFIG_SCSI_SYM53C8XX_MMIO
if (device->mmio_base)
device->s.ioaddr = pci_iomap(pdev, 1,
pci_resource_len(pdev, 1));
#endif
if (!device->s.ioaddr)
device->s.ioaddr = pci_iomap(pdev, 0,
pci_resource_len(pdev, 0));so ... ACK?
Quoted 3 lines
James
Signature · 1 line
MSt
Re: [PATCH-RFC 08/10] powerpc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 10 lines · Michael S. Tsirkin
Quoted 9 lines · Michael S. Tsirkin
powerpc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code sincearch/powerpc/include/asm/io.h
definesioremap_nocachesame as ioremap.
Quoted 6 lines
Quoted 1 line
Signed-off-by Michael S. Tsirkin <[email protected]>Sorry to nag, any ACKs/NACKs on the powerpc changes? I intend to send this to Linus if there are no objections. Thanks!
Ah sorry, forgot about that. Do you have a git tree I can pull to do quick test ?
No objection in principle.
Cheers,
Ben.
Quoted 55 lines
Quoted 55 lines
--- arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/iomap.c | 19 ------------------- 2 files changed, 1 insertions(+), 19 deletions(-)arch/powerpc/Kconfig +1
-0@@ -710,6 +710,7 @@ config PCI default PCI_PERMEDIA if !4xx && !CPM2 && !8xx default PCI_QSPAN if !4xx && !CPM2 && 8xx select ARCH_SUPPORTS_MSI + select GENERIC_PCI_IOMAP help Find out whether your system includes a PCI bus. PCI is the name of a bus system, i.e. the way the CPU talks to the other stuff insidearch/powerpc/kernel/iomap.c +0
-19@@ -119,24 +119,6 @@ EXPORT_SYMBOL(ioport_map);EXPORT_SYMBOL (ioport_unmap);#ifdef CONFIG_PCI -void __iomem *pci_iomap (struct pci_dev *dev,int bar,unsigned long max) -{ -resource_size_t start =pci_resource_start (dev, bar); -resource_size_t len =pci_resource_len (dev, bar); -unsigned long flags =pci_resource_flags (dev, bar); - -if (!len) -return NULL ; -if (max && len > max) - len = max; -if (flags &IORESOURCE_IO ) -return ioport_map (start, len); -if (flags &IORESOURCE_MEM ) -return ioremap (start, len); -/* What? */ -return NULL ; -} -void pci_iounmap (struct pci_dev *dev,void __iomem *addr) {if (isa_vaddr_is_ioport (addr))@@ -146,6 +128,5 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *addr) iounmap(addr); } -EXPORT_SYMBOL (pci_iomap);EXPORT_SYMBOL (pci_iounmap);#endif /* CONFIG_PCI */ Signature · 1 line
1.7.5.53.gc233e
PATCH 4/10 arm: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 11 lines · Michael S. Tsirkin
Quoted 6 lines · Michael S. Tsirkin
arm copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>---
Sorry to nag, any ACKs/NACKs on the arm part?
I intend to send this to Linus if there are no
objections. Thanks!
As there's no difference between the generic version and this version you're removing...
Re: [PATCH-RFC 08/10] powerpc: switch to GENERIC_PCI_IOMAP
In reply to Benjamin HerrenschmidtQuoted 14 lines · Benjamin Herrenschmidt
Quoted 13 lines · Michael S. Tsirkin
Quoted 10 lines · Michael S. Tsirkin
powerpc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.The only difference is handling of nocache flag,
that turns out to be done correctly by the
generic code sincearch/powerpc/include/asm/io.h
definesioremap_nocachesame as ioremap.Signed-off-by Michael S. Tsirkin <[email protected]>
Quoted 6 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the powerpc changes? I intend to send this to Linus if there are no objections. Thanks!
Ah sorry, forgot about that. Do you have a git tree I can pull to do quick test ?
Yes.
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
Thanks!
Quoted 4 lines
No objection in principle.
Cheers,
Ben.
James Bottomley
maintainerRe: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 54 lines · Michael S. Tsirkin
Quoted 31 lines · James Bottomley
Quoted 30 lines · Michael S. Tsirkin
Quoted 8 lines · James Bottomley
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>Quoted 7 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
I think it's trivial but I don't have the setup to even compile it so depend on someone to ack.
Quoted 9 lines
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEMoverIORESOURCE_IOwhen both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.James
Quoted 7 lines
Quoted 2 lines
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Could be ... I know we've had issues in the past with standard drivers like the sym53c8xx which map via both and operate far less efficiently over I/O ... but that could have been different bars I suppose (it's so long ago that I can't remember).
Probably, it looks like it has both mmio and io:
drivers/scsi/sym53c8xx_2/sym_glue.c#ifdef CONFIG_SCSI_SYM53C8XX_MMIO if (device->mmio_base) device->s.ioaddr = pci_iomap(pdev, 1, pci_resource_len(pdev, 1)); #endif if (!device->s.ioaddr) device->s.ioaddr = pci_iomap(pdev, 0, pci_resource_len(pdev, 0));
Quoted 1 line
so ... ACK?
Um, well, it looks like a trivial code shift, so it doesn't really need one (it can just go through the trivial tree). Unless there's some reason actually to test it out on parisc because something will break (in which case, I'll need the actual patch, not just a quoted one).
James
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 55 lines · James Bottomley
Quoted 54 lines · Michael S. Tsirkin
Quoted 31 lines · James Bottomley
Quoted 30 lines · Michael S. Tsirkin
Quoted 8 lines · James Bottomley
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines · Michael S. Tsirkin
parisc copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.Signed-off-by Michael S. Tsirkin <[email protected]>Quoted 7 lines
Quoted 3 lines
Sorry to nag, any ACKs/NACKs on the parisc part?
I intend to send this to Linus if there are no
objections. Thanks!Next time, send the patch to linux-arch or linux-parisc ... it helps to get people to review it. Although this one looks completely trivial, unless I'm missing something?
I think it's trivial but I don't have the setup to even compile it so depend on someone to ack.
Quoted 9 lines
Obviously there was a bit of a brain fart when this was done: the parisc piece shouldn't be a copy of the generic code: we don't have native i/o ports and emulation is pretty expensive, so we should prefer
IORESOURCE_MEMoverIORESOURCE_IOwhen both are available ... but even on x86, memory mapping is faster (although not by the order of magnitude it is on parisc), so it looks like you could fix this in the generic code.James
Quoted 7 lines
Quoted 2 lines
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Could be ... I know we've had issues in the past with standard drivers like the sym53c8xx which map via both and operate far less efficiently over I/O ... but that could have been different bars I suppose (it's so long ago that I can't remember).
Probably, it looks like it has both mmio and io:
drivers/scsi/sym53c8xx_2/sym_glue.c#ifdef CONFIG_SCSI_SYM53C8XX_MMIO if (device->mmio_base) device->s.ioaddr = pci_iomap(pdev, 1, pci_resource_len(pdev, 1)); #endif if (!device->s.ioaddr) device->s.ioaddr = pci_iomap(pdev, 0, pci_resource_len(pdev, 0));
Quoted 4 lines
Quoted 1 line
so ... ACK?
Um, well, it looks like a trivial code shift, so it doesn't really need one (it can just go through the trivial tree).
It's part of a larger set not all of which is trivial.
Quoted 5 lines
Unless there's some
reason actually to test it out on parisc because something will break (in which case, I'll need the actual patch, not just a quoted one).James
A build test would be nice. Just forwarded you a patch. It's also on linux-next.
Signature · 1 line
MST
James Bottomley
maintainerRe: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 6 lines · Michael S. Tsirkin
Quoted 4 lines
Quoted 1 line
so ... ACK?
Um, well, it looks like a trivial code shift, so it doesn't really need one (it can just go through the trivial tree).
It's part of a larger set not all of which is trivial.
OK, so it looks fine to me.
Quoted 8 lines
Quoted 5 lines
Unless there's some
reason actually to test it out on parisc because something will break (in which case, I'll need the actual patch, not just a quoted one).James
A build test would be nice. Just forwarded you a patch. It's also on linux-next.
Actually, sending it to me doesn't help. Being busy and lazy, I want to see if someone else will test it ... that's why we send patches to the list.
James
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinOn Sun, Dec 4, 2011 at 6:30 AM, Michael S. Tsirkin <[email protected]> wrote:
...
Quoted 2 lines
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Yes, a particular PCI BAR (Base Address Register) is either IO or MEM (not both) address space resource.
James is observing many older devices have the same set of registers mapped in both address spaces using two BARs. As you already know, MMIO is "lighter weight" (CPU cost to generate transactions on PCI bus). I think this is orthogonal to the issue you are addressing.
Regarding handling of IO Port space cookies:
arch/parisc/lib/iomap.c void ioport_unmap(void __iomem *addr) · line 451
Quoted 2 lines
arch/parisc/lib/iomap.c +0
-2-if (flags &IORESOURCE_IO ) -return ioport_map (start, len);
I don't know who all the consumers of pci_iomap() are. If user space can somehow call this, it should fail for IO port space "mappings" since unlike x86, parisc has no INB/OUTB instructions. Generating IO Port space requires frobbing PCI Bus controller registers that I don't think we want to expose to user space.
I'm going to assume this is NOT a problem since any code that generates anything that tries to look like an INB/OUTB just won't compile on parisc. I think removing the parisc specific definition and using the generic one instead looks fine to me. But I'm not confident enough to offer a formal ACKed-by line. Sorry. :(
cheers,
grant
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 23 lines · Grant Grundler
On Sun, Dec 4, 2011 at 6:30 AM, Michael S. Tsirkin <[email protected]> wrote:
...Quoted 2 lines
AFAIK, on PCI a resource is either IO or MEM, but never both. What am I missing?
Yes, a particular PCI BAR (Base Address Register) is either IO or MEM (not both) address space resource.
James is observing many older devices have the same set of registers mapped in both address spaces using two BARs. As you already know, MMIO is "lighter weight" (CPU cost to generate transactions on PCI bus). I think this is orthogonal to the issue you are addressing.
Regarding handling of IO Port space cookies:
arch/parisc/lib/iomap.c void ioport_unmap(void __iomem *addr) · line 451
Quoted 2 lines
arch/parisc/lib/iomap.c +0
-2-if (flags &IORESOURCE_IO ) -return ioport_map (start, len);I don't know who all the consumers of
pci_iomap()are. If user space can somehow call this, it should fail for IO port space "mappings" since unlike x86, parisc has no INB/OUTB instructions. Generating IO Port space requires frobbing PCI Bus controller registers that I don't think we want to expose to user space.
Quoted 8 lines
I'm going to assume this is NOT a problem since any code that generates anything that tries to look like an INB/OUTB just won't compile on parisc. I think removing the parisc specific definition and using the generic one instead looks fine to me. But I'm not confident enough to offer a formal ACKed-by line. Sorry. :(
cheers,
grant
How about a Tested-by line? I presume you have the hardware to try this out? You can also get the patches from my tree:git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next or from linux-next.
Signature · 1 line
MST
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
On Tue, Dec 6, 2011 at 3:06 AM, Michael S. Tsirkin <[email protected]> wro= te:
Quoted 1 line · Grant Grundler
=2E..
Quoted 3 lines
Quoted 3 lines
I'm going to assume this is NOT a problem since any code that generates anything that tries to look like an INB/OUTB just won't compile on parisc. =C2=A0I think removing the parisc specific defini=
tion
Quoted 1 line
Quoted 1 line
and using the generic one instead looks fine to me. =C2=A0But I'm no=
t
Quoted 7 lines
Quoted 4 lines
confident enough to offer a formal ACKed-by line. Sorry. :(
cheers,
grantHow about a Tested-by line? I presume you have the hardware to try this out?
I do have the HW at home to test this...but it's not been powered up in 6+ months. I have to point dpkg at a new repository and update all the SW on the machine. If you don't mind waiting another week, I'll make time to do that later this week (or weekend).
Quoted 2 lines
You can also get the patches from my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.gitlinux-nex=
t
Quoted 1 line
or from linux-next.
That's easy enough - thanks!
grant
Quoted 3 lines
--
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
Quoted 1 line · Grant Grundler
On Tue, Dec 6, 2011 at 3:06 AM, Michael S. Tsirkin <[email protected]> w=
rote:
Quoted 5 lines
Quoted 1 line · Grant Grundler
...
Quoted 3 lines
Quoted 3 lines
I'm going to assume this is NOT a problem since any code that generates anything that tries to look like an INB/OUTB just won't compile on parisc. =A0I think removing the parisc specific definit=
ion
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
and using the generic one instead looks fine to me. =A0But I'm not confident enough to offer a formal ACKed-by line. Sorry. :(
cheers,
grant
Quoted 10 lines
Quoted 2 lines
How about a Tested-by line? I presume you have the hardware to try this out?
=20
I do have the HW at home to test this...but it's not been powered up in 6+ months. I have to point dpkg at a new repository and update all the SW on the machine. If you don't mind waiting another week, I'll make time to do that later this week (or weekend).Quoted 2 lines
You can also get the patches from my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.gitlinux-n=
ext
Quoted 4 lines
Quoted 1 line
or from linux-next.
=20
That's easy enough - thanks!
grant
Waiting for 3.4 window to open anyway, so yes that will be nice. Thanks!
--=20
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC 03/10] alpha: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 10 lines · Michael S. Tsirkin
alpha copied
pci_iomapfrom generic code to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.The only difference is handling of nocache flag, that turns out to be done correctly by the generic code since
arch/alpha/include/asm/io.hdefinesioremap_nocachesame as ioremap.Signed-off-by Michael S. Tsirkin <[email protected]>
[snip]
WFM on my DS20E using 3.2.0-rc4-00231-g958c6c2
so,
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RFC 07/10] parisc: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinOn Tue, Dec 6, 2011 at 8:24 AM, Michael S. Tsirkin <[email protected]> wrote:
...
Quoted 5 lines
Quoted 5 lines
I do have the HW at home to test this...but it's not been powered up in 6+ months. I have to point dpkg at a new repository and update all the SW on the machine. If you don't mind waiting another week, I'll make time to do that later this week (or weekend).
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
You can also get the patches from my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.gitlinux-next or from linux-next.That's easy enough - thanks!
grantWaiting for 3.4 window to open anyway, so yes that will be nice.
Michael,
Just an update that I haven't forgotten your request. I tried to update the machine on Monday and the current state of hppa for debian-ports is dselect can't resolve dependencies on versions of packages because those versions don't exist for hppa. I've just asked for help with this on debian-hppa mailing list and will see if we can get this machine updated.
cheers,
grant
Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
In reply to Michael S. TsirkinQuoted 3 lines · Michael S. Tsirkin
mips copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.
[snip]
Quoted 2 lines
- if (flags &
IORESOURCE_IO)
- returnioport_map_pci(dev, start, len);
While investigating a new warning on the 3.3-rc1 MIPS build (unused static function ioport_map_pci()), I noticed that this patch has shown up in Linus' tree as commit eab90291d35438bcebf7c3dc85be66d0f24e3002.
I am not completely clear on the implications it has on mapping PCI I/O regions:
Prior to this change, the MIPS version of pci_iomap() called a MIPS-specific function, ioport_map_pci(), which tried to use the PCI controller's io_map_base field to determine the base address of the PCI I/O space. It also had a fallback mechanism to deal with the case where io_map_base is unset.
Now, in 3.3-rc1, the generic version of pci_iomap() is used instead. This code just calls arch/mips/lib/iomap.c:ioport_map() on these regions. ioport_map() falls through to ioport_map_legacy(), which always uses mips_io_port_base (not the PCI controller's io_map_base) as the base address. But on MIPS, it is still permissible to use different I/O port bases for PCI devices and for legacy (ISA?) devices.
Is this new behavior desirable, or are there any supported platforms on which adverse effects might be seen?
As for my part, I don't use PCI I/O regions at all - just memory regions. I'm more worried about making sure my tree builds with 0 warnings.
If we do want to move ahead with the switch to GENERIC_PCI_IOMAP now, I have patches to scrap iomap-pci.c entirely and squash the unused function warning.
If we still want to support the case where io_map_base != mips_io_port_base, maybe it would be better to revert commit eab90291 for 3.3.
Might also want to take a look at SH since it also appears to have an orphaned ioport_map_pci() function.
What are your thoughts?
Re: [PATCH-RFC 06/10] mips: switch to GENERIC_PCI_IOMAP
Quoted 7 lines · Kevin Cernekee
Quoted 3 lines · Michael S. Tsirkin
mips copied
pci_iomapfrom generic code, probably to avoid pulling the rest ofiomap.cin. Since that's in
a separate file now, we can reuse the common implementation.[snip]
Quoted 8 lines
Quoted 2 lines
- if (flags &
IORESOURCE_IO)
- returnioport_map_pci(dev, start, len);While investigating a new warning on the 3.3-rc1 MIPS build (unused static function
ioport_map_pci()), I noticed that this patch has shown up in Linus' tree as commiteab90291d35438bcebf7c3dc85be66d0f24e3002.I am not completely clear on the implications it has on mapping PCI I/O regions:
Yes, my bad, I missed the difference between ioport_map_pci and ioport_map for both MIPS and SH.
I'll post a patch to fix this, which is probably preferable to reintroducing the code duplication where it might trip us up again.
Signature · 1 line
MST