2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Implement the default iomap interfaces
|
|
|
|
*
|
|
|
|
* (C) Copyright 2004 Linus Torvalds
|
|
|
|
*/
|
|
|
|
#include <linux/pci.h>
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 00:00:26 -07:00
|
|
|
#include <linux/io.h>
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/module.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read/write from/to an (offsettable) iomem cookie. It might be a PIO
|
|
|
|
* access or a MMIO access, these functions don't care. The info is
|
|
|
|
* encoded in the hardware mapping set up by the mapping functions
|
|
|
|
* (or the cookie itself, depending on implementation and hw).
|
|
|
|
*
|
|
|
|
* The generic routines don't assume any hardware mappings, and just
|
|
|
|
* encode the PIO/MMIO as part of the cookie. They coldly assume that
|
|
|
|
* the MMIO IO mappings are not in the low address range.
|
|
|
|
*
|
|
|
|
* Architectures for which this is not true can't use this generic
|
|
|
|
* implementation and should do their own copy.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef HAVE_ARCH_PIO_SIZE
|
|
|
|
/*
|
|
|
|
* We encode the physical PIO addresses (0-0xffff) into the
|
|
|
|
* pointer by offsetting them with a constant (0x10000) and
|
|
|
|
* assuming that all the low addresses are always PIO. That means
|
|
|
|
* we can do some sanity checks on the low bits, and don't
|
|
|
|
* need to just take things for granted.
|
|
|
|
*/
|
|
|
|
#define PIO_OFFSET 0x10000UL
|
|
|
|
#define PIO_MASK 0x0ffffUL
|
|
|
|
#define PIO_RESERVED 0x40000UL
|
|
|
|
#endif
|
|
|
|
|
2007-05-04 21:44:23 -06:00
|
|
|
static void bad_io_access(unsigned long port, const char *access)
|
|
|
|
{
|
|
|
|
static int count = 10;
|
|
|
|
if (count) {
|
|
|
|
count--;
|
2007-10-17 00:29:51 -06:00
|
|
|
printk(KERN_ERR "Bad IO access at port %#lx (%s)\n", port, access);
|
2007-05-04 21:44:23 -06:00
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* Ugly macros are a way of life.
|
|
|
|
*/
|
|
|
|
#define IO_COND(addr, is_pio, is_mmio) do { \
|
|
|
|
unsigned long port = (unsigned long __force)addr; \
|
2007-05-04 21:44:23 -06:00
|
|
|
if (port >= PIO_RESERVED) { \
|
|
|
|
is_mmio; \
|
|
|
|
} else if (port > PIO_OFFSET) { \
|
2005-04-16 16:20:36 -06:00
|
|
|
port &= PIO_MASK; \
|
|
|
|
is_pio; \
|
2007-05-04 21:44:23 -06:00
|
|
|
} else \
|
|
|
|
bad_io_access(port, #is_pio ); \
|
2005-04-16 16:20:36 -06:00
|
|
|
} while (0)
|
|
|
|
|
2006-11-10 23:24:46 -07:00
|
|
|
#ifndef pio_read16be
|
|
|
|
#define pio_read16be(port) swab16(inw(port))
|
|
|
|
#define pio_read32be(port) swab32(inl(port))
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef mmio_read16be
|
|
|
|
#define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
|
|
|
|
#define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
|
|
|
|
#endif
|
|
|
|
|
2008-02-08 05:19:55 -07:00
|
|
|
unsigned int ioread8(void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, return inb(port), return readb(addr));
|
2007-05-04 21:44:23 -06:00
|
|
|
return 0xff;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
unsigned int ioread16(void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, return inw(port), return readw(addr));
|
2007-05-04 21:44:23 -06:00
|
|
|
return 0xffff;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
unsigned int ioread16be(void __iomem *addr)
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
{
|
2006-11-10 23:24:46 -07:00
|
|
|
IO_COND(addr, return pio_read16be(port), return mmio_read16be(addr));
|
2007-05-04 21:44:23 -06:00
|
|
|
return 0xffff;
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
unsigned int ioread32(void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, return inl(port), return readl(addr));
|
2007-05-04 21:44:23 -06:00
|
|
|
return 0xffffffff;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
unsigned int ioread32be(void __iomem *addr)
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
{
|
2006-11-10 23:24:46 -07:00
|
|
|
IO_COND(addr, return pio_read32be(port), return mmio_read32be(addr));
|
2007-05-04 21:44:23 -06:00
|
|
|
return 0xffffffff;
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(ioread8);
|
|
|
|
EXPORT_SYMBOL(ioread16);
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
EXPORT_SYMBOL(ioread16be);
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(ioread32);
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
EXPORT_SYMBOL(ioread32be);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-11-10 23:24:46 -07:00
|
|
|
#ifndef pio_write16be
|
|
|
|
#define pio_write16be(val,port) outw(swab16(val),port)
|
|
|
|
#define pio_write32be(val,port) outl(swab32(val),port)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef mmio_write16be
|
|
|
|
#define mmio_write16be(val,port) __raw_writew(be16_to_cpu(val),port)
|
|
|
|
#define mmio_write32be(val,port) __raw_writel(be32_to_cpu(val),port)
|
|
|
|
#endif
|
|
|
|
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite8(u8 val, void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outb(val,port), writeb(val, addr));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite16(u16 val, void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outw(val,port), writew(val, addr));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite16be(u16 val, void __iomem *addr)
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
{
|
2006-11-10 23:24:46 -07:00
|
|
|
IO_COND(addr, pio_write16be(val,port), mmio_write16be(val, addr));
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite32(u32 val, void __iomem *addr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outl(val,port), writel(val, addr));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite32be(u32 val, void __iomem *addr)
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
{
|
2006-11-10 23:24:46 -07:00
|
|
|
IO_COND(addr, pio_write32be(val,port), mmio_write32be(val, addr));
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(iowrite8);
|
|
|
|
EXPORT_SYMBOL(iowrite16);
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
EXPORT_SYMBOL(iowrite16be);
|
2005-04-16 16:20:36 -06:00
|
|
|
EXPORT_SYMBOL(iowrite32);
|
[PATCH] add Big Endian variants of ioread/iowrite
In the new io infrastructure, all of our operators are expecting the
underlying device to be little endian (because the PCI bus, their main
consumer, is LE).
However, there are a fair few devices and busses in the world that are
actually Big Endian. There's even evidence that some of these BE bus and
chip types are attached to LE systems. Thus, there's a need for a BE
equivalent of our io{read,write}{16,32} operations.
The attached patch adds this as io{read,write}{16,32}be. When it's in,
I'll add the first consume (the 53c700 SCSI chip driver).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 16:25:54 -06:00
|
|
|
EXPORT_SYMBOL(iowrite32be);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These are the "repeat MMIO read/write" functions.
|
|
|
|
* Note the "__raw" accesses, since we don't want to
|
|
|
|
* convert to CPU byte order. We write in "IO byte
|
|
|
|
* order" (we also don't have IO barriers).
|
|
|
|
*/
|
2006-11-10 23:24:46 -07:00
|
|
|
#ifndef mmio_insb
|
2005-04-16 16:20:36 -06:00
|
|
|
static inline void mmio_insb(void __iomem *addr, u8 *dst, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
u8 data = __raw_readb(addr);
|
|
|
|
*dst = data;
|
|
|
|
dst++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static inline void mmio_insw(void __iomem *addr, u16 *dst, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
u16 data = __raw_readw(addr);
|
|
|
|
*dst = data;
|
|
|
|
dst++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static inline void mmio_insl(void __iomem *addr, u32 *dst, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
u32 data = __raw_readl(addr);
|
|
|
|
*dst = data;
|
|
|
|
dst++;
|
|
|
|
}
|
|
|
|
}
|
2006-11-10 23:24:46 -07:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-11-10 23:24:46 -07:00
|
|
|
#ifndef mmio_outsb
|
2005-04-16 16:20:36 -06:00
|
|
|
static inline void mmio_outsb(void __iomem *addr, const u8 *src, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
__raw_writeb(*src, addr);
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static inline void mmio_outsw(void __iomem *addr, const u16 *src, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
__raw_writew(*src, addr);
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
static inline void mmio_outsl(void __iomem *addr, const u32 *src, int count)
|
|
|
|
{
|
|
|
|
while (--count >= 0) {
|
|
|
|
__raw_writel(*src, addr);
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
}
|
2006-11-10 23:24:46 -07:00
|
|
|
#endif
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-02-08 05:19:55 -07:00
|
|
|
void ioread8_rep(void __iomem *addr, void *dst, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, insb(port,dst,count), mmio_insb(addr, dst, count));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void ioread16_rep(void __iomem *addr, void *dst, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, insw(port,dst,count), mmio_insw(addr, dst, count));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void ioread32_rep(void __iomem *addr, void *dst, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, insl(port,dst,count), mmio_insl(addr, dst, count));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ioread8_rep);
|
|
|
|
EXPORT_SYMBOL(ioread16_rep);
|
|
|
|
EXPORT_SYMBOL(ioread32_rep);
|
|
|
|
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite8_rep(void __iomem *addr, const void *src, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outsb(port, src, count), mmio_outsb(addr, src, count));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite16_rep(void __iomem *addr, const void *src, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outsw(port, src, count), mmio_outsw(addr, src, count));
|
|
|
|
}
|
2008-02-08 05:19:55 -07:00
|
|
|
void iowrite32_rep(void __iomem *addr, const void *src, unsigned long count)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
IO_COND(addr, outsl(port, src,count), mmio_outsl(addr, src, count));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(iowrite8_rep);
|
|
|
|
EXPORT_SYMBOL(iowrite16_rep);
|
|
|
|
EXPORT_SYMBOL(iowrite32_rep);
|
|
|
|
|
|
|
|
/* Create a virtual mapping cookie for an IO port range */
|
|
|
|
void __iomem *ioport_map(unsigned long port, unsigned int nr)
|
|
|
|
{
|
|
|
|
if (port > PIO_MASK)
|
|
|
|
return NULL;
|
|
|
|
return (void __iomem *) (unsigned long) (port + PIO_OFFSET);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ioport_unmap(void __iomem *addr)
|
|
|
|
{
|
|
|
|
/* Nothing to do */
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(ioport_map);
|
|
|
|
EXPORT_SYMBOL(ioport_unmap);
|
|
|
|
|
2007-07-19 18:48:44 -06:00
|
|
|
/**
|
|
|
|
* pci_iomap - create a virtual mapping cookie for a PCI BAR
|
|
|
|
* @dev: PCI device that owns the BAR
|
|
|
|
* @bar: BAR number
|
|
|
|
* @maxlen: length of the memory to map
|
|
|
|
*
|
|
|
|
* Using this function you will get a __iomem address to your device BAR.
|
|
|
|
* You can access it using ioread*() and iowrite*(). These functions hide
|
|
|
|
* the details if this is a MMIO or PIO address space and will just do what
|
|
|
|
* you expect from them in the correct way.
|
|
|
|
*
|
|
|
|
* @maxlen specifies the maximum length to map. If you want to get access to
|
|
|
|
* the complete BAR without checking for its length first, pass %0 here.
|
|
|
|
* */
|
2005-04-16 16:20:36 -06:00
|
|
|
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
|
|
|
|
{
|
|
|
|
unsigned long start = pci_resource_start(dev, bar);
|
|
|
|
unsigned long len = pci_resource_len(dev, bar);
|
|
|
|
unsigned long flags = pci_resource_flags(dev, bar);
|
|
|
|
|
|
|
|
if (!len || !start)
|
|
|
|
return NULL;
|
|
|
|
if (maxlen && len > maxlen)
|
|
|
|
len = maxlen;
|
|
|
|
if (flags & IORESOURCE_IO)
|
|
|
|
return ioport_map(start, len);
|
|
|
|
if (flags & IORESOURCE_MEM) {
|
|
|
|
if (flags & IORESOURCE_CACHEABLE)
|
|
|
|
return ioremap(start, len);
|
|
|
|
return ioremap_nocache(start, len);
|
|
|
|
}
|
|
|
|
/* What? */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
|
|
|
|
{
|
|
|
|
IO_COND(addr, /* nothing */, iounmap(addr));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pci_iomap);
|
|
|
|
EXPORT_SYMBOL(pci_iounmap);
|