In our build, (currently based on 2.6.14.3) we define IMAP_ADDR as follows:
#define IMAP_ADDR (((bd_t *)__res)->bi_immr_base) With very few exceptions, nearly all driver code that dereferences IMAP_ADDR can be used unchanged and the IMMR value is always the value passed up from the bootloader. We build one image that runs on multiple platforms and some platforms place the IMMR address space at different addresses than others. It's not a constant. Regardless, I see little reason to ioremap() the IMMR address. The MMU is set up in such a way that IMMR based locations can be accessed directly. Ken Poole, MRV Communications, Inc. > In a related vein, as I alluded to in my previous email, there has been > previous discussion on this list about the fact that it is frowned upon > for device drivers to directly dereference IMAP_ADDR. Instead, I've > seen a recommendation that each individual driver perform an io_remap() > operation on IMAP_ADDR and save the resulting kernel virtual address in > a driver-specific data structure. Is this a universally-accepted > viewpoint? Is this something that the community agrees "should be > fixed" and we're just waiting for someone (like me) to volunteer to fix > all the drivers? > Or are there arguments in favor of keeping the direct IMAP_ADDR > dereferences? For example, if each driver performs its own separate > io_remap(), doesn't that have potentially negative consequences on the > VM system for some PPC implementations (e.g. increased contention for > TLB entries)? > Are these issues addressed by or otherwise impacted by other ongoing PPC > Linux work such as the "ppc" + "ppc64" --> "powerpc" effort / "flat > device tree" stuff??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060509/86fca084/attachment.htm
