[RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Sricharan R]

Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the interrupt
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt controllers are preceded by an
IRQ CROSSBAR that provides flexibility in muxing the device interrupt
requests to the controller inputs.

This series models the peripheral interrupts that can be routed through
the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
in a separate linear domain inside the GIC. The registered routable domain's
callback are invoked as a part of the GIC's callback, which in turn should
allocate a free irq line and configure the IP accordingly. So every peripheral
in the dts files mentions the fixed crossbar number as its interrupt. A free
gic line for that gets allocated and configured when the peripheral's interrupt
is mapped.

The minimal crossbar driver to track and allocate free GIC lines and configure the
crossbar is added here, along with the DT bindings.

Sricharan R (6):
  DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
  DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
  ARM: DTS: DRA: Add crossbar device binding
  ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar
    inputs.
  ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
  ARM: DRA: Enable Crossbar IP support for DRA7XX

 Documentation/devicetree/bindings/arm/gic.txt      |    5 +
 .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
 arch/arm/boot/dts/dra7.dtsi                        |   98 +++++-----
 arch/arm/mach-omap2/Kconfig                        |    1 +
 arch/arm/mach-omap2/omap-wakeupgen.c               |    4 +-
 arch/arm/mach-omap2/omap4-common.c                 |    4 +
 drivers/irqchip/Kconfig                            |    8 +
 drivers/irqchip/Makefile                           |    1 +
 drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
 drivers/irqchip/irq-gic.c                          |   57 +++++-
 include/linux/irqchip/arm-gic.h                    |    8 +-
 include/linux/irqchip/irq-crossbar.h               |   11 ++
 12 files changed, 363 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
 create mode 100644 drivers/irqchip/irq-crossbar.c
 create mode 100644 include/linux/irqchip/irq-crossbar.h

-- 
1.7.9.5

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

[Sricharan R]

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>
---
 Documentation/devicetree/bindings/arm/gic.txt |    5 +++
 arch/arm/boot/dts/dra7.dtsi                   |    1 +
 drivers/irqchip/irq-gic.c                     |   57 +++++++++++++++++++++----
 include/linux/irqchip/arm-gic.h               |    8 +++-
 4 files changed, 61 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..2d8c680 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.
 
+- 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.
 Example:
 
 	intc: interrupt-controller@fff11000 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..b35cb12 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -55,6 +55,7 @@
 		compatible = "arm,cortex-a15-gic";
 		interrupt-controller;
 		#interrupt-cells = <3>;
+		routable_irqs = <160>;
 		reg = <0x48211000 0x1000>,
 		      <0x48212000 0x1000>;
 	};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
+const struct irq_domain_ops *gic_routable_irq_domain_ops;
+
 /*
  * The GIC mapping of CPU interfaces does not necessarily match
  * the logical CPU numbering.  Let's use a mapping as returned
@@ -675,11 +677,26 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 		irq_set_chip_and_handler(irq, &gic_chip,
 					 handle_fasteoi_irq);
 		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+		if (gic_routable_irq_domain_ops &&
+		    gic_routable_irq_domain_ops->map)
+			gic_routable_irq_domain_ops->map(d, irq, hw);
 	}
 	irq_set_chip_data(irq, d->host_data);
 	return 0;
 }
 
+static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+
+	if (hw > 32) {
+		if (gic_routable_irq_domain_ops &&
+		    gic_routable_irq_domain_ops->unmap)
+			gic_routable_irq_domain_ops->unmap(d, irq);
+	}
+}
+
 static int gic_irq_domain_xlate(struct irq_domain *d,
 				struct device_node *controller,
 				const u32 *intspec, unsigned int intsize,
@@ -694,8 +711,15 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
 	*out_hwirq = intspec[1] + 16;
 
 	/* For SPIs, we need to add 16 more to get the GIC irq ID number */
-	if (!intspec[0])
-		*out_hwirq += 16;
+	if (!intspec[0]) {
+		if (gic_routable_irq_domain_ops &&
+		    gic_routable_irq_domain_ops->xlate)
+			*out_hwirq = gic_routable_irq_domain_ops->xlate(d,
+						controller, intspec, intsize,
+						out_hwirq, out_type);
+		else
+			*out_hwirq += 16;
+	}
 
 	*out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
 	return 0;
@@ -722,6 +746,7 @@ static struct notifier_block __cpuinitdata gic_cpu_notifier = {
 
 const struct irq_domain_ops gic_irq_domain_ops = {
 	.map = gic_irq_domain_map,
+	.unmap = gic_irq_domain_unmap,
 	.xlate = gic_irq_domain_xlate,
 };
 
@@ -732,6 +757,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
 	irq_hw_number_t hwirq_base;
 	struct gic_chip_data *gic;
 	int gic_irqs, irq_base, i;
+	int nr_routable_irqs;
 
 	BUG_ON(gic_nr >= MAX_GIC_NR);
 
@@ -797,14 +823,27 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
 	gic->gic_irqs = gic_irqs;
 
 	gic_irqs -= hwirq_base; /* calculate # of irqs to allocate */
-	irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
-	if (IS_ERR_VALUE(irq_base)) {
-		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
-		     irq_start);
-		irq_base = irq_start;
+
+	if (of_property_read_u32(node, "routable_irqs", &nr_routable_irqs)) {
+		irq_base = irq_alloc_descs(irq_start, 16, gic_irqs,
+					   numa_node_id());
+		if (IS_ERR_VALUE(irq_base)) {
+			WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+			     irq_start);
+			irq_base = irq_start;
+		}
+
+		gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+					hwirq_base, &gic_irq_domain_ops, gic);
+	} else {
+		if (WARN_ON(!gic_routable_irq_domain_ops))
+			return;
+
+		gic->domain = irq_domain_add_linear(node, nr_routable_irqs,
+						    &gic_irq_domain_ops,
+						    gic);
 	}
-	gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
-				    hwirq_base, &gic_irq_domain_ops, gic);
+
 	if (WARN_ON(!gic->domain))
 		return;
 
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb..fd4192a 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -73,6 +73,12 @@ static inline void gic_init(unsigned int nr, int start,
 	gic_init_bases(nr, start, dist, cpu, 0, NULL);
 }
 
-#endif /* __ASSEMBLY */
+extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+					(const struct irq_domain_ops *ops)
+{
+	gic_routable_irq_domain_ops = ops;
+}
 
+#endif /* __ASSEMBLY */
 #endif
-- 
1.7.9.5

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Marc Zyngier]

On 30/09/13 14:59, 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.

Isn't this just another chained interrupt controller? How is it GIC
specific?

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Santosh Shilimkar]

On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
> On 30/09/13 14:59, 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.
> 
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
> 
No it isn't a irq controller rather a event router. Patch is missing
reference to the previous discussion. Previous discussion is here [1]

Regards,
Santosh

[1] https://lkml.org/lkml/2013/9/13/413

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Marc Zyngier]

On 30/09/13 15:22, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>>
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
> 
> Regards,
> Santosh
> 
> [1] https://lkml.org/lkml/2013/9/13/413

Right. I need to go and understand that bit first.

Thanks Santosh.

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Sricharan R]

On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
>
Sorry, missed adding that and thanks for pointing it.

Regards,
 Sricharan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Linus Walleij]

On Mon, Sep 30, 2013 at 4:16 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?

I thought so from the beginning but I was dead wrong, as pointed out
by tglx it is basically a hardware .map function, so its usecase will map
to the irqdomain .map/.unmap so to say.

Yours,
Linus Walleij

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Thomas Gleixner]

