On 11/16/2012 07:56 PM, Will Deacon wrote: > On Thu, Nov 15, 2012 at 04:49:17PM +0000, Gregory CLEMENT wrote: >> On 11/15/2012 05:21 PM, Will Deacon wrote: >>> Anyway, that's by-the-by as this is all called early enough that we >>> shouldn't care. The thing I don't like now is that the fabric initialisation >>> is done entirely differently on the primary CPU than the secondaries. The >>> primary probes the device-tree (well, it's also now hard-coded for v2) and >>> accesses the registers from a C function(armada_370_xp_set_cpu_coherent) >>> whilst >>> the secondaries have hardcoded addresses and access via asm >>> (armada_xp_secondary_startup). >> >> >> Now it is hardcoded in both case as you pointed it. So the last >> difference is setup from a C function or via asm. >> >> The differences between primary and secondary CPU when they enable the >> coherency, is due to the fact that we really are in a different >> situation. For primary CPU, as it is the only CPU online it doesn't >> need to enable the coherency from the beginning, so we can wait to >> have MMU enable and convenient feature. Whereas for the secondary CPU >> they need the coherency from the very beginning are by definition they >> won't be alone. That's why this very first instruction are written in >> asm and they use physical address. >> >> I don't see how to handle it in a different way. > > The code paths are fine, I would just like to see less duplication. Can you > make the asm function PCS compliant and call it from C for the primary > (setting the link register to secondary_startup for the secondary cores)?
Have you a pointer on how to do it (make the asm function PCS compliant)? I will also need to add a parameter, because the base address are not the same between primary CPU and secondary CPUS. With the first we use virtual address whereas with the second the physical address. > > Will > > _______________________________________________ > linux-arm-kernel mailing list > [email protected] > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
