irqchip/gic-v3: Support MSIs via aliases and distributor
Subsystems (4)
PATCH 1/1 irqchip/gic-v3: Support MSIs via aliases and distributor
Some GIC configurations don't have an accessible ITS, but they want to support MSIs through the distributor's SETSPI registers or through the IMPLEMENTATION DEFINED message-based interrupt request register region. This mode of operation is similar to the v2m support on gic-400, but we don't necessarily know what particular SPIs are supported as MSIs so we need some help from firmware to know what to do.
Introduce an "arm,spi-ranges" property for this, similar to the "marvell,spi-ranges" property, that indicates the base and size of each MSI range. This property applies equally to the distributor and alias registers. In either case, we detect this mode of operation by looking for a node with the "msi-controller" property and then probe the v2m frame code on top of it. Assume these nodes will have the "arm,spi-ranges" property in them so that the v2m code works mostly unmodified.
--- .../bindings/interrupt-controller/arm,gic-v3.txt | 48 +++++++++- drivers/irqchip/irq-gic-v2m.c | 102 ++++++++++++++++----- drivers/irqchip/irq-gic-v3.c | 4 + include/linux/irqchip/arm-gic-common.h | 3 + 4 files changed, 129 insertions(+), 28 deletions(-)
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt +44 -4
@@ -57,6 +57,11 @@ Optional occupied by the redistributors. Required if more than one such region is present. +- msi-controller : Boolean property. Identifies the node as an MSI controller + +- arm,spi-ranges : Tuples of GIC SPI interrupt ranges (base, size) indicating + SPIs available for use as MSIs. + Sub-nodes: PPI affinity can be expressed as a single "ppi-partitions" node,
@@ -75,14 +80,28 @@ These nodes must have the following properties: - reg: Specifies the base physical address and size of the ITS registers. +GICv3 has an IMPLEMENTATION DEFINED set of aliases for message-based interrupt +requests. + +These nodes must have the following properties: +- compatible : Should at least contain one of + "qcom,gic-msi-aliases". +- msi-controller : Boolean property. Identifies the node as an MSI controller +- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device + which will generate the MSI. +- reg: Specifies the base physical address and size of the message-based + interrupt request registers. +- arm,spi-ranges: Tuples of GIC SPI interrupt ranges (base, size) indicating + SPIs available for use as MSIs. + +Note: The main GIC node must contain the appropriate #address-cells, +#size-cells and ranges properties for the reg property of all ITS and +alias message-based interrupt nodes. + Optional: - socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated address and size of the pre-ITS window. -The main GIC node must contain the appropriate #address-cells, -#size-cells and ranges properties for the reg property of all ITS -nodes. - Examples: gic: interrupt-controller at 2cf00000 {
@@ -149,6 +168,27 @@ Examples: }; }; + intc: interrupt-controller at 9bc0000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + interrupt-controller; + #redistributor-regions = <1>; + redistributor-stride = <0x0 0x40000>; + reg = <0x09bc0000 0x10000>, + <0x09c00000 0x100000>; + interrupts = <1 9 4>; + + msi_alias0: interrupt-controller at 9bd0000 { + compatible = "qcom,gic-msi-aliases"; + reg = <0x9bd0000 0x1000>; + msi-controller; + #msi-cells = <1>; + arm,spi-ranges = <544 96>; + }; + }; device at 0 { reg = <0 0 0 4>;
drivers/irqchip/irq-gic-v2m.c +78 -24
138 lines not on this page · raw message
drivers/irqchip/irq-gic-v3.c +4 -0
@@ -1267,6 +1267,10 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pareif (static_key_true (&supports_deactivate))gic_of_setup_kvm_info (node); + +if (IS_ENABLED (CONFIG_ARM_GIC_V2M )) +gicv2m_init_gicv3 (&node->fwnode, gic_data.domain); +return 0 ; out_unmap_rdist:
include/linux/irqchip/arm-gic-common.h +3 -0
@@ -33,4 +33,7 @@ struct gic_kvm_info {const struct gic_kvm_info *gic_get_kvm_info (void ); +int gicv2m_init_gicv3 (struct fwnode_handle *parent_handle, +struct irq_domain *parent); +#endif /* __LINUX_IRQCHIP_ARM_GIC_COMMON_H */
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Hi Stephen,
Thanks for the patch.
Quoted 17 lines · Stephen Boyd
Some GIC configurations don't have an accessible ITS, but they want to support MSIs through the distributor's SETSPI registers or through the IMPLEMENTATION DEFINED message-based interrupt request register region. This mode of operation is similar to the v2m support on gic-400, but we don't necessarily know what particular SPIs are supported as MSIs so we need some help from firmware to know what to do.
Introduce an "arm,spi-ranges" property for this, similar to the "marvell,spi-ranges" property, that indicates the base and size of each MSI range. This property applies equally to the distributor and alias registers. In either case, we detect this mode of operation by looking for a node with the "msi-controller" property and then probe the v2m frame code on top of it. Assume these nodes will have the "arm,spi-ranges" property in them so that the v2m code works mostly unmodified.
Quoted 4 lines
Cc <[email protected]>Cc Srinivas Kandagatla <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Stephen Boyd <[email protected]>
Tested it on DB820c board.
Quoted 17 lines · Stephen Boyd
Some GIC configurations don't have an accessible ITS, but they want to support MSIs through the distributor's SETSPI registers or through the IMPLEMENTATION DEFINED message-based interrupt request register region. This mode of operation is similar to the v2m support on gic-400, but we don't necessarily know what particular SPIs are supported as MSIs so we need some help from firmware to know what to do.
Introduce an "arm,spi-ranges" property for this, similar to the "marvell,spi-ranges" property, that indicates the base and size of each MSI range. This property applies equally to the distributor and alias registers. In either case, we detect this mode of operation by looking for a node with the "msi-controller" property and then probe the v2m frame code on top of it. Assume these nodes will have the "arm,spi-ranges" property in them so that the v2m code works mostly unmodified.
Quoted 6 lines
Cc <[email protected]>Cc Srinivas Kandagatla <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Stephen Boyd <[email protected]>--- .../bindings/interrupt-controller/arm,gic-v3.txt | 48 +++++++++-
Quoted 4 lines
drivers/irqchip/irq-gic-v2m.c | 102 ++++++++++++++++----- drivers/irqchip/irq-gic-v3.c | 4 + include/linux/irqchip/arm-gic-common.h | 3 + 4 files changed, 129 insertions(+), 28 deletions(-)
Quoted 21 lines · Stephen Boyd
Some GIC configurations don't have an accessible ITS, but they want to support MSIs through the distributor's SETSPI registers or through the IMPLEMENTATION DEFINED message-based interrupt request register region. This mode of operation is similar to the v2m support on gic-400, but we don't necessarily know what particular SPIs are supported as MSIs so we need some help from firmware to know what to do.
Introduce an "arm,spi-ranges" property for this, similar to the "marvell,spi-ranges" property, that indicates the base and size of each MSI range. This property applies equally to the distributor and alias registers. In either case, we detect this mode of operation by looking for a node with the "msi-controller" property and then probe the v2m frame code on top of it. Assume these nodes will have the "arm,spi-ranges" property in them so that the v2m code works mostly unmodified.
Cc <[email protected]>Cc Srinivas Kandagatla <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Stephen Boyd <[email protected]>
Quoted 6 lines
--- .../bindings/interrupt-controller/arm,gic-v3.txt | 48 +++++++++- drivers/irqchip/irq-gic-v2m.c | 102 ++++++++++++++++----- drivers/irqchip/irq-gic-v3.c | 4 + include/linux/irqchip/arm-gic-common.h | 3 + 4 files changed, 129 insertions(+), 28 deletions(-)
What's the plan on this?
I have not seen this patch in rc1 or in next.
We have a dependency on this to get WLAN working on DragonBoard820c.
thanks,
Srini
Quoted 30 lines · Srinivas Kandagatla
Quoted 21 lines · Stephen Boyd
Some GIC configurations don't have an accessible ITS, but they want to support MSIs through the distributor's SETSPI registers or through the IMPLEMENTATION DEFINED message-based interrupt request register region. This mode of operation is similar to the v2m support on gic-400, but we don't necessarily know what particular SPIs are supported as MSIs so we need some help from firmware to know what to do.
Introduce an "arm,spi-ranges" property for this, similar to the "marvell,spi-ranges" property, that indicates the base and size of each MSI range. This property applies equally to the distributor and alias registers. In either case, we detect this mode of operation by looking for a node with the "msi-controller" property and then probe the v2m frame code on top of it. Assume these nodes will have the "arm,spi-ranges" property in them so that the v2m code works mostly unmodified.
Cc <[email protected]>Cc Srinivas Kandagatla <[email protected]>Cc Marc Zyngier <[email protected]>Signed-off-by Stephen Boyd <[email protected]>Quoted 6 lines
--- .../bindings/interrupt-controller/arm,gic-v3.txt | 48 +++++++++- drivers/irqchip/irq-gic-v2m.c | 102 ++++++++++++++++----- drivers/irqchip/irq-gic-v3.c | 4 + include/linux/irqchip/arm-gic-common.h | 3 + 4 files changed, 129 insertions(+), 28 deletions(-)
Quoted 2 lines
What's the plan on this?
I have not seen this patch in rc1 or in next.
Because I haven't had a chance to review it just yet. It will certainly not be merged before 4.17. Looking at it, it isn't anywhere near getting there.
Stacking the v2m driver on top of GICv3 is at best wrong. This is not the same HW, and I've NACKed that approach in the past. You're ignoring the level interrupt for which the HW has support for.
I've mentioned reusing the GICP driver in the past, as it already caters for some of that, even if we're missing some infrastructure. How about having a common approach instead of reinventing the wheel?
Quoted 1 line
We have a dependency on this to get WLAN working on DragonBoard820c.
Even more of a reason to do the right thing then. If you want to have this supported, it needs to be a first class citizen, not a mix of two unrelated architectures.
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...