On Mon, 30 Sep 2013, Sricharan R wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 1760ceb..c5778ab 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -72,6 +72,8 @@ struct gic_chip_data {
>  
>  static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>  
> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
> +
>  /*
>   * The GIC mapping of CPU interfaces does not necessarily match
>   * the logical CPU numbering.  Let's use a mapping as returned
> @@ -675,11 +677,26 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>  		irq_set_chip_and_handler(irq, &gic_chip,
>  					 handle_fasteoi_irq);
>  		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
> +
> +		if (gic_routable_irq_domain_ops &&
> +		    gic_routable_irq_domain_ops->map)
> +			gic_routable_irq_domain_ops->map(d, irq, hw);

Shudder. Why are you sprinkling these if (ops && ops->fun)
conditionals all over the place instead of having a default ops
implementation which handles the non crossbar case by proper empty
functions. That code is not on a hot path so it does not matter at
all.

>  	}
>  	irq_set_chip_data(irq, d->host_data);
>  	return 0;
>  }
>  
> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> +	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
> +
> +	if (hw > 32) {

Groan. This wants to be in the ops->unmap function. It's not related
to the GIC core code.

> +		if (gic_routable_irq_domain_ops &&
> +		    gic_routable_irq_domain_ops->unmap)
> +			gic_routable_irq_domain_ops->unmap(d, irq);
> +	}
> +}
> +
>  static int gic_irq_domain_xlate(struct irq_domain *d,
>  				struct device_node *controller,
>  				const u32 *intspec, unsigned int intsize,
> @@ -694,8 +711,15 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
>  	*out_hwirq = intspec[1] + 16;
>  
>  	/* For SPIs, we need to add 16 more to get the GIC irq ID number */
> -	if (!intspec[0])
> -		*out_hwirq += 16;
> +	if (!intspec[0]) {
> +		if (gic_routable_irq_domain_ops &&
> +		    gic_routable_irq_domain_ops->xlate)
> +			*out_hwirq = gic_routable_irq_domain_ops->xlate(d,
> +						controller, intspec, intsize,
> +						out_hwirq, out_type);
> +		else
> +			*out_hwirq += 16;
> +	}

So if you have a default xlate ops implementation then this boils down to

      if (!intspec[0])
		*out_hwirq = routing_ops->xlate()

And the default (non crossbar) implementation would be:

    	return *out_hwirq + 16;
    

Thanks,

	tglx

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Sricharan R]

Hi Thomas,

Thanks a lot for reviewing this.

On Thursday 24 October 2013 02:42 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 1760ceb..c5778ab 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -72,6 +72,8 @@ struct gic_chip_data {
>>  
>>  static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>  
>> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
>> +
>>  /*
>>   * The GIC mapping of CPU interfaces does not necessarily match
>>   * the logical CPU numbering.  Let's use a mapping as returned
>> @@ -675,11 +677,26 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>>  		irq_set_chip_and_handler(irq, &gic_chip,
>>  					 handle_fasteoi_irq);
>>  		set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
>> +
>> +		if (gic_routable_irq_domain_ops &&
>> +		    gic_routable_irq_domain_ops->map)
>> +			gic_routable_irq_domain_ops->map(d, irq, hw);
> Shudder. Why are you sprinkling these if (ops && ops->fun)
> conditionals all over the place instead of having a default ops
> implementation which handles the non crossbar case by proper empty
> functions. That code is not on a hot path so it does not matter at
> all.
>
 Ok, Understand. Will add default ops to avoid these checks.
>>  	}
>>  	irq_set_chip_data(irq, d->host_data);
>>  	return 0;
>>  }
>>  
>> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> +	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
>> +
>> +	if (hw > 32) {
> Groan. This wants to be in the ops->unmap function. It's not related
> to the GIC core code.
 Ok, will move this to unmap ops of the crossbar.
>> +		if (gic_routable_irq_domain_ops &&
>> +		    gic_routable_irq_domain_ops->unmap)
>> +			gic_routable_irq_domain_ops->unmap(d, irq);
>> +	}
>> +}
>> +
>>  static int gic_irq_domain_xlate(struct irq_domain *d,
>>  				struct device_node *controller,
>>  				const u32 *intspec, unsigned int intsize,
>> @@ -694,8 +711,15 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
>>  	*out_hwirq = intspec[1] + 16;
>>  
>>  	/* For SPIs, we need to add 16 more to get the GIC irq ID number */
>> -	if (!intspec[0])
>> -		*out_hwirq += 16;
>> +	if (!intspec[0]) {
>> +		if (gic_routable_irq_domain_ops &&
>> +		    gic_routable_irq_domain_ops->xlate)
>> +			*out_hwirq = gic_routable_irq_domain_ops->xlate(d,
>> +						controller, intspec, intsize,
>> +						out_hwirq, out_type);
>> +		else
>> +			*out_hwirq += 16;
>> +	}
> So if you have a default xlate ops implementation then this boils down to
>
>       if (!intspec[0])
> 		*out_hwirq = routing_ops->xlate()
>
> And the default (non crossbar) implementation would be:
>
>     	return *out_hwirq + 16;
>     
 Ok. This is better. Will change here.


Regards,
 Sricharan

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Kumar Gala]

On Sep 30, 2013, at 8:59 AM, 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>
> ---
> Documentation/devicetree/bindings/arm/gic.txt |    5 +++
> arch/arm/boot/dts/dra7.dtsi                   |    1 +
> drivers/irqchip/irq-gic.c                     |   57 +++++++++++++++++++++----
> include/linux/irqchip/arm-gic.h               |    8 +++-
> 4 files changed, 61 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..2d8c680 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.
> 
> +- 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.

arm,routable-irqs

> Example:
> 
> 	intc: interrupt-controller@fff11000 {

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs

[Sricharan R]

On Thursday 24 October 2013 03:08 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8:59 AM, 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>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt |    5 +++
>> arch/arm/boot/dts/dra7.dtsi                   |    1 +
>> drivers/irqchip/irq-gic.c                     |   57 +++++++++++++++++++++----
>> include/linux/irqchip/arm-gic.h               |    8 +++-
>> 4 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..2d8c680 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.
>>
>> +- 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.
> arm,routable-irqs
 ok will change here as well.

 Thanks for reviewing.

Regards,
 Sricharan

[RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Sricharan R]

Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.

This driver takes care a allocating a free irq and then configuring the
crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
be called right before the irqchip_init, so that it is setup to handle the
irqchip callbacks.

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>
---
 .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
 drivers/irqchip/Kconfig                            |    8 +
 drivers/irqchip/Makefile                           |    1 +
 drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
 include/linux/irqchip/irq-crossbar.h               |   11 ++
 5 files changed, 242 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
 create mode 100644 drivers/irqchip/irq-crossbar.c
 create mode 100644 include/linux/irqchip/irq-crossbar.h

diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 0000000..cdec2cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be "ti,irq-crossbar"
+- reg: Base address and the size of the crossbar registers.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: Size of a individual register in bytes. Every individual
+	    register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+		 crossbar. These interrupt lines are reserved in the soc,
+		 so crossbar bar driver should not consider them as free
+		 lines.
+
+Examples:
+		crossbar_mpu: @4a020000 {
+			compatible = "ti,irq-crossbar";
+			reg = <0x4a002a48 0x130>;
+			max-irqs = <160>;
+			reg-size = <2>;
+			irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+		};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..ed6ced28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -41,3 +41,11 @@ config VERSATILE_FPGA_IRQ_NR
        int
        default 4
        depends on VERSATILE_FPGA_IRQ
+
+config IRQ_CROSSBAR
+	bool
+	help
+	  Support for a CROSSBAR ip that preceeds the main interrupt controller.
+	  The primary irqchip invokes the crossbar's callback which inturn allocates
+	  a free irq and configures the IP. Thus the peripheral interrupts are
+	  routed to one of the free irqchip interrupt lines.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..7f690b7 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_RENESAS_INTC_IRQPIN)	+= irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC)		+= irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)	+= irq-versatile-fpga.o
 obj-$(CONFIG_ARCH_VT8500)		+= irq-vt8500.o
