On Tue, Jan 04 2011, Nicolas Pitre wrote:
On Tue, 4 Jan 2011, David Brown wrote:
quoted
Any idea how much it would hurt other targets to have the
__virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
the upper 8 bits are used?
Probably not that much. But let's make it work satisfactorily for the
general case first, and then we might consider and test variations that
could accommodate msm.
Sounds like a good plan. We've got quite a few other things to clean up
before we can build for more than one arch anyway.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Tue, Jan 04, 2011 at 11:00:05AM -0800, David Brown wrote:
On Tue, Jan 04 2011, Nicolas Pitre wrote:
quoted
On Tue, 4 Jan 2011, David Brown wrote:
quoted
Any idea how much it would hurt other targets to have the
__virt_to_phys() and __phys_to_virt() have a 16-bit fixup, even if only
the upper 8 bits are used?
Probably not that much. But let's make it work satisfactorily for the
general case first, and then we might consider and test variations that
could accommodate msm.
Sounds like a good plan. We've got quite a few other things to clean up
before we can build for more than one arch anyway.
Actually, we can do this quite easily. Having a config symbol which
gets enabled when MSM is added, which then enables two consecutive
__pv_fixups gives us 16-bits to play with.
As I originally intended with my implementation, the value field of the
instruction can be used to identify what this fixup is about - and we
can put that to use by selecting either bits 31-24 or 23-16 of the
offset value.
This still allows optimizations to happen with instruction scheduling -
eg, for the MSM kernel I've just built with this enabled:
c000b320: e2844001 add r4, r4, #1 ; 0x1
c000b324: e59f3264 ldr r3, [pc, #612] ; c000b590 <setup_arch+0x690>
c000b328: e2844000 add r4, r4, #0 ; 0x0
c000b32c: e2833001 add r3, r3, #1 ; 0x1
c000b330: e59f5228 ldr r5, [pc, #552] ; c000b560 <setup_arch+0x660>
c000b334: e2833000 add r3, r3, #0 ; 0x0
The first and second adds comprise one translation, the second pair are
a second translation, and as you can see, the compiler scheduled the
loads inbetween.