This is a major source of frustration on our particular board design. We
actually have a real memory-mapped ISA (PC104) bus, but few Linux ISA
device drivers will work because in*() macros seems have already been
overloaded to point to AHB/APB space. What we do to cope is map our ISA
bus spaces in kernel virtual memory and use a high address such as
inb(0x8dc003f8) in drivers. Our ISA bus is mapped physically between
0x10000000 and 0x20000000, so this 0x8dc00000 is really an arbitrary
number that eventually gets massaged by IO_ADDRESS() to hit the right
spot.
Of course, a lot of ISA drivers won't work anyway because they manipulate
IO addresses as "signed int" for which a 0x8xxx_xxxx addr is somewhat bad.
They also make assumptions about IRQ numbering that don't apply on ARM
(e.g. IRQ2 == IRQ9), but thats another problem altogether. Preferably,
in*() and out*() would be reserved for the ISA IO bus space and another
mechanism would be used for accessing internal SoC peripheral space.
Also, it would be nice if request_irq() could be reserved for x86 style
IRQ's and something like ep93xx_request_irq() could be used for the real
VIC irqs.
Maybe this is already present, I personally haven't looked a lot at the
new 2.6 stuff yet.
//Jesse Off //Technologic Systems, http://www.embeddedARM.com
I don't like the IO_ADDRESS() thing, but I can live with it :)
better ideas?Dropping it ;) More seriously, I think replacing inl(addr) with readl(IO_ADDRESS(addr)) reduces the code readability. If we had EP93XX_AHB_BASE defined as IO_BASE_VIRT, we could get rid of this IO_ADDRESS macro.