On Tue, Jan 08, 2013 at 04:21:38PM +0000, Mark Rutland wrote:
> On Tue, Jan 08, 2013 at 02:53:42PM +0000, Hiroshi Doyu wrote:
[...]
> > > > static void __init tegra_smp_init_cpus(void)
> > > > {
> > > > - unsigned int i, ncores = scu_get_core_count(scu_base);
> > > > + unsigned int i, cpu_id, ncores;
> > > > + u32 l2ctlr;
> > > > + phys_addr_t pa;
> > > > +
> > > > + cpu_id = read_cpuid(CPUID_ID) & CPU_MASK;
> > > > + switch (cpu_id) {
> > > > + case CPU_CORTEX_A15:
> > > > + asm("mrc p15, 1, %0, c9, c0, 2\n" : "=r" (l2ctlr));
> > > > + ncores = ((l2ctlr >> 24) & 3) + 1;
> > > > + break;
> > >
> > > [...]
> > >
> > > As mentioned last time [1], you should get this information from the dt
> > > instead.
> >
> > Most of platsmp.c:.smp_init_cpus() implementations seem just to
> > overwrite # of cores by SCU/MRC detection. Is there any implementation
> > to use the DT's # and skip SCU/MRC detection in .smp_init_cpus()?
>
> As far as I can see, there's no other platform which just relies on
> arm_dt_init_cpu_maps. Until recently, it didn't exist, so that makes some
> sense. As far as I can see, for the Tegra 114 you only need your smp_init_cpus
> to call set_smp_cross_call(gic_raise_softirq). Everything else you do seems to
> be handled by arm_dt_init_cpus.
>
> I think the best option would be to have a separate smp_ops for your dt
> platforms where we know cpu nodes are populated (e.g. Tegra 114), where
> smp_init_cpus is different to that for non-dt platforms. That way non dt
> platforms can keep the SCU hack for now, and won't be broken, and the dt
> platforms are far removed from the SCU hack and just use common infrastructure.
>
> Maybe someone else has a better idea?
Have a look at mach-vexpress/platsmp.c (keeping in mind that the
GENERIC_SCU case will be refactored/removed since arm_dt_init_cpu_maps() is
doing most of the required steps), please let me know what you think.
Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