+obj-$(CONFIG_IRQ_CROSSBAR)		+= irq-crossbar.o
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
new file mode 100644
index 0000000..3e1b488
--- /dev/null
+++ b/drivers/irqchip/irq-crossbar.c
@@ -0,0 +1,195 @@
+/*
+ *  drivers/irqchip/irq-crossbar.c
+ *
+ *  Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+#include <linux/irqchip/arm-gic.h>
+
+#define IRQ_FREE	-1
+#define GIC_IRQ_START	32
+
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+	uint int_max;
+	uint *irq_map;
+	void __iomem *crossbar_base;
+	int *register_offsets;
+	void (*write) (int, int);
+};
+
+static struct crossbar_device *cb;
+
+static inline void crossbar_writel(int irq_no, int cb_no)
+{
+	writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writew(int irq_no, int cb_no)
+{
+	writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writeb(int irq_no, int cb_no)
+{
+	writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline const u32 allocate_free_irq(int cb_no)
+{
+	int i;
+
+	for (i = 0; i < cb->int_max; i++) {
+		if (cb->irq_map[i] == IRQ_FREE) {
+			cb->irq_map[i] = cb_no;
+			return i;
+		}
+	}
+
+	return -ENODEV;
+}
+
+static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
+			       irq_hw_number_t hw)
+{
+	cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+	return 0;
+}
+
+static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq - GIC_IRQ_START;
+	cb->irq_map[hw] = IRQ_FREE;
+}
+
+static int crossbar_domain_xlate(struct irq_domain *d,
+				 struct device_node *controller,
+				 const u32 *intspec, unsigned int intsize,
+				 unsigned long *out_hwirq,
+				 unsigned int *out_type)
+{
+	return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
+}
+
+const struct irq_domain_ops routable_irq_domain_ops = {
+	.map = crossbar_domain_map,
+	.unmap = crossbar_domain_unmap,
+	.xlate = crossbar_domain_xlate
+};
+
+static int __init crossbar_of_init(struct device_node *node)
+{
+	int i, size, max, reserved = 0, entry;
+	const __be32 *irqsr;
+
+	cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
+
+	if (!cb)
+		return -ENOMEM;
+
+	cb->crossbar_base = of_iomap(node, 0);
+	if (!cb->crossbar_base)
+		goto err1;
+
+	of_property_read_u32(node, "max-irqs", &max);
+	cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+	if (!cb->irq_map)
+		goto err2;
+
+	cb->int_max = max;
+
+	for (i = 0; i < max; i++)
+		cb->irq_map[i] = IRQ_FREE;
+
+	/* Get and mark reserved irqs */
+	irqsr = of_get_property(node, "irqs-reserved", &size);
+	if (irqsr) {
+		size /= sizeof(__be32);
+
+		for (i = 0; i < size; i++) {
+			entry = be32_to_cpup(irqsr + i);
+			if (entry > max) {
+				pr_err("Invalid reserved entry\n");
+				goto err3;
+			}
+			cb->irq_map[entry] = 0;
+		}
+	}
+
+	cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+	if (!cb->register_offsets)
+		goto err3;
+
+	of_property_read_u32(node, "reg-size", &size);
+
+	switch (size) {
+	case 1:
+		cb->write = crossbar_writeb;
+		break;
+	case 2:
+		cb->write = crossbar_writew;
+		break;
+	case 4:
+		cb->write = crossbar_writel;
+		break;
+	default:
+		pr_err("Invalid reg-size property\n");
+		goto err4;
+		break;
+	}
+
+	/*
+	 * Register offsets are not linear because of the
+	 * reserved irqs. so find and store the offsets once.
+	 */
+	for (i = 0; i < max; i++) {
+		if (!cb->irq_map[i])
+			continue;
+
+		cb->register_offsets[i] = reserved;
+		reserved += size;
+	}
+
+	register_routable_domain_ops(&routable_irq_domain_ops);
+	return 0;
+
+err4:
+	kfree(cb->register_offsets);
+err3:
+	kfree(cb->irq_map);
+err2:
+	iounmap(cb->crossbar_base);
+err1:
+	kfree(cb);
+	return -ENOMEM;
+}
+
+static const struct of_device_id crossbar_match[] __initconst = {
+	{ .compatible = "ti,irq-crossbar" },
+	{}
+};
+
+int crossbar_init(void)
+{
+	struct device_node *np;
+	np = of_find_matching_node(NULL, crossbar_match);
+	if (!np)
+		return -ENODEV;
+
+	crossbar_of_init(np);
+	return 0;
+}
diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
new file mode 100644
index 0000000..ad2f744
--- /dev/null
+++ b/include/linux/irqchip/irq-crossbar.h
@@ -0,0 +1,11 @@
+/*
+ *  drivers/irqchip/irq-crossbar.h
+ *
+ *  Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+int crossbar_init(void);
-- 
1.7.9.5

Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Thomas Gleixner]

On Mon, 30 Sep 2013, Sricharan R wrote:
> +/*
> + * @int_max: maximum number of supported interrupts
> + * @irq_map: array of interrupts to crossbar number mapping
> + * @crossbar_base: crossbar base address
> + * @register_offsets: offsets for each irq number
> + */
> +struct crossbar_device {
> +	uint int_max;
> +	uint *irq_map;

Why do you need another map here?

Isn't the linear_revmap of the irqdomain sufficient?

> +static inline const u32 allocate_free_irq(int cb_no)
> +{
> +	int i;
> +
> +	for (i = 0; i < cb->int_max; i++) {
> +		if (cb->irq_map[i] == IRQ_FREE) {
> +			cb->irq_map[i] = cb_no;
> +			return i;
> +		}
> +	}
> +
> +	return -ENODEV;
> +}
> +
> +static int crossbar_domain_xlate(struct irq_domain *d,
> +				 struct device_node *controller,
> +				 const u32 *intspec, unsigned int intsize,
> +				 unsigned long *out_hwirq,
> +				 unsigned int *out_type)
> +{
> +	return allocate_free_irq(intspec[1]) + GIC_IRQ_START;

Mooo. In the error case you return:

      -ENODEV + GIC_IRQ_START == -19 + 32 == 13

Yikes.

> +
> +	/*
> +	 * Register offsets are not linear because of the
> +	 * reserved irqs. so find and store the offsets once.
> +	 */
> +	for (i = 0; i < max; i++) {
> +		if (!cb->irq_map[i])
> +			continue;
> +
> +		cb->register_offsets[i] = reserved;
> +		reserved += size;

I'm amazed by such a brilliant hardware design.

Thanks,

	tglx

Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Sricharan R]

Hi Thomas,

On Thursday 24 October 2013 02:50 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> +/*
>> + * @int_max: maximum number of supported interrupts
>> + * @irq_map: array of interrupts to crossbar number mapping
>> + * @crossbar_base: crossbar base address
>> + * @register_offsets: offsets for each irq number
>> + */
>> +struct crossbar_device {
>> +	uint int_max;
>> +	uint *irq_map;
> Why do you need another map here?
>
> Isn't the linear_revmap of the irqdomain sufficient?
 linear_revmap gives the linux-irq for hw-irq,
 but here i need the crossbar number corresponding to
 the hwirq allocated. This is needed for setting up the
 crossbar register in map.
>> +static inline const u32 allocate_free_irq(int cb_no)
>> +{
>> +	int i;
>> +
>> +	for (i = 0; i < cb->int_max; i++) {
>> +		if (cb->irq_map[i] == IRQ_FREE) {
>> +			cb->irq_map[i] = cb_no;
>> +			return i;
>> +		}
>> +	}
>> +
>> +	return -ENODEV;
>> +}
>> +
>> +static int crossbar_domain_xlate(struct irq_domain *d,
>> +				 struct device_node *controller,
>> +				 const u32 *intspec, unsigned int intsize,
>> +				 unsigned long *out_hwirq,
>> +				 unsigned int *out_type)
>> +{
>> +	return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
> Mooo. In the error case you return:
>
>       -ENODEV + GIC_IRQ_START == -19 + 32 == 13
>
> Yikes.
 ya. will be a problem with error case. Will add a check here and
 in the gic as well to check for the return value.
>> +
>> +	/*
>> +	 * Register offsets are not linear because of the
>> +	 * reserved irqs. so find and store the offsets once.
>> +	 */
>> +	for (i = 0; i < max; i++) {
>> +		if (!cb->irq_map[i])
>> +			continue;
>> +
>> +		cb->register_offsets[i] = reserved;
>> +		reserved += size;
> I'm amazed by such a brilliant hardware design.
>
> Thanks,
>
> 	tglx

Regards,
 Sricharan

Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Kumar Gala]

On Sep 30, 2013, at 8:59 AM, Sricharan R wrote:

> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the
> interrupt lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-controller appropriately.
> In such places a interrupt controllers are preceded by an CROSSBAR
> that provides flexibility in muxing the device requests to the controller
> inputs.
> 
> This driver takes care a allocating a free irq and then configuring the
> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> be called right before the irqchip_init, so that it is setup to handle the
> irqchip callbacks.
> 
> 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>
> ---
> .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
> drivers/irqchip/Kconfig                            |    8 +
> drivers/irqchip/Makefile                           |    1 +
> drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
> include/linux/irqchip/irq-crossbar.h               |   11 ++
> 5 files changed, 242 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
> create mode 100644 drivers/irqchip/irq-crossbar.c
> create mode 100644 include/linux/irqchip/irq-crossbar.h
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..cdec2cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,27 @@
> +Some socs have a large number of interrupts requests to service
> +the needs of its many peripherals and subsystems. All of the
> +interrupt lines from the subsystems are not needed at the same
> +time, so they have to be muxed to the irq-controller appropriately.
> +In such places a interrupt controllers are preceded by an CROSSBAR
> +that provides flexibility in muxing the device requests to the controller
> +inputs.
> +
> +Required properties:
> +- compatible : Should be "ti,irq-crossbar"
> +- reg: Base address and the size of the crossbar registers.
> +- max-irqs: Total number of irqs available at the interrupt controller.

Should be 'ti,max-irqs

> +- reg-size: Size of a individual register in bytes. Every individual
> +	    register is assumed to be of same size. Valid sizes are 1, 2, 4.

Is this something that really needs to be encoded in the dts?

If we keep it should be ti,reg-size

> +- irqs-reserved: List of the reserved irq lines that are not muxed using
> +		 crossbar. These interrupt lines are reserved in the soc,
> +		 so crossbar bar driver should not consider them as free
> +		 lines.
> +

ti,irqs-reserved

> +Examples:
> +		crossbar_mpu: @4a020000 {

Did you mean for there to be a label and no node name?

> +			compatible = "ti,irq-crossbar";
> +			reg = <0x4a002a48 0x130>;
> +			max-irqs = <160>;
> +			reg-size = <2>;
> +			irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> +		};

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Sricharan R]

Hi Kumar,

On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8:59 AM, Sricharan R wrote:
>
>> Some socs have a large number of interrupts requests to service
>> the needs of its many peripherals and subsystems. All of the
>> interrupt lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the irq-controller appropriately.
>> In such places a interrupt controllers are preceded by an CROSSBAR
>> that provides flexibility in muxing the device requests to the controller
>> inputs.
>>
>> This driver takes care a allocating a free irq and then configuring the
>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>> be called right before the irqchip_init, so that it is setup to handle the
>> irqchip callbacks.
>>
>> 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>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
>> drivers/irqchip/Kconfig                            |    8 +
>> drivers/irqchip/Makefile                           |    1 +
>> drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
>> include/linux/irqchip/irq-crossbar.h               |   11 ++
>> 5 files changed, 242 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> create mode 100644 drivers/irqchip/irq-crossbar.c
>> create mode 100644 include/linux/irqchip/irq-crossbar.h
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..cdec2cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,27 @@
>> +Some socs have a large number of interrupts requests to service
>> +the needs of its many peripherals and subsystems. All of the
>> +interrupt lines from the subsystems are not needed at the same
>> +time, so they have to be muxed to the irq-controller appropriately.
>> +In such places a interrupt controllers are preceded by an CROSSBAR
>> +that provides flexibility in muxing the device requests to the controller
>> +inputs.
>> +
>> +Required properties:
>> +- compatible : Should be "ti,irq-crossbar"
>> +- reg: Base address and the size of the crossbar registers.
>> +- max-irqs: Total number of irqs available at the interrupt controller.
> Should be 'ti,max-irqs
 Ok, will correct.
>> +- reg-size: Size of a individual register in bytes. Every individual
>> +	    register is assumed to be of same size. Valid sizes are 1, 2, 4.
> Is this something that really needs to be encoded in the dts?
>
> If we keep it should be ti,reg-size
Currently, this is the only IP with a fixed register-size.
 So this can be in the driver also. I thought keeping it
DT will avoid any hard-coding in driver.
>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>> +		 crossbar. These interrupt lines are reserved in the soc,
>> +		 so crossbar bar driver should not consider them as free
>> +		 lines.
>> +
> ti,irqs-reserved
Ok, will correct
>> +Examples:
>> +		crossbar_mpu: @4a020000 {
> Did you mean for there to be a label and no node name?
>
 ya, name is missing. Will add.
>> +			compatible = "ti,irq-crossbar";
>> +			reg = <0x4a002a48 0x130>;
>> +			max-irqs = <160>;
>> +			reg-size = <2>;
>> +			irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>> +		};

Regards,
 Sricharan

Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP

[Kumar Gala]

On Oct 24, 2013, at 5:43 AM, Sricharan R wrote:

> Hi Kumar,
> 
> On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
>> On Sep 30, 2013, at 8:59 AM, Sricharan R wrote:
>> 
>>> Some socs have a large number of interrupts requests to service
>>> the needs of its many peripherals and subsystems. All of the
>>> interrupt lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the irq-controller appropriately.
>>> In such places a interrupt controllers are preceded by an CROSSBAR
>>> that provides flexibility in muxing the device requests to the controller
>>> inputs.
>>> 
>>> This driver takes care a allocating a free irq and then configuring the
>>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>>> be called right before the irqchip_init, so that it is setup to handle the
>>> irqchip callbacks.
>>> 
>>> 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>
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
>>> drivers/irqchip/Kconfig                            |    8 +
>>> drivers/irqchip/Makefile                           |    1 +
>>> drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
>>> include/linux/irqchip/irq-crossbar.h               |   11 ++
>>> 5 files changed, 242 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> create mode 100644 drivers/irqchip/irq-crossbar.c
>>> create mode 100644 include/linux/irqchip/irq-crossbar.h
>>> 
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..cdec2cd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,27 @@
>>> +Some socs have a large number of interrupts requests to service
>>> +the needs of its many peripherals and subsystems. All of the
>>> +interrupt lines from the subsystems are not needed at the same
>>> +time, so they have to be muxed to the irq-controller appropriately.
>>> +In such places a interrupt controllers are preceded by an CROSSBAR
>>> +that provides flexibility in muxing the device requests to the controller
>>> +inputs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,irq-crossbar"
>>> +- reg: Base address and the size of the crossbar registers.
>>> +- max-irqs: Total number of irqs available at the interrupt controller.
>> Should be 'ti,max-irqs
> Ok, will correct.
>>> +- reg-size: Size of a individual register in bytes. Every individual
>>> +	    register is assumed to be of same size. Valid sizes are 1, 2, 4.
>> Is this something that really needs to be encoded in the dts?
>> 
>> If we keep it should be ti,reg-size
> Currently, this is the only IP with a fixed register-size.
> So this can be in the driver also. I thought keeping it
> DT will avoid any hard-coding in driver.

I'd go with less in the DT at this point, if in the future you need this you can always add it later.

>>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>>> +		 crossbar. These interrupt lines are reserved in the soc,
>>> +		 so crossbar bar driver should not consider them as free
>>> +		 lines.
>>> +
>> ti,irqs-reserved
> Ok, will correct
>>> +Examples:
>>> +		crossbar_mpu: @4a020000 {
>> Did you mean for there to be a label and no node name?
>> 
> ya, name is missing. Will add.
>>> +			compatible = "ti,irq-crossbar";
>>> +			reg = <0x4a002a48 0x130>;
>>> +			max-irqs = <160>;
>>> +			reg-size = <2>;
>>> +			irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>>> +		};
> 
> Regards,
> Sricharan

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[RFC PATCH 3/6] ARM: DTS: DRA: Add crossbar device binding

[Sricharan R]

This adds the irq crossbar device node.

There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.

Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
 arch/arm/boot/dts/dra7.dtsi |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b35cb12..799b7be 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -492,5 +492,14 @@
 			dmas = <&sdma 70>, <&sdma 71>;
 			dma-names = "tx0", "rx0";
 		};
+
+		crossbar_mpu: @4a020000 {
+			compatible = "ti,irq-crossbar";
+			reg = <0x4a002a48 0x130>;
+			max-irqs = <160>;
+			reg-size = <2>;
+			irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+		};
+
 	};
 };
