[RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
Kumar Gala
galak at kernel.crashing.org
Fri Aug 8 10:04:04 EST 2008
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
More information about the Linuxppc-dev
mailing list