On Tue, Apr 8, 2014 at 4:11 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > There is a wide range of implementations across architectures: > > a) no access to I/O ports at all (tile, s390, ...) > b) access to I/O ports only through special instructions (x86, ...) > c) all MMIO is mapped virtual contiguous to PCI_IOBASE or _IO_BASE > (most ppc64, arm32 with MMU, arm64, ...) > d) only one PCI host can have an I/O space (mips, microblaze, ...) > e) each host controller can have its own method (ppc64 with indirect pio) > f) PIO token equals virtual address plus offset (some legacy ARM platforms, > probably some other architectures), or physical address (sparc) > g) PIO token encodes address space number plus offset (ia64) > > a) and b) are trivially handled by any implementation that falls > back to 'return -EINVAL'. > I believe that c) is the most appropriate solution and we should be > able to adopt it by most of the architectures that have an MMU and > make it the default implementation. > d) seems like a good fallback for noMMU architectures: While we do > need to support I/O spaces, we need to support multiple PCI domains, > and we need to support noMMU, the combination of all three should > be extremely rare, and I'd leave it up to the architecture to support > that if there is a real use case, rather than trying to put that into > common code. > Anything that currently requires e), f) or g) I think should keep > doing that and not try to use the generic implementation. Thanks for the nice summary. That's way more than I had figured out myself. I don't know whether it'd be worth it, especially for something that's so close to obsolete, but it seems like it should be *possible* to generalize and unify this somewhat. I would argue that g) (which I wrote, so I know it better than the others) could fairly easily subsume c), d), and f), since it maps an ioport number to a virtual address for an MMIO access, but it doesn't assume that all the MMIO spaces are contiguous. b), e), and maybe a) could be handled with an exception, e.g., inside inb(), look up the struct io_space (e.g., similar to what ia64 does in __ia64_mk_io_addr()), and if that struct contains a non-zero ops pointer, use that instead of doing the MMIO access. The ops pointer functions could use the x86 INB instruction or do the indirect PIO thing or whatever. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
