On Aug 7, 2008, at 5:13 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-08-06 at 20:49 -0500, Kumar Gala wrote:
On Aug 6, 2008, at 5:28 PM, Benjamin Herrenschmidt wrote:
there is a bunch of error checking and difference in semantics that
you need to fix. I think introduce a new API for this is silly,
especially since we expect there to only be one actual invocation
of
the API for serial console access.
Not necessarily....
There's another aspect to BAT mappings here. First, they should be
permanent (ie, not unmappable). That way, we have ioremap just use
an existing BAT mapping when asked for a device that is covered
by a BAT. This allows to have platform code do something like setup
a BAT over a bunch of SOC registers or over a device, to
automagically
get drivers doing ioremap to that area benefit from it.
why should they be permanent.. We could implement reference counting
around the regions and free BATs if the count = 0.
Do we care ?
probably not for BATs but for other things we might.
I'm more concerned about this being implemented around the existing
ioremap core in __ioremap(). We can easily use a flag bit to say use
"large mappings" or the fact that mem_init_done == 0.
mem_init_done isn't a good indication. We can do page tables when it's
0, we would have to use a separate mem_preinit_done or something :-)
I initially also though about a flag to ioremap_prot to be honest. But
it does obfuscate the normal ioremap code path and if there's a flag,
that means that callers know the difference and thus may as well call
a separate function, don't you think ?
I'm ok with exposing a separate function as far as the API goes.. I'm
not ok with duplicating the logic of __ioremap().
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
