On Thu, 27 Jul 2023, Michael Schmitz wrote:
I can't figure out why those platforms don't suffer from the same
"double translation" problem that William described on q40.
There are only two other address translation schemes in effect - Amiga
Gayle, which handles byte/word address offsets, and gets passed IO
addresses (in the sense that these are the addresses where registers are
mapped in memory), and Atari EtherNEC, which handles IO ports (from the
ne.c legacy ISA driver).
The Gayle address translation, taking MMIO addresses does not add an IO
base address. The EtherNEC address translation, OTOH, takes IO ports and
must add the ROM port base address as IO base.
What I did not realize at the time I rewrote the Q40 driver as platform
driver is that the old driver used IO ports, not MMIO addresses. In
order to reserve the IDE register area (we don't have a MMIO area
corresponding to the IO ports range mapped on m68k), I did add the Q40
ISA base address to the IO port range to populate the platform memory
resources, forgetting that the same base address is then added a second
time through the IO address translation.
[...]
A correct fix would keep the current IO translation intact, and instead
use the platform mem resource to register the driver IO range, and the
platform IO resource as base offset to populate the port ioaddr struct
(minus the register scaling and byte offset, mind you).
I'll give this some more thought ASAP.
I wonder whether Will's suggestion (CONFIG_HAS_IOPORT_MAP) is feasible in
light of the needs of Gayle and EtherNEC drivers.
And yes, I'm painfully aware the m68k low level IO code is becoming a
bit of a maintainance legacy, in no small part due to my hacks around
Atari EtherNEC.
I guess you and I both can share the blame for 44b1fbc0f5f30e66...
Anyway, you make a good point about on-going maintenance. Do you think
that by supporting standard ISA drivers we might actually reduce the
ideosyncracies in m68k IO code?
