Messages in this thread |  | | From | Arnd Bergmann <> | Subject | Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be) | Date | Wed, 6 Feb 2013 16:18:07 +0000 |
| |
On Wednesday 06 February 2013, Geert Uytterhoeven wrote: > On Wed, Feb 6, 2013 at 12:03 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Tuesday 05 February 2013, Michal Simek wrote: > >> I want to be sure about this. I have parsed this again with closer look and > >> seems to me that ioread32 is equal to readl and iowrite32 to writel. > >> Arnd: Am I right? > > > > Correct. On all the architectures you care about (most importantly, not > > x86), readl and ioread32 are defined to have the same semantics. There > > are a few exceptions where ioread32 provides a wrapper for PCI > > PIO accesses that are not memory mapped, making ioread32 slightly > > slower than readl, but for all practical purposes you don't have > > to worry about it ;-) > > PCI PIO? Do you mean "PCI I/O space"?
Yes.
> That's different, and accessed through inb() and friends, right?
Sort of. The native methods are readl() etc for MMIO and inb() etc. for PIO, as you say. However, the ioread32() family does the superset of the two, either using a wrapper function with a mangled port number / pointer argument (e.g. on x86), or it gets defined to do the same as readl on platforms where the PCI I/O space is memory mapped. The requirement here is that whatever the result of ioport_map() is must be turned back into a PIO access when passed into ioread32(). On memory mapped platforms, there is typically just an offset that gets added to the port number to turn that into an __iomem pointer.
Arnd
|  |