-- 
1.7.9.5

[RFC PATCH 4/6] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.

[Sricharan R]

Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.

Cc: Benoit Cousson <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
Cc: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Sricharan R <r.sricharan-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/dra7.dtsi |   88 +++++++++++++++++++++----------------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 799b7be..bef1c99 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
 		sdma: dma-controller@4a056000 {
 			compatible = "ti,omap4430-sdma";
 			reg = <0x4a056000 0x1000>;
-			interrupts = <0 12 0x4>,
-				     <0 13 0x4>,
-				     <0 14 0x4>,
-				     <0 15 0x4>;
+			interrupts = <0 7 0x4>,
+				     <0 8 0x4>,
+				     <0 9 0x4>,
+				     <0 10 0x4>;
 			#dma-cells = <1>;
 			#dma-channels = <32>;
 			#dma-requests = <127>;
@@ -116,7 +116,7 @@
 		gpio1: gpio@4ae10000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4ae10000 0x200>;
-			interrupts = <0 29 0x4>;
+			interrupts = <0 24 0x4>;
 			ti,hwmods = "gpio1";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -127,7 +127,7 @@
 		gpio2: gpio@48055000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x48055000 0x200>;
-			interrupts = <0 30 0x4>;
+			interrupts = <0 25 0x4>;
 			ti,hwmods = "gpio2";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -138,7 +138,7 @@
 		gpio3: gpio@48057000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x48057000 0x200>;
-			interrupts = <0 31 0x4>;
+			interrupts = <0 26 0x4>;
 			ti,hwmods = "gpio3";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -149,7 +149,7 @@
 		gpio4: gpio@48059000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x48059000 0x200>;
-			interrupts = <0 32 0x4>;
+			interrupts = <0 27 0x4>;
 			ti,hwmods = "gpio4";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -160,7 +160,7 @@
 		gpio5: gpio@4805b000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4805b000 0x200>;
-			interrupts = <0 33 0x4>;
+			interrupts = <0 28 0x4>;
 			ti,hwmods = "gpio5";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -171,7 +171,7 @@
 		gpio6: gpio@4805d000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4805d000 0x200>;
-			interrupts = <0 34 0x4>;
+			interrupts = <0 29 0x4>;
 			ti,hwmods = "gpio6";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -182,7 +182,7 @@
 		gpio7: gpio@48051000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x48051000 0x200>;
-			interrupts = <0 35 0x4>;
+			interrupts = <0 30 0x4>;
 			ti,hwmods = "gpio7";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -193,7 +193,7 @@
 		gpio8: gpio@48053000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x48053000 0x200>;
-			interrupts = <0 121 0x4>;
+			interrupts = <0 116 0x4>;
 			ti,hwmods = "gpio8";
 			gpio-controller;
 			#gpio-cells = <2>;
@@ -204,7 +204,7 @@
 		uart1: serial@4806a000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x4806a000 0x100>;
-			interrupts = <0 72 0x4>;
+			interrupts = <0 67 0x4>;
 			ti,hwmods = "uart1";
 			clock-frequency = <48000000>;
 		};
