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

Nicolas Pitre
2010-08-06T17:07:46Z

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@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