David,
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.
Just realized - might this be about the first page not being mapped on m68k?
That's where the 0x3X0 addresses would go (if it wasn't for the ROM port
special case).
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.
Checked my boot log and it isn't - it properly reports 0x360/0x340 there.
You probably also still have that error messafe about a resource being freed
that wasn't registered - does that match the same address?
Different story - that's the CPLD, and I've found and corrected that one.
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.
What's the expected behavior if I call __pa() on something that is not
actually mapped?
Cheers,
Michael
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
--
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
