[PATCH] [ARM] Introduce patching of phys_to_virt and vice versa

[Nicolas Pitre]

On Thu, 5 Aug 2010, Russell King - ARM Linux wrote:

> On Thu, Aug 05, 2010 at 04:45:25PM +0800, Eric Miao wrote:
> > On Wed, Jul 21, 2010 at 5:16 AM, Russell King - ARM Linux
> > <linux at arm.linux.org.uk> wrote:
> > > On Fri, Jul 02, 2010 at 10:06:04AM -0500, Rob Herring wrote:
> > >> Should something more generic like the x86 alternative code be done for
> > >> ARM? It's very likely we will need patching in other places like for UP
> > >> and SMP in one kernel.
> > >
> > > I think yes, we need to - I can't see how we can sensibly combine
> > > kernels without this.
> > >
> > > However, the effect of this is that XIP can't use this - as the
> > > kernel text is read-only.
> > >
> > 
> > Hi Russell,
> > 
> > Sorry for late update on this. I've addressed your comments as below,
> > and really hope this can get into this merge window, so I'm also sending
> > this to your patch system right now ;-)
> 
> How does this affect the compiler's instruction scheduling w.r.t. previous
> load instructions?

No idea.  That depends how gcc is considering inline asm.  Given there 
is one input operand, I suppose gcc would account for the delay slot 
before that operand is actually available.  The inline asm itself is an 
ALU instruction but there is no way to indicate that fact to gcc, and 
whether or not it uses the output operand right away won't matter in 
this case.  So all that could be missing is for gcc to schedule this ALU 
instruction into a possible delay slot for another ldr instruction or 
the like.

In any case, this can only be an improvement over the alternative which 
is to have PHYS_OFFSET in a global variable.


Nicolas