Hi David,
Hi Michael, may be I've found something
It appears you have!
Must be something rather obvious but I can't figure it out. Maybe it's time to stop fudging with the isa_rom_* macros and bang the ROM port directly until we know how to read the chip ID.See the code below from isp116x.h, I've added some traces in function isp116x_write_addr(): static inline void isp116x_write_addr(struct isp116x *isp116x, unsigned reg) { IRQ_TEST(); isp_writew(reg & 0xff, isp116x->addr_reg); if (((int)isp116x->addr_reg & 0x00000FFFUL) == 0x360) printk("addr_reg: 0x%08lx __pa(addr_reg): 0x%08lx\n",isp116x->addr_reg, __pa(isp116x->addr_reg)); // isp116x_delay(isp116x, 300); } This is what I'm getting for those two values: addr_reg: 0xd0400360 __pa(addr_reg): 0xd0400360 addr_reg: 0xd0400360 __pa(addr_reg): 0xd0400360 addr_reg: 0xd0400360 __pa(addr_reg): 0xd0400360
Bugger - the __pa() does not appear to work as expected.
So if I'm not overlooking anything, __pa(p)<1024 is FALSE and the isa routines aren't taken. What do you think?
You're absolutely right - is the 0xd0400360 address the same as reported by the prinkt() statements frop isp116x_probe() ?? I think there are some that report what address the data register is at. You probably also still have that error messafe about a resource being freed that wasn't registered - does that match the same address? Geert et al. - what's the correct way to find out what physical address corresponds to a ioremapped virtual one? addr_reg is the ioremapped 'IO port address' 0x360 that I need to pass to the isa_rom macros in order to get the ROM port access right. Seems I've tangled myself up in too many indirections here. David - just mask off the address with 0xFFFUL if the test returns true to force the correct address on the accessors - that way we can get on with testing at least. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
