On 05/09/2023 1:22 pm, Lorenzo Pieralisi wrote:
On Tue, Sep 05, 2023 at 12:17:51PM +0100, Robin Murphy wrote:
On 05/09/2023 11:47 am, Lorenzo Pieralisi wrote:
The GIC v3 specifications allow redistributors and ITSes interconnect
ports used to access memory to be wired up in a way that makes the
respective initiators/memory observers non-coherent.
Add the standard dma-noncoherent property to the GICv3 bindings to
allow firmware to describe the redistributors/ITSes components and
interconnect ports behaviour in system designs where the redistributors
and ITSes are not coherent with the CPU.
Signed-off-by: Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx>
Cc: Rob Herring <robh@xxxxxxxxxx>
---
.../bindings/interrupt-controller/arm,gic-v3.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index 39e64c7f6360..0a81ae4519a6 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -106,6 +106,10 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 4096
+ dma-noncoherent:
+ description: |
+ Present if the GIC redistributors are not cache coherent with the CPU.
I wonder if it's worth being a bit more specific here, e.g. "if the GIC
{redistributors,ITS} permit programming cacheable inner-shareable memory
attributes, but are connected to a non-coherent downstream interconnect."
In my opinion it is and I wanted to elaborate on what I wrote but then I
thought that this is a standard DT property, I wasn't sure whether we
really need to explain what it is there for.
We are using the property to plug a hole so I agree with you, we should
be as clear as possible in the property definition but I will rely on
Rob/Marc's opinion, I don't know what's the DT policy for this.
That might help clarify why the negative property, which could seem a bit
backwards at first glance, and that it's not so important in the cases where
the GIC itself is fundamentally non-coherent anyway (which *is*
software-discoverable).
Is it ? Again, see above, are we defining "dma-noncoherent" to fix a bug
or to fix the specs ? The shareability bits are writeable and even a
fundamentally non-coherent GIC design could allow writing them, AFAIU.
I mean the case on GIC-500 and earlier where the register bits could be
hard-wired. I'm not sure a GIC implementation which didn't even *try* to
honour the programmed attributes in what it emits would be considered
valid; it certainly couldn't be considered sensible :/
I would avoid putting ourselves into a corner where we can't use
this property because the binding itself is too strict on what it is
solving.
Really I'm just getting at the fact that if you do have a legacy GIC
with hard-wired attributes then whatever DT says is most likely
irrelevant anyway (unless the integrator has done something utterly
bonkers and tied off the interconnect input to *different* attributes,
but I would consider that beyond the bounds of fair reasoning...)
Cheers,
Robin.
Otherwise, this is the same approach that I like and have previously lobbied
for, so obviously I approve :)
(plus I do think it's the right shape to be able to slot an equivalent field
into ACPI MADT entries without *too* much bother)
We are in agreement, let's see what others think.
Thanks,
Lorenzo
Thanks,
Robin.
+
msi-controller:
description:
Only present if the Message Based Interrupt functionality is
@@ -193,6 +197,10 @@ patternProperties:
compatible:
const: arm,gic-v3-its
+ dma-noncoherent:
+ description: |
+ Present if the GIC ITS is not cache coherent with the CPU.
+
msi-controller: true
"#msi-cells":
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
