Hi Rob, On 12/04/16 17:29, Rob Herring wrote: > On Mon, Apr 11, 2016 at 09:57:55AM +0100, Marc Zyngier wrote: >> Add a decription of the PPI partitioning support. >> >> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> >> --- >> .../bindings/interrupt-controller/arm,gic-v3.txt | 34 ++++++++++++++++++++-- >> 1 file changed, 32 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt >> index 007a5b4..4c29cda 100644 >> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt >> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt >> @@ -11,6 +11,8 @@ Main node required properties: >> - interrupt-controller : Identifies the node as an interrupt controller >> - #interrupt-cells : Specifies the number of cells needed to encode an >> interrupt source. Must be a single cell with a value of at least 3. >> + If the system requires describing PPI affinity, then the value must >> + be at least 4. > > You're winning for cell count... Yeah, it feels like we aim at making people's life difficult... > One alternative that would save adding a cell and keep it contained > within would be just list the affinities in the GIC node in the form of > '<PPI#> <count> <cpu phandles>': > > ppi-affinity = <1 2 &cpu2 &cpu3>, > <5 1 &cpu4>, > ... But how would that work if you have two sets of CPUs (set-1=[cpu0, cpu1]; set-2=[cpu2, cpu3]), and for the same PPI, device A is connected to set-1 and device-B is connected to set-2? You need a way to distinguish these two interrupts and so far, the only way I've found is to reference the affinity in the interrupt specifier. That being said, I'm definitely open to suggestions on how to describe this in a better way. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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
