RFC: Deprecating io_block_mapping

Dan Malek dan at embeddededge.com
Wed May 25 15:00:10 EST 2005


On May 24, 2005, at 10:30 PM, Kumar Gala wrote:

> I know what I've done in the past is either steal a BAT (83xx) or CAM 
> (85xx) entry and then free it up when a proper ioremap can be done 
> later.

This is even more of a hack than io_block_mapping() because it is often
obscure and not documented.  Several boards have done this in the past
as well.  It's "magic" that occurs, what seems to be minor code changes
often cause this to break and makes debugging more complex :-)

> No, as far as a can tell doing a quick glance if we drop 
> io_block_mapping than we can drop setup_io_mappings().

We've got to have something to address the board unique requirements
that are currently satisfied by this.

There is a real problem that we have to solve.  Some boards just need
access to mapped hardware before the VM is set up.  You can't just
remove a feature or tell them their design is wrong.  I don't think 
obscure
mapping tricks are the solution, either.

The only solution is to make ioremap() smart enough to properly use
BATs and CAMs that are available to a processor.   I suspect this is 
going
to lead to a bunch of also undesirable configuration options to address
the customizations necessary.

Thanks.


	-- Dan




More information about the Linuxppc-embedded mailing list