> It seems like i82365.c implies a PCI device. If this is true, then things do > make sense here. No, the VG469 (and original i82365) is most definately an ISA device. From the manual: "The VG-469 has built in a standard ISA interface ..." My machine, as much as I hate it, _does_ have an ISA bus located at isa_slot_offset. > It has nothing to isa_slot_offset here. I don't know about the > history of isa_slot_offset, but it appears to be faint effort to > allow the access to what is called "ISA memory" space on PC. This > region, if it ever exists, should never be a separate region on a > MIPS machine. It should just be the beginning part of PCI Memory The complete memory map of my machine is: 1FC0 0000 - 1FFF FFFF Boot ROM 1E00 0000 - 1EFF FFFF Flash Mem Space 1400 0000 - 14FF FFFF VG-469 I/O Space 1000 0000 - 10FF FFFF VG-469 Mem 0C00 0000 - 0CFF FFFF Processor internal IO Area 1 0A00 0000 - 0A1F FFFF LCD Frame buffer 0A20 0000 - 0A3F FFFF S-MOS Registers 0000 0000 - 01FF FFFF DRAM Space As I see it, the VG-469 Mem (ie. an ISA bus, since the VG-469 is ISA) is a separate region. > Ralf, we should just delete isa_slot_offset to avoid any further confusions. But my PCMCIA contoller _is_ an ISA device, and we need _something_ to indicate where its "ISA memory" is physically mapped. If it's not stuck into a variable, then it's just going to be hard-coded with an #ifdef for each architecture that does this .. ?? > My understanding is that PCMCIA does it own IRQ re-mapping (somewhat similar > to P2P bridge IRQ re-mapping). It's a driver issue. Again, the i82365 is on an ISA bus, and so has physical interrupt pins IRQ3-15, and uses these values in its configuration and status registers. The driver expected that these matched system interrupts, as they usually would on an ISA architecture; but that of course is not the case, as they're all wired to the same GPIO pin on my system. I've fixed this in the driver. -jim
