linux-mips
[Top] [All Lists]

Re: [PATCH] Inline ioremap() magic for 32-bit constant addresses

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] Inline ioremap() magic for 32-bit constant addresses
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 29 Jun 2005 18:07:26 +0100 (BST)
Cc: linux-mips@linux-mips.org
In-reply-to: <20050629131437.GE3211@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.61L.0506281713050.13758@blysk.ds.pg.gda.pl> <20050629131437.GE3211@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 29 Jun 2005, Ralf Baechle wrote:

> >  I'd like to get rid of CKSEG1ADDR() wherever possible from code I am 
> > looking after as the macro is unportable and has already proven to cause 
> > maintenance hassle.  I don't want to get rid of its advantages though, so 
> > here's an update for ioremap() that makes it be expanded inline when 
> > constant arguments are used and the resulting mapping fits in KSEG1.  
> > Likewise for iounmap().
> 
> I don't think I'd complain about taking the whole thing out off line.  Last
> I checked we had no driver that did substancially benefit from being
> initialized a few nanoseconds faster.

 I haven't checked it yet, but it may be possible for my updates to add 
calls to ioremap() from interrupt handlers, which may not necessarily be 
so neutral to performance if calculations are done out of line.  With this 
inline implementation ioremap() expands to at most two instructions for 
qualifying calls and iounmap() expands to nothing.  With an out of line 
version not only the address calculations are done at the run time, but 
you need to add an overhead of two function calls.

 I like the MIPS64 version best, though. ;-)

> >  Apparently the generic version is used for all platforms but the Au1000.  
> > I have only implemented the bare minimum required for the platform to keep 
> > working.  The platform seems to be maintained though, so I'm leaving the 
> > decision as to whether to inline the platform-specific variation or not up 
> > to the maintainer.
> 
> So I guess your patch leaves getting rid of that indirection of
> fixup_bigphys_addr calling into __fixup_bigphys_addr to Pete :-)

 Yes, formally.  Technically, I can probably get convinced to do the dirty 
cut & paste work if asked to appropriately. ;-)

  Maciej

<Prev in Thread] Current Thread [Next in Thread>