[PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[mark.rutland@arm.com (Mark Rutland)]

On Thu, Nov 14, 2013 at 12:18:47PM +0000, Sricharan R wrote:
> In some socs the gic can be preceded by a crossbar IP which
> routes the peripheral interrupts to the gic inputs. The peripheral
> interrupts are associated with a fixed crossbar input line and the
> crossbar routes that to one of the free gic input line.
> 
> The DT entries for peripherals provides the fixed crossbar input line
> as its interrupt number and the mapping code should associate this with
> a free gic input line. This patch adds the support inside the gic irqchip
> to handle such routable irqs. The routable irqs are registered in a linear
> domain. The registered routable domain's callback should be implemented
> to get a free irq and to configure the IP to route it.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
>  [V2] Added default routable-irqs functions to avoid
>       unnecessary if checks as per Thomas Gleixner comments
>       and renamed routable-irq binding as per
>       Kumar Gala <galak@codeaurora.org> comments.
> 
>  [V3] Addressed unnecessary warn-on and updated default
>       xlate function as per Thomas Gleixner comments
> 
>  Documentation/devicetree/bindings/arm/gic.txt |    6 ++
>  drivers/irqchip/irq-gic.c                     |   81 ++++++++++++++++++++++---
>  include/linux/irqchip/arm-gic.h               |    7 ++-
>  3 files changed, 83 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..5357745 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -49,6 +49,11 @@ Optional
>    regions, used when the GIC doesn't have banked registers. The offset is
>    cpu-offset * cpu-nr.
>  
> +- arm,routable-irqs : Total number of gic irq inputs which are not directly
> +		  connected from the peripherals, but are routed dynamically
> +		  by a crossbar/multiplexer preceding the GIC. The GIC irq
> +		  input line is assigned dynamically when the corresponding
> +		  peripheral's crossbar line is mapped.

I'm not keen on the design of the arm,routable-irqs property. The set of
IRQs which the crossbar IP can use is a property of which IRQ lines it
has routed to the GIC. I don't see why that should be considered a
property of the GIC; it's a property of the crossbar IP's attachment to
the GIC.

Given we already have a mechanism for describing the attachment (i.e.
the interrupts property) where the property appears on the node for the
device generating/propagating the interrupt, I don't see why we should
do differently here.

Listing 160 interrupts in the crossbar node is clearly something we
don't want to have to do.  If we had a property that we could use to
define a range (or multiple ranges) of interrupts, then the crossbar
driver could go and request those ranges from its interrupt-parent (the
GIC) and the GIC driver could reserve/allocate the irqdomain at that
time.

This feels like a point-hack, counter in style to the vast majority of
provider/consumer bindings. It only allows for one multiplexer before
the GIC. What if we had multiple multiplexers feeding into the GIC?
Describing the attachment on the multiplexer allows that to be handled,
describing that on the GIC does not.

Describing the attachement on the multiplexer would also prevent the
duplication of information (i.e. the max-irqs property in the crossbar
binding).

Thanks,
Mark.