On Thu, Feb 05, 2015 at 11:54:16AM +0000, Will Deacon wrote:
> On Thu, Feb 05, 2015 at 11:46:42AM +0000, Mark Rutland wrote:
> > On Mon, Jan 26, 2015 at 05:54:15PM +0000, Will Deacon wrote:
> > > diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
> > > index cb3073e4e7a8..4ed9287aaef1 100644
> > > --- a/arch/arm64/boot/dts/arm/juno.dts
> > > +++ b/arch/arm64/boot/dts/arm/juno.dts
> > > @@ -107,11 +107,11 @@
> > > pmu {
> > > compatible = "arm,armv8-pmuv3";
> > > interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>,
> > > <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
> > > <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
> > > - <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
> > > - <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>,
> > > - <GIC_SPI 06 IRQ_TYPE_LEVEL_HIGH>;
> > > + <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> >
> > I am very much not keen on this. While this may get things working
> > today, it completely relies on Linux-internal details (the order of CPU
> > bringup, which in this case is different from the order of entries in
> > /cpus).
> >
> > In all other dts that I am aware of, the order of entries in /cpus
> > aligns with the order of interrupts in the PMU node, and the first entry
> > is the boot CPU.
> >
> > I think that we should ensure that the ordering of CPU nodes matches the
> > order of interrupts here. That way we can fall back to that ordering (if
> > not explicitly overridden), and even after an arbitrary logical
> > renumbering (e.g. after a kexec) the relationship should stay intact.
>
> There are a few problems with reordering the CPU nodes:
>
> (1) It breaks any existing users of taskset to pin on big/little
> clusters.
This is unfortunate, but this is also the case if the boot CPU is
different.
> (2) It's not generally possible if, for example, the bootloader decides
> to boot Linux on a different CPU then we have no choice but to
> change the PMU interrupt order.
In that case _this_ patch is broken.
If we associate the interrupt with a CPU by node order, the relationship
is preserved regardless of which CPU is the boot CPU (whether it was the
bootloader's choice, kexec, or whatever).
> (3) I didn't think that the ordering of CPU nodes was guaranteed to be
> preserved by dtc, whereas the order of the interrupts will be.
The order of nodes is presently preserved.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