@@ -212,7 +212,7 @@
 		uart2: serial@4806c000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x4806c000 0x100>;
-			interrupts = <0 73 0x4>;
+			interrupts = <0 68 0x4>;
 			ti,hwmods = "uart2";
 			clock-frequency = <48000000>;
 		};
@@ -220,7 +220,7 @@
 		uart3: serial@48020000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x48020000 0x100>;
-			interrupts = <0 74 0x4>;
+			interrupts = <0 69 0x4>;
 			ti,hwmods = "uart3";
 			clock-frequency = <48000000>;
 		};
@@ -228,7 +228,7 @@
 		uart4: serial@4806e000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x4806e000 0x100>;
-			interrupts = <0 70 0x4>;
+			interrupts = <0 65 0x4>;
 			ti,hwmods = "uart4";
 			clock-frequency = <48000000>;
 		};
@@ -236,7 +236,7 @@
 		uart5: serial@48066000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x48066000 0x100>;
-			interrupts = <0 105 0x4>;
+			interrupts = <0 100 0x4>;
 			ti,hwmods = "uart5";
 			clock-frequency = <48000000>;
 		};
@@ -244,7 +244,7 @@
 		uart6: serial@48068000 {
 			compatible = "ti,omap4-uart";
 			reg = <0x48068000 0x100>;
-			interrupts = <0 106 0x4>;
+			interrupts = <0 101 0x4>;
 			ti,hwmods = "uart6";
 			clock-frequency = <48000000>;
 		};
@@ -252,7 +252,7 @@
 		timer1: timer@4ae18000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x4ae18000 0x80>;
-			interrupts = <0 37 0x4>;
+			interrupts = <0 32 0x4>;
 			ti,hwmods = "timer1";
 			ti,timer-alwon;
 		};
@@ -260,28 +260,28 @@
 		timer2: timer@48032000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48032000 0x80>;
-			interrupts = <0 38 0x4>;
+			interrupts = <0 33 0x4>;
 			ti,hwmods = "timer2";
 		};
 
 		timer3: timer@48034000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48034000 0x80>;
-			interrupts = <0 39 0x4>;
+			interrupts = <0 34 0x4>;
 			ti,hwmods = "timer3";
 		};
 
 		timer4: timer@48036000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48036000 0x80>;
-			interrupts = <0 40 0x4>;
+			interrupts = <0 35 0x4>;
 			ti,hwmods = "timer4";
 		};
 
 		timer5: timer@48820000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48820000 0x80>;
-			interrupts = <0 41 0x4>;
+			interrupts = <0 36 0x4>;
 			ti,hwmods = "timer5";
 			ti,timer-dsp;
 		};
@@ -289,7 +289,7 @@
 		timer6: timer@48822000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48822000 0x80>;
-			interrupts = <0 42 0x4>;
+			interrupts = <0 37 0x4>;
 			ti,hwmods = "timer6";
 			ti,timer-dsp;
 			ti,timer-pwm;
@@ -298,7 +298,7 @@
 		timer7: timer@48824000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48824000 0x80>;
-			interrupts = <0 43 0x4>;
+			interrupts = <0 38 0x4>;
 			ti,hwmods = "timer7";
 			ti,timer-dsp;
 		};
@@ -306,7 +306,7 @@
 		timer8: timer@48826000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48826000 0x80>;
-			interrupts = <0 44 0x4>;
+			interrupts = <0 39 0x4>;
 			ti,hwmods = "timer8";
 			ti,timer-dsp;
 			ti,timer-pwm;
@@ -315,21 +315,21 @@
 		timer9: timer@4803e000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x4803e000 0x80>;
-			interrupts = <0 45 0x4>;
+			interrupts = <0 40 0x4>;
 			ti,hwmods = "timer9";
 		};
 
 		timer10: timer@48086000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48086000 0x80>;
-			interrupts = <0 46 0x4>;
+			interrupts = <0 41 0x4>;
 			ti,hwmods = "timer10";
 		};
 
 		timer11: timer@48088000 {
 			compatible = "ti,omap5430-timer";
 			reg = <0x48088000 0x80>;
-			interrupts = <0 47 0x4>;
+			interrupts = <0 42 0x4>;
 			ti,hwmods = "timer11";
 			ti,timer-pwm;
 		};
