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

On Thu, Aug 05, 2010 at 04:45:25PM +0800, Eric Miao wrote:

quoted

On Wed, Jul 21, 2010 at 5:16 AM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Fri, Jul 02, 2010 at 10:06:04AM -0500, Rob Herring wrote:

quoted

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