From mboxrd@z Thu Jan 1 00:00:00 1970 From: nico@fluxnic.net (Nicolas Pitre) Date: Fri, 06 Aug 2010 13:07:46 -0400 (EDT) Subject: [PATCH] [ARM] Introduce patching of phys_to_virt and vice versa In-Reply-To: <20100805094521.GB23473@n2100.arm.linux.org.uk> References: <1277542025-19881-1-git-send-email-eric.miao@canonical.com> <1278083164.15298.55.camel@ra7055-laptop> <20100720211629.GB10553@n2100.arm.linux.org.uk> <20100805094521.GB23473@n2100.arm.linux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > > 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