@@ -337,21 +337,21 @@
 		wdt2: wdt@4ae14000 {
 			compatible = "ti,omap4-wdt";
 			reg = <0x4ae14000 0x80>;
-			interrupts = <0 80 0x4>;
+			interrupts = <0 75 0x4>;
 			ti,hwmods = "wd_timer2";
 		};
 
 		dmm: dmm@4e000000 {
 			compatible = "ti,omap5-dmm";
 			reg = <0x4e000000 0x800>;
-			interrupts = <0 113 0x4>;
+			interrupts = <0 108 0x4>;
 			ti,hwmods = "dmm";
 		};
 
 		i2c1: i2c@48070000 {
 			compatible = "ti,omap4-i2c";
 			reg = <0x48070000 0x100>;
-			interrupts = <0 56 0x4>;
+			interrupts = <0 51 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c1";
@@ -360,7 +360,7 @@
 		i2c2: i2c@48072000 {
 			compatible = "ti,omap4-i2c";
 			reg = <0x48072000 0x100>;
-			interrupts = <0 57 0x4>;
+			interrupts = <0 52 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c2";
@@ -369,7 +369,7 @@
 		i2c3: i2c@48060000 {
 			compatible = "ti,omap4-i2c";
 			reg = <0x48060000 0x100>;
-			interrupts = <0 61 0x4>;
+			interrupts = <0 56 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c3";
@@ -378,7 +378,7 @@
 		i2c4: i2c@4807a000 {
 			compatible = "ti,omap4-i2c";
 			reg = <0x4807a000 0x100>;
-			interrupts = <0 62 0x4>;
+			interrupts = <0 57 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c4";
@@ -387,7 +387,7 @@
 		i2c5: i2c@4807c000 {
 			compatible = "ti,omap4-i2c";
 			reg = <0x4807c000 0x100>;
-			interrupts = <0 60 0x4>;
+			interrupts = <0 55 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "i2c5";
@@ -396,7 +396,7 @@
 		mmc1: mmc@4809c000 {
 			compatible = "ti,omap4-hsmmc";
 			reg = <0x4809c000 0x400>;
-			interrupts = <0 83 0x4>;
+			interrupts = <0 78 0x4>;
 			ti,hwmods = "mmc1";
 			ti,dual-volt;
 			ti,needs-special-reset;
@@ -407,7 +407,7 @@
 		mmc2: mmc@480b4000 {
 			compatible = "ti,omap4-hsmmc";
 			reg = <0x480b4000 0x400>;
-			interrupts = <0 86 0x4>;
+			interrupts = <0 81 0x4>;
 			ti,hwmods = "mmc2";
 			ti,needs-special-reset;
 			dmas = <&sdma 47>, <&sdma 48>;
@@ -417,7 +417,7 @@
 		mmc3: mmc@480ad000 {
 			compatible = "ti,omap4-hsmmc";
 			reg = <0x480ad000 0x400>;
-			interrupts = <0 94 0x4>;
+			interrupts = <0 89 0x4>;
 			ti,hwmods = "mmc3";
 			ti,needs-special-reset;
 			dmas = <&sdma 77>, <&sdma 78>;
@@ -427,7 +427,7 @@
 		mmc4: mmc@480d1000 {
 			compatible = "ti,omap4-hsmmc";
 			reg = <0x480d1000 0x400>;
-			interrupts = <0 96 0x4>;
+			interrupts = <0 91 0x4>;
 			ti,hwmods = "mmc4";
 			ti,needs-special-reset;
 			dmas = <&sdma 57>, <&sdma 58>;
@@ -437,7 +437,7 @@
 		mcspi1: spi@48098000 {
 			compatible = "ti,omap4-mcspi";
 			reg = <0x48098000 0x200>;
-			interrupts = <0 65 0x4>;
+			interrupts = <0 60 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "mcspi1";
@@ -457,7 +457,7 @@
 		mcspi2: spi@4809a000 {
 			compatible = "ti,omap4-mcspi";
 			reg = <0x4809a000 0x200>;
-			interrupts = <0 66 0x4>;
+			interrupts = <0 61 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "mcspi2";
@@ -472,7 +472,7 @@
 		mcspi3: spi@480b8000 {
 			compatible = "ti,omap4-mcspi";
 			reg = <0x480b8000 0x200>;
-			interrupts = <0 91 0x4>;
+			interrupts = <0 86 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "mcspi3";
@@ -484,7 +484,7 @@
 		mcspi4: spi@480ba000 {
 			compatible = "ti,omap4-mcspi";
 			reg = <0x480ba000 0x200>;
-			interrupts = <0 48 0x4>;
+			interrupts = <0 43 0x4>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 			ti,hwmods = "mcspi4";
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Santosh Shilimkar]

On Monday 30 September 2013 09:59 AM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the interrupt
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt controllers are preceded by an
> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
> requests to the controller inputs.
> 
> This series models the peripheral interrupts that can be routed through
> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
> in a separate linear domain inside the GIC. The registered routable domain's
> callback are invoked as a part of the GIC's callback, which in turn should
> allocate a free irq line and configure the IP accordingly. So every peripheral
> in the dts files mentions the fixed crossbar number as its interrupt. A free
> gic line for that gets allocated and configured when the peripheral's interrupt
> is mapped.
> 
> The minimal crossbar driver to track and allocate free GIC lines and configure the
> crossbar is added here, along with the DT bindings.
> 
You should have references to the previous discussions so that its
easier for new reviewers to understand why you ended up the approach.
I noticed you missed this in your last posts as well.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 5/6] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number

[Sricharan R]

The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/omap-wakeupgen.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 4dc16c2c..244839c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -134,7 +134,7 @@ static void wakeupgen_mask(struct irq_data *d)
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&wakeupgen_lock, flags);
-	_wakeupgen_clear(d->irq, irq_target_cpu[d->irq]);
+	_wakeupgen_clear(d->hwirq, irq_target_cpu[d->hwirq]);
 	raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
 }
 
@@ -146,7 +146,7 @@ static void wakeupgen_unmask(struct irq_data *d)
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&wakeupgen_lock, flags);
-	_wakeupgen_set(d->irq, irq_target_cpu[d->irq]);
+	_wakeupgen_set(d->hwirq, irq_target_cpu[d->hwirq]);
 	raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
 }
 
-- 
1.7.9.5

[RFC PATCH 6/6] ARM: DRA: Enable Crossbar IP support for DRA7XX

[Sricharan R]

Enable the crossbar IP support for DRA7xx soc.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/Kconfig        |    1 +
 arch/arm/mach-omap2/omap4-common.c |    4 ++++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..10ec40c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
 	select ARM_GIC
 	select HAVE_SMP
 	select COMMON_CLK
+	select IRQ_CROSSBAR
 
 comment "OMAP Core Type"
 	depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index adbe86b..4692f1c 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -22,6 +22,7 @@
 #include <linux/of_platform.h>
 #include <linux/export.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/irq-crossbar.h>
 #include <linux/of_address.h>
 
 #include <asm/hardware/cache-l2x0.h>
@@ -287,9 +288,12 @@ void __init omap_gic_of_init(void)
 
 skip_errata_init:
 	omap_wakeupgen_init();
+	if (soc_is_dra7xx())
+		crossbar_init();
 	irqchip_init();
 }
 
+
 #if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 static int omap4_twl6030_hsmmc_late_init(struct device *dev)
 {
-- 
1.7.9.5

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Rob Herring]

On 09/30/2013 08:59 AM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the interrupt
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers appropriately.
> In such places a interrupt controllers are preceded by an
> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
> requests to the controller inputs.
> 
> This series models the peripheral interrupts that can be routed through
> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
> in a separate linear domain inside the GIC. The registered routable domain's
> callback are invoked as a part of the GIC's callback, which in turn should
> allocate a free irq line and configure the IP accordingly. So every peripheral
> in the dts files mentions the fixed crossbar number as its interrupt. A free
> gic line for that gets allocated and configured when the peripheral's interrupt
> is mapped.
> 
> The minimal crossbar driver to track and allocate free GIC lines and configure the
> crossbar is added here, along with the DT bindings.

Seems like interrupt-map property is what you need here.

http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping

Versatile Express also has an example.

Rob

> 
> Sricharan R (6):
>   DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
>   DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
>   ARM: DTS: DRA: Add crossbar device binding
>   ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar
>     inputs.
>   ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
>   ARM: DRA: Enable Crossbar IP support for DRA7XX
> 
>  Documentation/devicetree/bindings/arm/gic.txt      |    5 +
>  .../devicetree/bindings/arm/omap/crossbar.txt      |   27 +++
>  arch/arm/boot/dts/dra7.dtsi                        |   98 +++++-----
>  arch/arm/mach-omap2/Kconfig                        |    1 +
>  arch/arm/mach-omap2/omap-wakeupgen.c               |    4 +-
>  arch/arm/mach-omap2/omap4-common.c                 |    4 +
>  drivers/irqchip/Kconfig                            |    8 +
>  drivers/irqchip/Makefile                           |    1 +
>  drivers/irqchip/irq-crossbar.c                     |  195 ++++++++++++++++++++
>  drivers/irqchip/irq-gic.c                          |   57 +++++-
>  include/linux/irqchip/arm-gic.h                    |    8 +-
>  include/linux/irqchip/irq-crossbar.h               |   11 ++
>  12 files changed, 363 insertions(+), 56 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>  create mode 100644 drivers/irqchip/irq-crossbar.c
>  create mode 100644 include/linux/irqchip/irq-crossbar.h
> 

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Sricharan R]

Hi,

On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
> On 09/30/2013 08:59 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts requests to service
>> the needs of its many peripherals and subsystems. All of the interrupt
>> requests lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the controllers appropriately.
>> In such places a interrupt controllers are preceded by an
>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>> requests to the controller inputs.
>>
>> This series models the peripheral interrupts that can be routed through
>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>> in a separate linear domain inside the GIC. The registered routable domain's
>> callback are invoked as a part of the GIC's callback, which in turn should
>> allocate a free irq line and configure the IP accordingly. So every peripheral
>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>> gic line for that gets allocated and configured when the peripheral's interrupt
>> is mapped.
>>
>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>> crossbar is added here, along with the DT bindings.
> Seems like interrupt-map property is what you need here.
>
> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>
> Versatile Express also has an example.
   OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
   DTS level, but to assign it dynamically during runtime. This was one of the
  comments that came up with first crossbar support patches, which was assigning a
  interrupt line to crossbar number in the DTS and setting it up in crossbar probe.

    https://lkml.org/lkml/2013/7/18/416

   Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
   that did not go as well. Finally was asked to handle this as a part of GIC driver with
   a separate domain.
   
  http://www.spinics.net/lists/linux-omap/msg97085.html
  
Regards,
 Sricharan

 

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Rob Herring]

On 10/01/2013 06:13 AM, Sricharan R wrote:
> Hi,
> 
> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>> Some socs have a large number of interrupts requests to service
>>> the needs of its many peripherals and subsystems. All of the interrupt
>>> requests lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the controllers appropriately.
>>> In such places a interrupt controllers are preceded by an
>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>> requests to the controller inputs.
>>>
>>> This series models the peripheral interrupts that can be routed through
>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>> in a separate linear domain inside the GIC. The registered routable domain's
>>> callback are invoked as a part of the GIC's callback, which in turn should
>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>> is mapped.
>>>
>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>> crossbar is added here, along with the DT bindings.
>> Seems like interrupt-map property is what you need here.
>>
>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>
>> Versatile Express also has an example.
>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>    DTS level, but to assign it dynamically during runtime. This was one of the
>   comments that came up with first crossbar support patches, which was assigning a
>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.

Is there an actual usecase on a single h/w design that you run out of
interrupts and it is a user decision which interrupts to use?

You could fill in the interrupt-map at run-time. It would have to be
early (bootloader or early kernel init) and can't be at request_irq time.

>     https://lkml.org/lkml/2013/7/18/416
> 
>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>    a separate domain.
>    
>   http://www.spinics.net/lists/linux-omap/msg97085.html

This has nothing to do with the GIC, so it does not belong there.

Rob

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Santosh Shilimkar]

On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
> On 10/01/2013 06:13 AM, Sricharan R wrote:
>> Hi,
>>
>> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>>> Some socs have a large number of interrupts requests to service
>>>> the needs of its many peripherals and subsystems. All of the interrupt
>>>> requests lines from the subsystems are not needed at the same
>>>> time, so they have to be muxed to the controllers appropriately.
>>>> In such places a interrupt controllers are preceded by an
>>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>>> requests to the controller inputs.
>>>>
>>>> This series models the peripheral interrupts that can be routed through
>>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>>> in a separate linear domain inside the GIC. The registered routable domain's
>>>> callback are invoked as a part of the GIC's callback, which in turn should
>>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>>> is mapped.
>>>>
>>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>>> crossbar is added here, along with the DT bindings.
>>> Seems like interrupt-map property is what you need here.
>>>
>>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>>
>>> Versatile Express also has an example.
>>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>>    DTS level, but to assign it dynamically during runtime. This was one of the
>>   comments that came up with first crossbar support patches, which was assigning a
>>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.
> 
> Is there an actual usecase on a single h/w design that you run out of
> interrupts and it is a user decision which interrupts to use?
>
Yes. There are 240 peripheral interrupts connected out of which 160 can
be used in this specific case. 
 
> You could fill in the interrupt-map at run-time. It would have to be
> early (bootloader or early kernel init) and can't be at request_irq time.
>
Well all options are tried before coming up to the $subject solution.
It was suggested by Thomas in the last review.
 
>>     https://lkml.org/lkml/2013/7/18/416
>>
>>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>>    a separate domain.
>>    
>>   http://www.spinics.net/lists/linux-omap/msg97085.html
> 
> This has nothing to do with the GIC, so it does not belong there.
> 
Well the router makes connections from peripheral to GIC. Thomas can
better explain it but I think since its doing irq routing for GIC on
a given hardware, I don't see any issue having some generic map/unmap
function in GIC. The actual implementation is still outside of GIC.

Regards,
Sasntosh

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Rob Herring]

On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
>> On 10/01/2013 06:13 AM, Sricharan R wrote:
>>> Hi,
>>>
>>> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>>>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>>>> Some socs have a large number of interrupts requests to service
>>>>> the needs of its many peripherals and subsystems. All of the interrupt
>>>>> requests lines from the subsystems are not needed at the same
>>>>> time, so they have to be muxed to the controllers appropriately.
>>>>> In such places a interrupt controllers are preceded by an
>>>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>>>> requests to the controller inputs.
>>>>>
>>>>> This series models the peripheral interrupts that can be routed through
>>>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>>>> in a separate linear domain inside the GIC. The registered routable domain's
>>>>> callback are invoked as a part of the GIC's callback, which in turn should
>>>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>>>> is mapped.
>>>>>
>>>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>>>> crossbar is added here, along with the DT bindings.
>>>> Seems like interrupt-map property is what you need here.
>>>>
>>>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>>>
>>>> Versatile Express also has an example.
>>>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>>>    DTS level, but to assign it dynamically during runtime. This was one of the
>>>   comments that came up with first crossbar support patches, which was assigning a
>>>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.
>>
>> Is there an actual usecase on a single h/w design that you run out of
>> interrupts and it is a user decision which interrupts to use?
>>
> Yes. There are 240 peripheral interrupts connected out of which 160 can
> be used in this specific case. 

Yes, I understand the SOC connections. That does not answer my question.
The 240 interrupts are likely to be limited to fewer by board design,
pinmuxing, etc.

How do you handle the 161st interrupt request? Will never happen? Just
rely on the random driver probe ordering?

>> You could fill in the interrupt-map at run-time. It would have to be
>> early (bootloader or early kernel init) and can't be at request_irq time.
>>
> Well all options are tried before coming up to the $subject solution.
> It was suggested by Thomas in the last review.
>  
>>>     https://lkml.org/lkml/2013/7/18/416
>>>
>>>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>>>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>>>    a separate domain.
>>>    
>>>   http://www.spinics.net/lists/linux-omap/msg97085.html
>>
>> This has nothing to do with the GIC, so it does not belong there.
>>
> Well the router makes connections from peripheral to GIC. Thomas can
> better explain it but I think since its doing irq routing for GIC on
> a given hardware, I don't see any issue having some generic map/unmap
> function in GIC. The actual implementation is still outside of GIC.

I read Thomas' reply as don't put this crap in his code.

You can call it generic, but it is not. It is specific to the GIC and
looks like an abuse of irqdomains to me. Look where the function
declaration for register_routable_domain_ops is.

Rob

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Santosh Shilimkar]

On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote:
> On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
>> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
>>> On 10/01/2013 06:13 AM, Sricharan R wrote:
>>>> Hi,
>>>>
>>>> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>>>>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>>>>> Some socs have a large number of interrupts requests to service
>>>>>> the needs of its many peripherals and subsystems. All of the interrupt
>>>>>> requests lines from the subsystems are not needed at the same
>>>>>> time, so they have to be muxed to the controllers appropriately.
>>>>>> In such places a interrupt controllers are preceded by an
>>>>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>>>>> requests to the controller inputs.
>>>>>>
>>>>>> This series models the peripheral interrupts that can be routed through
>>>>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>>>>> in a separate linear domain inside the GIC. The registered routable domain's
>>>>>> callback are invoked as a part of the GIC's callback, which in turn should
>>>>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>>>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>>>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>>>>> is mapped.
>>>>>>
>>>>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>>>>> crossbar is added here, along with the DT bindings.
>>>>> Seems like interrupt-map property is what you need here.
>>>>>
>>>>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>>>>
>>>>> Versatile Express also has an example.
>>>>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>>>>    DTS level, but to assign it dynamically during runtime. This was one of the
>>>>   comments that came up with first crossbar support patches, which was assigning a
>>>>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.
>>>
>>> Is there an actual usecase on a single h/w design that you run out of
>>> interrupts and it is a user decision which interrupts to use?
>>>
>> Yes. There are 240 peripheral interrupts connected out of which 160 can
>> be used in this specific case. 
> 
> Yes, I understand the SOC connections. That does not answer my question.
> The 240 interrupts are likely to be limited to fewer by board design,
> pinmuxing, etc.
> 
yes limited by different board designs ...

> How do you handle the 161st interrupt request? Will never happen? Just
> rely on the random driver probe ordering?
>
Well the board dts are expected to provide the peripheral support info to optimise it.
If a board actually has more than 160 peripherals available then in that
case the 161 interrupt will not be mapped. 
 
>>> You could fill in the interrupt-map at run-time. It would have to be
>>> early (bootloader or early kernel init) and can't be at request_irq time.
>>>
>> Well all options are tried before coming up to the $subject solution.
>> It was suggested by Thomas in the last review.
>>  
>>>>     https://lkml.org/lkml/2013/7/18/416
>>>>
>>>>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>>>>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>>>>    a separate domain.
>>>>    
>>>>   http://www.spinics.net/lists/linux-omap/msg97085.html
>>>
>>> This has nothing to do with the GIC, so it does not belong there.
>>>
>> Well the router makes connections from peripheral to GIC. Thomas can
>> better explain it but I think since its doing irq routing for GIC on
>> a given hardware, I don't see any issue having some generic map/unmap
>> function in GIC. The actual implementation is still outside of GIC.
> 
> I read Thomas' reply as don't put this crap in his code.
>
That was for the IRQCHIP based approach and as part of that review
Thomas suggested why not irqdomain and suggested a prototype code
as well.
 
> You can call it generic, but it is not. It is specific to the GIC and
> looks like an abuse of irqdomains to me. Look where the function
> declaration for register_routable_domain_ops is.
> 
I am not sure why you call it abuse of irqdomain since the map/unmap
are exactly the interfaces where the logical to physical irq
connections are made. Look at existing GIC code as well. I still
let Thomas give his expert comment whether it is abusive because it
it was, am sure he wouldn't have suggested that.

Now if your concern is the register_routable_domain_ops() then
we are open to hear if there is any better way to do that. Thats
why the series is still RFC.

Regards,
Santosh

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Sricharan R]

