On Wed, 2005-06-29 at 14:19 -0300, Marcelo Tosatti wrote: > Once the physical->virtual mapping for device IO space are set > with io_block_mapping() (or with ioremap() for dynamic virtual > addresses), why would you want to ioremap() the physical address > again??? > > PS: I've had a quick try at converting the IMMAP to use > ioremap instead (and have that dynamic virtual address stored > in a pointer), changed drivers to use that pointer instead of > hardcoded "IMMAP". Didnt work immediately :) Its not that the > idea?
No, you are missing the point. The idea is: - Everything should use ioremap(), that is the proper interface for a driver or whatever else to get a virtual address for a physical area. - The architecture may use io_block_mapping() to create large fixed mappings (BATs, CAMs, 8M TLBs, ...) for some physical areas as an optimisation. Those should be transparent to later code, that is you shouldn't have to care about their existence when you are driver. You just call ioremap. If that space was already part of a large fixed mapping, then ioremap will just return an address within that range. - The debate between Dan and me here is about the semantics of io_block_mapping(). Currently, it takes both the physical and virtual address. Thus you hard-code your mappings at known virtual addresses. I find this unnecessary and source of problems, and I want to add to io_block_mapping() a way to "allocate" virtual addresses dynamically (by simply moving down ioremap_bot like ioremap would do if called that early). That way, there is no "magic" hard coded virtual addresses at all anymore. Ben.
