On 14/02/18 12:08, Srinivas Kandagatla wrote: > > On 27/11/17 10:24, Stephen Boyd wrote: >> 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: <devicetree@xxxxxxxxxxxxxxx> >> Cc: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> >> Cc: Marc Zyngier <marc.zyngier@xxxxxxx> >> Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx> >> --- >> .../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. 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? > 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. -- 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