Hi Thomas,

On Tuesday 01 October 2013 08:37 PM, Santosh Shilimkar wrote:
> On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote:
>> On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
>>> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
>>>> On 10/01/2013 06:13 AM, Sricharan R wrote:
>>>>> Hi,
>>>>>
>>>>> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>>>>>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>>>>>> Some socs have a large number of interrupts requests to service
>>>>>>> the needs of its many peripherals and subsystems. All of the interrupt
>>>>>>> requests lines from the subsystems are not needed at the same
>>>>>>> time, so they have to be muxed to the controllers appropriately.
>>>>>>> In such places a interrupt controllers are preceded by an
>>>>>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>>>>>> requests to the controller inputs.
>>>>>>>
>>>>>>> This series models the peripheral interrupts that can be routed through
>>>>>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>>>>>> in a separate linear domain inside the GIC. The registered routable domain's
>>>>>>> callback are invoked as a part of the GIC's callback, which in turn should
>>>>>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>>>>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>>>>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>>>>>> is mapped.
>>>>>>>
>>>>>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>>>>>> crossbar is added here, along with the DT bindings.
>>>>>> Seems like interrupt-map property is what you need here.
>>>>>>
>>>>>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>>>>>
>>>>>> Versatile Express also has an example.
>>>>>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>>>>>    DTS level, but to assign it dynamically during runtime. This was one of the
>>>>>   comments that came up with first crossbar support patches, which was assigning a
>>>>>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.
>>>> Is there an actual usecase on a single h/w design that you run out of
>>>> interrupts and it is a user decision which interrupts to use?
>>>>
>>> Yes. There are 240 peripheral interrupts connected out of which 160 can
>>> be used in this specific case. 
>> Yes, I understand the SOC connections. That does not answer my question.
>> The 240 interrupts are likely to be limited to fewer by board design,
>> pinmuxing, etc.
>>
> yes limited by different board designs ...
>
>> How do you handle the 161st interrupt request? Will never happen? Just
>> rely on the random driver probe ordering?
>>
> Well the board dts are expected to provide the peripheral support info to optimise it.
> If a board actually has more than 160 peripherals available then in that
> case the 161 interrupt will not be mapped. 
>  
>>>> You could fill in the interrupt-map at run-time. It would have to be
>>>> early (bootloader or early kernel init) and can't be at request_irq time.
>>>>
>>> Well all options are tried before coming up to the $subject solution.
>>> It was suggested by Thomas in the last review.
>>>  
>>>>>     https://lkml.org/lkml/2013/7/18/416
>>>>>
>>>>>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>>>>>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>>>>>    a separate domain.
>>>>>    
>>>>>   http://www.spinics.net/lists/linux-omap/msg97085.html
>>>> This has nothing to do with the GIC, so it does not belong there.
>>>>
>>> Well the router makes connections from peripheral to GIC. Thomas can
>>> better explain it but I think since its doing irq routing for GIC on
>>> a given hardware, I don't see any issue having some generic map/unmap
>>> function in GIC. The actual implementation is still outside of GIC.
>> I read Thomas' reply as don't put this crap in his code.
>>
> That was for the IRQCHIP based approach and as part of that review
> Thomas suggested why not irqdomain and suggested a prototype code
> as well.
>  
>> You can call it generic, but it is not. It is specific to the GIC and
>> looks like an abuse of irqdomains to me. Look where the function
>> declaration for register_routable_domain_ops is.
>>
> I am not sure why you call it abuse of irqdomain since the map/unmap
> are exactly the interfaces where the logical to physical irq
> connections are made. Look at existing GIC code as well. I still
> let Thomas give his expert comment whether it is abusive because it
> it was, am sure he wouldn't have suggested that.
  Is this inline with what you were suggesting and
  is this approach fine ?

Regards,
 Sricharan

Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

[Thomas Gleixner]

On Tue, 1 Oct 2013, Rob Herring wrote:
> On 10/01/2013 06:13 AM, Sricharan R wrote:
> 
> Is there an actual usecase on a single h/w design that you run out of
> interrupts and it is a user decision which interrupts to use?

I don't think that matters. What matters is that you have a single DT
entry which tells the driver which crossbar irq to use for that
particular device. And that is the only information which is relevant
because the IP block is connected to a crossbar input and not to a GIC
line. The crossbar provides the mapping and this is really best done
at runtime w/o having hardcoded information in the DT or at some other
place.
 
> You could fill in the interrupt-map at run-time. It would have to be
> early (bootloader or early kernel init) and can't be at request_irq time.

How is that supposed to work when you have no idea at early boot time
which particular IP blocks are going to be used later on?

> >   http://www.spinics.net/lists/linux-omap/msg97085.html
> 
> This has nothing to do with the GIC, so it does not belong there.

Errm. crossbar is a mapping device which happens to sit between the
GIC and the IP blocks. So how is this NOT related to GIC ?

Thanks,

	tglx