On Thu, Feb 05, 2015 at 12:12:25PM +0000, Will Deacon wrote: > On Thu, Feb 05, 2015 at 11:56:01AM +0000, Mark Rutland wrote: > > On Mon, Jan 26, 2015 at 05:54:16PM +0000, Will Deacon wrote: > > > Historically, the PMU devicetree bindings have expected SPIs to be > > > listed in order of *logical* CPU number. This is problematic for > > > bootloaders, especially when the boot CPU (logical ID 0) isn't listed > > > first in the devicetree. > > > > > > This patch adds a new optional property, interrupt-affinity, to the > > > PMU node which allows the interrupt affinity to be described using > > > a list of phandled to CPU nodes, with each entry in the list > > > corresponding to the SPI at the same index in the interrupts property. > > > > > > Cc: Mark Rutland <mark.rutland@xxxxxxx> > > > Signed-off-by: Will Deacon <will.deacon@xxxxxxx> > > > --- > > > Documentation/devicetree/bindings/arm/pmu.txt | 6 +++ > > > arch/arm64/include/asm/pmu.h | 1 + > > > arch/arm64/kernel/perf_event.c | 57 +++++++++++++++++++++++++-- > > > 3 files changed, 60 insertions(+), 4 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt > > > index 75ef91d08f3b..a9281fc48743 100644 > > > --- a/Documentation/devicetree/bindings/arm/pmu.txt > > > +++ b/Documentation/devicetree/bindings/arm/pmu.txt > > > @@ -24,6 +24,12 @@ Required properties: > > > > > > Optional properties: > > > > > > +- interrupt-affinity : Valid only when using SPIs, specifies a list of phandles > > > + to CPU nodes corresponding directly to the affinity of > > > + the SPIs listed in the interrupts property. If absent, > > > + the interrupts are assumed to be listed in logical CPU > > > + order. > > > > This covers the case we care about today, but it's problematic in cases > > where the number of interrupts is not equal to the number of CPUs affine > > to that interrupt. For example: > > > > * PPIs in big.LITTLE systems, where we may need a node per cluster, and > > will need a way of associating a PMU node with a subset of all CPUs, > > despite having only one interrupt. > > > > * Muxed SPIs per-cluster (is this likely to happen?) > > > > The former can be covered by allowing multiple entries in > > interrupt-affintiy for PPIs. > > Yes, that sounds like a sensible extension in the future if we have to > support such a platform. > > > I'm not sure if the latter is something we need to cater for. If we do, > > then perhaps we need an interruptN-affinity property per interrupt (though > > that's ugly and painful to deal with). > > I'm not keen to handle this, so I'd rather defer it to whoever ends up > building it. Trying to design for every possibility is usually impossible > in my experience and you just end up carrying something that isn't useful. I suspected that would be the case. Just thought I should raise it as a potential problem. 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
