linux_dsm_epyc7002/arch/powerpc/include/asm/io.h

844 lines
27 KiB
C
Raw Normal View History

#ifndef _ASM_POWERPC_IO_H
#define _ASM_POWERPC_IO_H
#ifdef __KERNEL__
#define ARCH_HAS_IOREMAP_WC
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
/* Check of existence of legacy devices */
extern int check_legacy_ioport(unsigned long base_port);
#define I8042_DATA_REG 0x60
#define FDC_BASE 0x3f0
#if defined(CONFIG_PPC64) && defined(CONFIG_PCI)
extern struct pci_dev *isa_bridge_pcidev;
/*
* has legacy ISA devices ?
*/
#define arch_has_dev_port() (isa_bridge_pcidev != NULL || isa_io_special)
#endif
#include <linux/device.h>
#include <linux/io.h>
#include <linux/compiler.h>
#include <asm/page.h>
#include <asm/byteorder.h>
#include <asm/synch.h>
#include <asm/delay.h>
#include <asm/mmu.h>
#include <asm-generic/iomap.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#endif
#define SIO_CONFIG_RA 0x398
#define SIO_CONFIG_RD 0x399
#define SLOW_DOWN_IO
/* 32 bits uses slightly different variables for the various IO
* bases. Most of this file only uses _IO_BASE though which we
* define properly based on the platform
*/
#ifndef CONFIG_PCI
#define _IO_BASE 0
#define _ISA_MEM_BASE 0
#define PCI_DRAM_OFFSET 0
#elif defined(CONFIG_PPC32)
#define _IO_BASE isa_io_base
#define _ISA_MEM_BASE isa_mem_base
#define PCI_DRAM_OFFSET pci_dram_offset
#else
#define _IO_BASE pci_io_base
#define _ISA_MEM_BASE isa_mem_base
#define PCI_DRAM_OFFSET 0
#endif
extern unsigned long isa_io_base;
extern unsigned long pci_io_base;
extern unsigned long pci_dram_offset;
extern resource_size_t isa_mem_base;
/* Boolean set by platform if PIO accesses are suppored while _IO_BASE
* is not set or addresses cannot be translated to MMIO. This is typically
* set when the platform supports "special" PIO accesses via a non memory
* mapped mechanism, and allows things like the early udbg UART code to
* function.
*/
extern bool isa_io_special;
#ifdef CONFIG_PPC32
#if defined(CONFIG_PPC_INDIRECT_PIO) || defined(CONFIG_PPC_INDIRECT_MMIO)
#error CONFIG_PPC_INDIRECT_{PIO,MMIO} are not yet supported on 32 bits
#endif
#endif
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
*
* Low level MMIO accessors
*
* This provides the non-bus specific accessors to MMIO. Those are PowerPC
* specific and thus shouldn't be used in generic code. The accessors
* provided here are:
*
* in_8, in_le16, in_be16, in_le32, in_be32, in_le64, in_be64
* out_8, out_le16, out_be16, out_le32, out_be32, out_le64, out_be64
* _insb, _insw_ns, _insl_ns, _outsb, _outsw_ns, _outsl_ns
*
* Those operate directly on a kernel virtual address. Note that the prototype
* for the out_* accessors has the arguments in opposite order from the usual
* linux PCI accessors. Unlike those, they take the address first and the value
* next.
*
* Note: I might drop the _ns suffix on the stream operations soon as it is
* simply normal for stream operations to not swap in the first place.
*
*/
#ifdef CONFIG_PPC64
#define IO_SET_SYNC_FLAG() do { local_paca->io_sync = 1; } while(0)
#else
#define IO_SET_SYNC_FLAG()
#endif
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
/* gcc 4.0 and older doesn't have 'Z' constraint */
#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ == 0)
#define DEF_MMIO_IN_X(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline u##size name(const volatile u##size __iomem *addr) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
{ \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
u##size ret; \
__asm__ __volatile__("sync;"#insn" %0,0,%1;twi 0,%0,0;isync" \
: "=r" (ret) : "r" (addr), "m" (*addr) : "memory"); \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
return ret; \
}
#define DEF_MMIO_OUT_X(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline void name(volatile u##size __iomem *addr, u##size val) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
{ \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
__asm__ __volatile__("sync;"#insn" %1,0,%2" \
: "=m" (*addr) : "r" (val), "r" (addr) : "memory"); \
IO_SET_SYNC_FLAG(); \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
}
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
#else /* newer gcc */
#define DEF_MMIO_IN_X(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline u##size name(const volatile u##size __iomem *addr) \
{ \
u##size ret; \
__asm__ __volatile__("sync;"#insn" %0,%y1;twi 0,%0,0;isync" \
: "=r" (ret) : "Z" (*addr) : "memory"); \
return ret; \
}
#define DEF_MMIO_OUT_X(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline void name(volatile u##size __iomem *addr, u##size val) \
{ \
__asm__ __volatile__("sync;"#insn" %1,%y0" \
: "=Z" (*addr) : "r" (val) : "memory"); \
IO_SET_SYNC_FLAG(); \
}
#endif
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define DEF_MMIO_IN_D(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline u##size name(const volatile u##size __iomem *addr) \
{ \
u##size ret; \
__asm__ __volatile__("sync;"#insn"%U1%X1 %0,%1;twi 0,%0,0;isync"\
: "=r" (ret) : "m" (*addr) : "memory"); \
return ret; \
}
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define DEF_MMIO_OUT_D(name, size, insn) \
powerpc: Improve (in|out)_[bl]eXX() asm code Since commit 4cb3cee03d558fd457cb58f56c80a2a09a66110c the code generated for the in_beXX() and out_beXX() mmio functions has been sub-optimal. The out_leXX() family of functions are created with the macro DEF_MMIO_OUT_LE() while the out_beXX() family are created with DEF_MMIO_OUT_BE(). In what was perhaps a bit too much macro use, both of these macros are in turn created via the macro DEF_MMIO_OUT(). For the LE versions, eventually they boil down to an asm that will look something like this: asm("sync; stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)); The issue is that the "stwbrx" instruction only comes in an indexed, or 'x', version, in which the address is represented by the sum of two registers (the "0,%2"). Unfortunately, gcc doesn't have a constraint for an indexed memory reference. The "m" constraint allows both indexed and offset, i.e. register plus constant, memory references and there is no "stwbr" version for offset references. "m" also allows updating addresses and there is no 'u' version of "stwbrx" like there is with "stwux". The unused first operand to the asm is just to tell gcc that *addr is an output of the asm. The address used is passed in a single register via the third asm operand, and the index register is just hard coded as 0. This means gcc is forced to put the address in a single register and can't use index addressing, e.g. if one has the data in register 9, a base address in register 3 and an index in register 4, gcc must emit code like "add 11,4,3; stwbrx 9,0,11" instead of just "stwbrx 9,4,3". This costs an extra add instruction and another register. For gcc 4.0 and older, there doesn't appear to be anything that can be done. But for 4.1 and newer, there is a 'Z' constraint. It does not allow "updating" addresses, but does allow both indexed and offset addresses. However, the only allowed constant offset is 0. We can then use the undocumented 'y' operand modifier, which causes gcc to convert "0(reg)" into the equivilient "0,reg" format that can be used with stwbrx. This brings us the to problem with the BE version. In this case, the "stw" instruction does have both indexed and non-indexed versions. The final asm ends up looking like this: asm("sync; stw%U0%X0 %1,%0" : "=m" (*addr) : "r" (val), "r" (addr)); The undocumented codes "%U0" and "%0X" will generate a 'u' if the memory reference should be an auto-updating one, and an 'x' if the memory reference is indexed, respectively. The third operand is unused, it's just there because asm the code is reused from the LE version. However, gcc does not know this, and generates unnecessary code to stick addr in a register! To use the example from the LE version, gcc will generate "add 11,4,3; stwx 9,4,3". It is able to use the indexed address "4,3" for the "stwx", but still thinks it needs to put 4+3 into register 11, which will never be used. This also ends up happening a lot for the offset addressing mode, where common code like this: out_be32(&device_registers->some_register, data); uses an instruction like "stw 9, 42(3)", where register 3 has the pointer device_registers and 42 is the offset of some_register in that structure. gcc will be forced to generate the unnecessary instruction "addi 11, 3, 42" to put the address into a single (unused) register. The in_* versions end up having these exact same problems as well. Signed-off-by: Trent Piepho <tpiepho@freescale.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-28 06:48:32 +07:00
static inline void name(volatile u##size __iomem *addr, u##size val) \
{ \
__asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \
: "=m" (*addr) : "r" (val) : "memory"); \
IO_SET_SYNC_FLAG(); \
}
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
DEF_MMIO_IN_D(in_8, 8, lbz);
DEF_MMIO_OUT_D(out_8, 8, stb);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#ifdef __BIG_ENDIAN__
DEF_MMIO_IN_D(in_be16, 16, lhz);
DEF_MMIO_IN_D(in_be32, 32, lwz);
DEF_MMIO_IN_X(in_le16, 16, lhbrx);
DEF_MMIO_IN_X(in_le32, 32, lwbrx);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
DEF_MMIO_OUT_D(out_be16, 16, sth);
DEF_MMIO_OUT_D(out_be32, 32, stw);
DEF_MMIO_OUT_X(out_le16, 16, sthbrx);
DEF_MMIO_OUT_X(out_le32, 32, stwbrx);
#else
DEF_MMIO_IN_X(in_be16, 16, lhbrx);
DEF_MMIO_IN_X(in_be32, 32, lwbrx);
DEF_MMIO_IN_D(in_le16, 16, lhz);
DEF_MMIO_IN_D(in_le32, 32, lwz);
DEF_MMIO_OUT_X(out_be16, 16, sthbrx);
DEF_MMIO_OUT_X(out_be32, 32, stwbrx);
DEF_MMIO_OUT_D(out_le16, 16, sth);
DEF_MMIO_OUT_D(out_le32, 32, stw);
#endif /* __BIG_ENDIAN */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#ifdef __powerpc64__
#ifdef __BIG_ENDIAN__
DEF_MMIO_OUT_D(out_be64, 64, std);
DEF_MMIO_IN_D(in_be64, 64, ld);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/* There is no asm instructions for 64 bits reverse loads and stores */
static inline u64 in_le64(const volatile u64 __iomem *addr)
{
return swab64(in_be64(addr));
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
}
static inline void out_le64(volatile u64 __iomem *addr, u64 val)
{
out_be64(addr, swab64(val));
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
}
#else
DEF_MMIO_OUT_D(out_le64, 64, std);
DEF_MMIO_IN_D(in_le64, 64, ld);
/* There is no asm instructions for 64 bits reverse loads and stores */
static inline u64 in_be64(const volatile u64 __iomem *addr)
{
return swab64(in_le64(addr));
}
static inline void out_be64(volatile u64 __iomem *addr, u64 val)
{
out_le64(addr, swab64(val));
}
#endif
#endif /* __powerpc64__ */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
* Low level IO stream instructions are defined out of line for now
*/
extern void _insb(const volatile u8 __iomem *addr, void *buf, long count);
extern void _outsb(volatile u8 __iomem *addr,const void *buf,long count);
extern void _insw_ns(const volatile u16 __iomem *addr, void *buf, long count);
extern void _outsw_ns(volatile u16 __iomem *addr, const void *buf, long count);
extern void _insl_ns(const volatile u32 __iomem *addr, void *buf, long count);
extern void _outsl_ns(volatile u32 __iomem *addr, const void *buf, long count);
/* The _ns naming is historical and will be removed. For now, just #define
* the non _ns equivalent names
*/
#define _insw _insw_ns
#define _insl _insl_ns
#define _outsw _outsw_ns
#define _outsl _outsl_ns
/*
* memset_io, memcpy_toio, memcpy_fromio base implementations are out of line
*/
extern void _memset_io(volatile void __iomem *addr, int c, unsigned long n);
extern void _memcpy_fromio(void *dest, const volatile void __iomem *src,
unsigned long n);
extern void _memcpy_toio(volatile void __iomem *dest, const void *src,
unsigned long n);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
*
* PCI and standard ISA accessors
*
* Those are globally defined linux accessors for devices on PCI or ISA
* busses. They follow the Linux defined semantics. The current implementation
* for PowerPC is as close as possible to the x86 version of these, and thus
* provides fairly heavy weight barriers for the non-raw versions
*
* In addition, they support a hook mechanism when CONFIG_PPC_INDIRECT_MMIO
* or CONFIG_PPC_INDIRECT_PIO are set allowing the platform to provide its
* own implementation of some or all of the accessors.
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*/
/*
* Include the EEH definitions when EEH is enabled only so they don't get
* in the way when building for 32 bits
*/
#ifdef CONFIG_EEH
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#include <asm/eeh.h>
#endif
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/* Shortcut to the MMIO argument pointer */
#define PCI_IO_ADDR volatile void __iomem *
/* Indirect IO address tokens:
*
* When CONFIG_PPC_INDIRECT_MMIO is set, the platform can provide hooks
* on all MMIOs. (Note that this is all 64 bits only for now)
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*
* To help platforms who may need to differenciate MMIO addresses in
* their hooks, a bitfield is reserved for use by the platform near the
* top of MMIO addresses (not PIO, those have to cope the hard way).
*
* This bit field is 12 bits and is at the top of the IO virtual
* addresses PCI_IO_INDIRECT_TOKEN_MASK.
*
* The kernel virtual space is thus:
*
* 0xD000000000000000 : vmalloc
* 0xD000080000000000 : PCI PHB IO space
* 0xD000080080000000 : ioremap
* 0xD0000fffffffffff : end of ioremap region
*
* Since the top 4 bits are reserved as the region ID, we use thus
* the next 12 bits and keep 4 bits available for the future if the
* virtual address space is ever to be extended.
*
* The direct IO mapping operations will then mask off those bits
* before doing the actual access, though that only happen when
* CONFIG_PPC_INDIRECT_MMIO is set, thus be careful when you use that
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* mechanism
*
* For PIO, there is a separate CONFIG_PPC_INDIRECT_PIO which makes
* all PIO functions call through a hook.
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*/
#ifdef CONFIG_PPC_INDIRECT_MMIO
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define PCI_IO_IND_TOKEN_MASK 0x0fff000000000000ul
#define PCI_IO_IND_TOKEN_SHIFT 48
#define PCI_FIX_ADDR(addr) \
((PCI_IO_ADDR)(((unsigned long)(addr)) & ~PCI_IO_IND_TOKEN_MASK))
#define PCI_GET_ADDR_TOKEN(addr) \
(((unsigned long)(addr) & PCI_IO_IND_TOKEN_MASK) >> \
PCI_IO_IND_TOKEN_SHIFT)
#define PCI_SET_ADDR_TOKEN(addr, token) \
do { \
unsigned long __a = (unsigned long)(addr); \
__a &= ~PCI_IO_IND_TOKEN_MASK; \
__a |= ((unsigned long)(token)) << PCI_IO_IND_TOKEN_SHIFT; \
(addr) = (void __iomem *)__a; \
} while(0)
#else
#define PCI_FIX_ADDR(addr) (addr)
#endif
/*
* Non ordered and non-swapping "raw" accessors
*/
static inline unsigned char __raw_readb(const volatile void __iomem *addr)
{
return *(volatile unsigned char __force *)PCI_FIX_ADDR(addr);
}
static inline unsigned short __raw_readw(const volatile void __iomem *addr)
{
return *(volatile unsigned short __force *)PCI_FIX_ADDR(addr);
}
static inline unsigned int __raw_readl(const volatile void __iomem *addr)
{
return *(volatile unsigned int __force *)PCI_FIX_ADDR(addr);
}
static inline void __raw_writeb(unsigned char v, volatile void __iomem *addr)
{
*(volatile unsigned char __force *)PCI_FIX_ADDR(addr) = v;
}
static inline void __raw_writew(unsigned short v, volatile void __iomem *addr)
{
*(volatile unsigned short __force *)PCI_FIX_ADDR(addr) = v;
}
static inline void __raw_writel(unsigned int v, volatile void __iomem *addr)
{
*(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v;
}
#ifdef __powerpc64__
static inline unsigned long __raw_readq(const volatile void __iomem *addr)
{
return *(volatile unsigned long __force *)PCI_FIX_ADDR(addr);
}
static inline void __raw_writeq(unsigned long v, volatile void __iomem *addr)
{
*(volatile unsigned long __force *)PCI_FIX_ADDR(addr) = v;
}
#endif /* __powerpc64__ */
/*
*
* PCI PIO and MMIO accessors.
*
*
* On 32 bits, PIO operations have a recovery mechanism in case they trigger
* machine checks (which they occasionally do when probing non existing
* IO ports on some platforms, like PowerMac and 8xx).
* I always found it to be of dubious reliability and I am tempted to get
* rid of it one of these days. So if you think it's important to keep it,
* please voice up asap. We never had it for 64 bits and I do not intend
* to port it over
*/
#ifdef CONFIG_PPC32
#define __do_in_asm(name, op) \
static inline unsigned int name(unsigned int port) \
{ \
unsigned int x; \
__asm__ __volatile__( \
"sync\n" \
"0:" op " %0,0,%1\n" \
"1: twi 0,%0,0\n" \
"2: isync\n" \
"3: nop\n" \
"4:\n" \
".section .fixup,\"ax\"\n" \
"5: li %0,-1\n" \
" b 4b\n" \
".previous\n" \
".section __ex_table,\"a\"\n" \
" .align 2\n" \
" .long 0b,5b\n" \
" .long 1b,5b\n" \
" .long 2b,5b\n" \
" .long 3b,5b\n" \
".previous" \
: "=&r" (x) \
: "r" (port + _IO_BASE) \
: "memory"); \
return x; \
}
#define __do_out_asm(name, op) \
static inline void name(unsigned int val, unsigned int port) \
{ \
__asm__ __volatile__( \
"sync\n" \
"0:" op " %0,0,%1\n" \
"1: sync\n" \
"2:\n" \
".section __ex_table,\"a\"\n" \
" .align 2\n" \
" .long 0b,2b\n" \
" .long 1b,2b\n" \
".previous" \
: : "r" (val), "r" (port + _IO_BASE) \
: "memory"); \
}
__do_in_asm(_rec_inb, "lbzx")
__do_in_asm(_rec_inw, "lhbrx")
__do_in_asm(_rec_inl, "lwbrx")
__do_out_asm(_rec_outb, "stbx")
__do_out_asm(_rec_outw, "sthbrx")
__do_out_asm(_rec_outl, "stwbrx")
#endif /* CONFIG_PPC32 */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/* The "__do_*" operations below provide the actual "base" implementation
* for each of the defined accessors. Some of them use the out_* functions
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* directly, some of them still use EEH, though we might change that in the
* future. Those macros below provide the necessary argument swapping and
* handling of the IO base for PIO.
*
* They are themselves used by the macros that define the actual accessors
* and can be used by the hooks if any.
*
* Note that PIO operations are always defined in terms of their corresonding
* MMIO operations. That allows platforms like iSeries who want to modify the
* behaviour of both to only hook on the MMIO version and get both. It's also
* possible to hook directly at the toplevel PIO operation if they have to
* be handled differently
*/
#define __do_writeb(val, addr) out_8(PCI_FIX_ADDR(addr), val)
#define __do_writew(val, addr) out_le16(PCI_FIX_ADDR(addr), val)
#define __do_writel(val, addr) out_le32(PCI_FIX_ADDR(addr), val)
#define __do_writeq(val, addr) out_le64(PCI_FIX_ADDR(addr), val)
#define __do_writew_be(val, addr) out_be16(PCI_FIX_ADDR(addr), val)
#define __do_writel_be(val, addr) out_be32(PCI_FIX_ADDR(addr), val)
#define __do_writeq_be(val, addr) out_be64(PCI_FIX_ADDR(addr), val)
#ifdef CONFIG_EEH
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define __do_readb(addr) eeh_readb(PCI_FIX_ADDR(addr))
#define __do_readw(addr) eeh_readw(PCI_FIX_ADDR(addr))
#define __do_readl(addr) eeh_readl(PCI_FIX_ADDR(addr))
#define __do_readq(addr) eeh_readq(PCI_FIX_ADDR(addr))
#define __do_readw_be(addr) eeh_readw_be(PCI_FIX_ADDR(addr))
#define __do_readl_be(addr) eeh_readl_be(PCI_FIX_ADDR(addr))
#define __do_readq_be(addr) eeh_readq_be(PCI_FIX_ADDR(addr))
#else /* CONFIG_EEH */
#define __do_readb(addr) in_8(PCI_FIX_ADDR(addr))
#define __do_readw(addr) in_le16(PCI_FIX_ADDR(addr))
#define __do_readl(addr) in_le32(PCI_FIX_ADDR(addr))
#define __do_readq(addr) in_le64(PCI_FIX_ADDR(addr))
#define __do_readw_be(addr) in_be16(PCI_FIX_ADDR(addr))
#define __do_readl_be(addr) in_be32(PCI_FIX_ADDR(addr))
#define __do_readq_be(addr) in_be64(PCI_FIX_ADDR(addr))
#endif /* !defined(CONFIG_EEH) */
#ifdef CONFIG_PPC32
#define __do_outb(val, port) _rec_outb(val, port)
#define __do_outw(val, port) _rec_outw(val, port)
#define __do_outl(val, port) _rec_outl(val, port)
#define __do_inb(port) _rec_inb(port)
#define __do_inw(port) _rec_inw(port)
#define __do_inl(port) _rec_inl(port)
#else /* CONFIG_PPC32 */
#define __do_outb(val, port) writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
#define __do_outw(val, port) writew(val,(PCI_IO_ADDR)_IO_BASE+port);
#define __do_outl(val, port) writel(val,(PCI_IO_ADDR)_IO_BASE+port);
#define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port);
#define __do_inw(port) readw((PCI_IO_ADDR)_IO_BASE + port);
#define __do_inl(port) readl((PCI_IO_ADDR)_IO_BASE + port);
#endif /* !CONFIG_PPC32 */
#ifdef CONFIG_EEH
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define __do_readsb(a, b, n) eeh_readsb(PCI_FIX_ADDR(a), (b), (n))
#define __do_readsw(a, b, n) eeh_readsw(PCI_FIX_ADDR(a), (b), (n))
#define __do_readsl(a, b, n) eeh_readsl(PCI_FIX_ADDR(a), (b), (n))
#else /* CONFIG_EEH */
#define __do_readsb(a, b, n) _insb(PCI_FIX_ADDR(a), (b), (n))
#define __do_readsw(a, b, n) _insw(PCI_FIX_ADDR(a), (b), (n))
#define __do_readsl(a, b, n) _insl(PCI_FIX_ADDR(a), (b), (n))
#endif /* !CONFIG_EEH */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define __do_writesb(a, b, n) _outsb(PCI_FIX_ADDR(a),(b),(n))
#define __do_writesw(a, b, n) _outsw(PCI_FIX_ADDR(a),(b),(n))
#define __do_writesl(a, b, n) _outsl(PCI_FIX_ADDR(a),(b),(n))
#define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
#define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
#define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
#define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
#define __do_outsw(p, b, n) writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
#define __do_outsl(p, b, n) writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
#define __do_memset_io(addr, c, n) \
_memset_io(PCI_FIX_ADDR(addr), c, n)
#define __do_memcpy_toio(dst, src, n) \
_memcpy_toio(PCI_FIX_ADDR(dst), src, n)
#ifdef CONFIG_EEH
#define __do_memcpy_fromio(dst, src, n) \
eeh_memcpy_fromio(dst, PCI_FIX_ADDR(src), n)
#else /* CONFIG_EEH */
#define __do_memcpy_fromio(dst, src, n) \
_memcpy_fromio(dst,PCI_FIX_ADDR(src),n)
#endif /* !CONFIG_EEH */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#ifdef CONFIG_PPC_INDIRECT_PIO
#define DEF_PCI_HOOK_pio(x) x
#else
#define DEF_PCI_HOOK_pio(x) NULL
#endif
#ifdef CONFIG_PPC_INDIRECT_MMIO
#define DEF_PCI_HOOK_mem(x) x
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#else
#define DEF_PCI_HOOK_mem(x) NULL
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#endif
/* Structure containing all the hooks */
extern struct ppc_pci_io {
#define DEF_PCI_AC_RET(name, ret, at, al, space, aa) ret (*name) at;
#define DEF_PCI_AC_NORET(name, at, al, space, aa) void (*name) at;
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#include <asm/io-defs.h>
#undef DEF_PCI_AC_RET
#undef DEF_PCI_AC_NORET
} ppc_pci_io;
/* The inline wrappers */
#define DEF_PCI_AC_RET(name, ret, at, al, space, aa) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
static inline ret name at \
{ \
if (DEF_PCI_HOOK_##space(ppc_pci_io.name) != NULL) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
return ppc_pci_io.name al; \
return __do_##name al; \
}
#define DEF_PCI_AC_NORET(name, at, al, space, aa) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
static inline void name at \
{ \
if (DEF_PCI_HOOK_##space(ppc_pci_io.name) != NULL) \
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
ppc_pci_io.name al; \
else \
__do_##name al; \
}
#include <asm/io-defs.h>
#undef DEF_PCI_AC_RET
#undef DEF_PCI_AC_NORET
/* Some drivers check for the presence of readq & writeq with
* a #ifdef, so we make them happy here.
*/
#ifdef __powerpc64__
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define readq readq
#define writeq writeq
#endif
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
* Convert a physical pointer to a virtual kernel pointer for /dev/mem
* access
*/
#define xlate_dev_mem_ptr(p) __va(p)
/*
* Convert a virtual cached pointer to an uncached pointer
*/
#define xlate_dev_kmem_ptr(p) p
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
* We don't do relaxed operations yet, at least not with this semantic
*/
#define readb_relaxed(addr) readb(addr)
#define readw_relaxed(addr) readw(addr)
#define readl_relaxed(addr) readl(addr)
#define readq_relaxed(addr) readq(addr)
#ifdef CONFIG_PPC32
#define mmiowb()
#else
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
* Enforce synchronisation of stores vs. spin_unlock
* (this does it explicitly, though our implementation of spin_unlock
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* does it implicitely too)
*/
static inline void mmiowb(void)
{
unsigned long tmp;
__asm__ __volatile__("sync; li %0,0; stb %0,%1(13)"
: "=&r" (tmp) : "i" (offsetof(struct paca_struct, io_sync))
: "memory");
}
#endif /* !CONFIG_PPC32 */
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
static inline void iosync(void)
{
__asm__ __volatile__ ("sync" : : : "memory");
}
/* Enforce in-order execution of data I/O.
* No distinction between read/write on PPC; use eieio for all three.
* Those are fairly week though. They don't provide a barrier between
* MMIO and cacheable storage nor do they provide a barrier vs. locks,
* they only provide barriers between 2 __raw MMIO operations and
* possibly break write combining.
*/
#define iobarrier_rw() eieio()
#define iobarrier_r() eieio()
#define iobarrier_w() eieio()
/*
* output pause versions need a delay at least for the
* w83c105 ide controller in a p610.
*/
#define inb_p(port) inb(port)
#define outb_p(val, port) (udelay(1), outb((val), (port)))
#define inw_p(port) inw(port)
#define outw_p(val, port) (udelay(1), outw((val), (port)))
#define inl_p(port) inl(port)
#define outl_p(val, port) (udelay(1), outl((val), (port)))
#define IO_SPACE_LIMIT ~(0UL)
/**
* ioremap - map bus memory into CPU space
* @address: bus address of the memory
* @size: size of the resource to map
*
* ioremap performs a platform specific sequence of operations to
* make bus memory CPU accessible via the readb/readw/readl/writeb/
* writew/writel functions and the other mmio helpers. The returned
* address is not guaranteed to be usable directly as a virtual
* address.
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*
* We provide a few variations of it:
*
* * ioremap is the standard one and provides non-cacheable guarded mappings
* and can be hooked by the platform via ppc_md
*
* * ioremap_prot allows to specify the page flags as an argument and can
* also be hooked by the platform via ppc_md.
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*
* * ioremap_nocache is identical to ioremap
*
* * ioremap_wc enables write combining
*
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* * iounmap undoes such a mapping and can be hooked
*
[POWERPC] Rewrite IO allocation & mapping on powerpc64 This rewrites pretty much from scratch the handling of MMIO and PIO space allocations on powerpc64. The main goals are: - Get rid of imalloc and use more common code where possible - Simplify the current mess so that PIO space is allocated and mapped in a single place for PCI bridges - Handle allocation constraints of PIO for all bridges including hot plugged ones within the 2GB space reserved for IO ports, so that devices on hotplugged busses will now work with drivers that assume IO ports fit in an int. - Cleanup and separate tracking of the ISA space in the reserved low 64K of IO space. No ISA -> Nothing mapped there. I booted a cell blade with IDE on PIO and MMIO and a dual G5 so far, that's it :-) With this patch, all allocations are done using the code in mm/vmalloc.c, though we use the low level __get_vm_area with explicit start/stop constraints in order to manage separate areas for vmalloc/vmap, ioremap, and PCI IOs. This greatly simplifies a lot of things, as you can see in the diffstat of that patch :-) A new pair of functions pcibios_map/unmap_io_space() now replace all of the previous code that used to manipulate PCI IOs space. The allocation is done at mapping time, which is now called from scan_phb's, just before the devices are probed (instead of after, which is by itself a bug fix). The only other caller is the PCI hotplug code for hot adding PCI-PCI bridges (slots). imalloc is gone, as is the "sub-allocation" thing, but I do beleive that hotplug should still work in the sense that the space allocation is always done by the PHB, but if you unmap a child bus of this PHB (which seems to be possible), then the code should properly tear down all the HPTE mappings for that area of the PHB allocated IO space. I now always reserve the first 64K of IO space for the bridge with the ISA bus on it. I have moved the code for tracking ISA in a separate file which should also make it smarter if we ever are capable of hot unplugging or re-plugging an ISA bridge. This should have a side effect on platforms like powermac where VGA IOs will no longer work. This is done on purpose though as they would have worked semi-randomly before. The idea at this point is to isolate drivers that might need to access those and fix them by providing a proper function to obtain an offset to the legacy IOs of a given bus. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-04 12:15:36 +07:00
* * __ioremap_at (and the pending __iounmap_at) are low level functions to
* create hand-made mappings for use only by the PCI code and cannot
* currently be hooked. Must be page aligned.
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
*
* * __ioremap is the low level implementation used by ioremap and
* ioremap_prot and cannot be hooked (but can be used by a hook on one
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* of the previous ones)
*
* * __ioremap_caller is the same as above but takes an explicit caller
* reference rather than using __builtin_return_address(0)
*
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* * __iounmap, is the low level implementation used by iounmap and cannot
* be hooked (but can be used by a hook on iounmap)
*
*/
extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
extern void __iomem *ioremap_prot(phys_addr_t address, unsigned long size,
unsigned long flags);
extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
#define ioremap_nocache(addr, size) ioremap((addr), (size))
extern void iounmap(volatile void __iomem *addr);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
extern void __iomem *__ioremap(phys_addr_t, unsigned long size,
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
unsigned long flags);
extern void __iomem *__ioremap_caller(phys_addr_t, unsigned long size,
unsigned long flags, void *caller);
extern void __iounmap(volatile void __iomem *addr);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
[POWERPC] Rewrite IO allocation & mapping on powerpc64 This rewrites pretty much from scratch the handling of MMIO and PIO space allocations on powerpc64. The main goals are: - Get rid of imalloc and use more common code where possible - Simplify the current mess so that PIO space is allocated and mapped in a single place for PCI bridges - Handle allocation constraints of PIO for all bridges including hot plugged ones within the 2GB space reserved for IO ports, so that devices on hotplugged busses will now work with drivers that assume IO ports fit in an int. - Cleanup and separate tracking of the ISA space in the reserved low 64K of IO space. No ISA -> Nothing mapped there. I booted a cell blade with IDE on PIO and MMIO and a dual G5 so far, that's it :-) With this patch, all allocations are done using the code in mm/vmalloc.c, though we use the low level __get_vm_area with explicit start/stop constraints in order to manage separate areas for vmalloc/vmap, ioremap, and PCI IOs. This greatly simplifies a lot of things, as you can see in the diffstat of that patch :-) A new pair of functions pcibios_map/unmap_io_space() now replace all of the previous code that used to manipulate PCI IOs space. The allocation is done at mapping time, which is now called from scan_phb's, just before the devices are probed (instead of after, which is by itself a bug fix). The only other caller is the PCI hotplug code for hot adding PCI-PCI bridges (slots). imalloc is gone, as is the "sub-allocation" thing, but I do beleive that hotplug should still work in the sense that the space allocation is always done by the PHB, but if you unmap a child bus of this PHB (which seems to be possible), then the code should properly tear down all the HPTE mappings for that area of the PHB allocated IO space. I now always reserve the first 64K of IO space for the bridge with the ISA bus on it. I have moved the code for tracking ISA in a separate file which should also make it smarter if we ever are capable of hot unplugging or re-plugging an ISA bridge. This should have a side effect on platforms like powermac where VGA IOs will no longer work. This is done on purpose though as they would have worked semi-randomly before. The idea at this point is to isolate drivers that might need to access those and fix them by providing a proper function to obtain an offset to the legacy IOs of a given bus. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-04 12:15:36 +07:00
extern void __iomem * __ioremap_at(phys_addr_t pa, void *ea,
unsigned long size, unsigned long flags);
extern void __iounmap_at(void *ea, unsigned long size);
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
/*
* When CONFIG_PPC_INDIRECT_PIO is set, we use the generic iomap implementation
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
* which needs some additional definitions here. They basically allow PIO
* space overall to be 1GB. This will work as long as we never try to use
* iomap to map MMIO below 1GB which should be fine on ppc64
*/
#define HAVE_ARCH_PIO_SIZE 1
#define PIO_OFFSET 0x00000000UL
[POWERPC] Rewrite IO allocation & mapping on powerpc64 This rewrites pretty much from scratch the handling of MMIO and PIO space allocations on powerpc64. The main goals are: - Get rid of imalloc and use more common code where possible - Simplify the current mess so that PIO space is allocated and mapped in a single place for PCI bridges - Handle allocation constraints of PIO for all bridges including hot plugged ones within the 2GB space reserved for IO ports, so that devices on hotplugged busses will now work with drivers that assume IO ports fit in an int. - Cleanup and separate tracking of the ISA space in the reserved low 64K of IO space. No ISA -> Nothing mapped there. I booted a cell blade with IDE on PIO and MMIO and a dual G5 so far, that's it :-) With this patch, all allocations are done using the code in mm/vmalloc.c, though we use the low level __get_vm_area with explicit start/stop constraints in order to manage separate areas for vmalloc/vmap, ioremap, and PCI IOs. This greatly simplifies a lot of things, as you can see in the diffstat of that patch :-) A new pair of functions pcibios_map/unmap_io_space() now replace all of the previous code that used to manipulate PCI IOs space. The allocation is done at mapping time, which is now called from scan_phb's, just before the devices are probed (instead of after, which is by itself a bug fix). The only other caller is the PCI hotplug code for hot adding PCI-PCI bridges (slots). imalloc is gone, as is the "sub-allocation" thing, but I do beleive that hotplug should still work in the sense that the space allocation is always done by the PHB, but if you unmap a child bus of this PHB (which seems to be possible), then the code should properly tear down all the HPTE mappings for that area of the PHB allocated IO space. I now always reserve the first 64K of IO space for the bridge with the ISA bus on it. I have moved the code for tracking ISA in a separate file which should also make it smarter if we ever are capable of hot unplugging or re-plugging an ISA bridge. This should have a side effect on platforms like powermac where VGA IOs will no longer work. This is done on purpose though as they would have worked semi-randomly before. The idea at this point is to isolate drivers that might need to access those and fix them by providing a proper function to obtain an offset to the legacy IOs of a given bus. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-04 12:15:36 +07:00
#define PIO_MASK (FULL_IO_SIZE - 1)
#define PIO_RESERVED (FULL_IO_SIZE)
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits This patch reworks the way iSeries hooks on PCI IO operations (both MMIO and PIO) and provides a generic way for other platforms to do so (we have need to do that for various other platforms). While reworking the IO ops, I ended up doing some spring cleaning in io.h and eeh.h which I might want to split into 2 or 3 patches (among others, eeh.h had a lot of useless stuff in it). A side effect is that EEH for PIO should work now (it used to pass IO ports down to the eeh address check functions which is bogus). Also, new are MMIO "repeat" ops, which other archs like ARM already had, and that we have too now: readsb, readsw, readsl, writesb, writesw, writesl. In the long run, I might also make EEH use the hooks instead of wrapping at the toplevel, which would make things even cleaner and relegate EEH completely in platforms/iseries, but we have to measure the performance impact there (though it's really only on MMIO reads) Since I also need to hook on ioremap, I shuffled the functions a bit there. I introduced ioremap_flags() to use by drivers who want to pass explicit flags to ioremap (and it can be hooked). The old __ioremap() is still there as a low level and cannot be hooked, thus drivers who use it should migrate unless they know they want the low level version. The patch "arch provides generic iomap missing accessors" (should be number 4 in this series) is a pre-requisite to provide full iomap API support with this patch. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 13:25:10 +07:00
#define mmio_read16be(addr) readw_be(addr)
#define mmio_read32be(addr) readl_be(addr)
#define mmio_write16be(val, addr) writew_be(val, addr)
#define mmio_write32be(val, addr) writel_be(val, addr)
#define mmio_insb(addr, dst, count) readsb(addr, dst, count)
#define mmio_insw(addr, dst, count) readsw(addr, dst, count)
#define mmio_insl(addr, dst, count) readsl(addr, dst, count)
#define mmio_outsb(addr, src, count) writesb(addr, src, count)
#define mmio_outsw(addr, src, count) writesw(addr, src, count)
#define mmio_outsl(addr, src, count) writesl(addr, src, count)
/**
* virt_to_phys - map virtual addresses to physical
* @address: address to remap
*
* The returned physical address is the physical (CPU) mapping for
* the memory address given. It is only valid to use this function on
* addresses directly mapped or allocated via kmalloc.
*
* This function does not give bus mappings for DMA transfers. In
* almost all conceivable cases a device driver should not be using
* this function
*/
static inline unsigned long virt_to_phys(volatile void * address)
{
return __pa((unsigned long)address);
}
/**
* phys_to_virt - map physical address to virtual
* @address: address to remap
*
* The returned virtual address is a current CPU mapping for
* the memory address given. It is only valid to use this function on
* addresses that have a kernel mapping
*
* This function does not handle bus mappings for DMA transfers. In
* almost all conceivable cases a device driver should not be using
* this function
*/
static inline void * phys_to_virt(unsigned long address)
{
return (void *)__va(address);
}
/*
* Change "struct page" to physical address.
*/
#define page_to_phys(page) ((phys_addr_t)page_to_pfn(page) << PAGE_SHIFT)
/*
* 32 bits still uses virt_to_bus() for it's implementation of DMA
* mappings se we have to keep it defined here. We also have some old
* drivers (shame shame shame) that use bus_to_virt() and haven't been
* fixed yet so I need to define it here.
*/
#ifdef CONFIG_PPC32
static inline unsigned long virt_to_bus(volatile void * address)
{
if (address == NULL)
return 0;
return __pa(address) + PCI_DRAM_OFFSET;
}
static inline void * bus_to_virt(unsigned long address)
{
if (address == 0)
return NULL;
return __va(address - PCI_DRAM_OFFSET);
}
#define page_to_bus(page) (page_to_phys(page) + PCI_DRAM_OFFSET)
#endif /* CONFIG_PPC32 */
/* access ports */
#define setbits32(_addr, _v) out_be32((_addr), in_be32(_addr) | (_v))
#define clrbits32(_addr, _v) out_be32((_addr), in_be32(_addr) & ~(_v))
#define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) | (_v))
#define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
#define setbits8(_addr, _v) out_8((_addr), in_8(_addr) | (_v))
#define clrbits8(_addr, _v) out_8((_addr), in_8(_addr) & ~(_v))
/* Clear and set bits in one shot. These macros can be used to clear and
* set multiple bits in a register using a single read-modify-write. These
* macros can also be used to set a multiple-bit bit pattern using a mask,
* by specifying the mask in the 'clear' parameter and the new bit pattern
* in the 'set' parameter.
*/
#define clrsetbits(type, addr, clear, set) \
out_##type((addr), (in_##type(addr) & ~(clear)) | (set))
#ifdef __powerpc64__
#define clrsetbits_be64(addr, clear, set) clrsetbits(be64, addr, clear, set)
#define clrsetbits_le64(addr, clear, set) clrsetbits(le64, addr, clear, set)
#endif
#define clrsetbits_be32(addr, clear, set) clrsetbits(be32, addr, clear, set)
#define clrsetbits_le32(addr, clear, set) clrsetbits(le32, addr, clear, set)
#define clrsetbits_be16(addr, clear, set) clrsetbits(be16, addr, clear, set)
#define clrsetbits_le16(addr, clear, set) clrsetbits(le16, addr, clear, set)
#define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset,
size_t size, unsigned long flags);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */