Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar

[Jason Cooper]

On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
> Hi Jason,
> 
> On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
> > On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
> >> From: Nishanth Menon <nm@xxxxxx>
> >>
> >> When, in the system due to varied reasons, interrupts might be unusable
> >> due to hardware behavior, but register maps do exist, then those interrupts
> >> should be skipped while mapping irq to crossbars.
> >>
> >> Signed-off-by: Nishanth Menon <nm@xxxxxx>
> >> Signed-off-by: Sricharan R <r.sricharan@xxxxxx>
> >> Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> > 
> > Tony, have you applied these somewhere already?
> > 
> >> ---
> >>  drivers/irqchip/irq-crossbar.c |   47 ++++++++++++++++++++++++++++++++++++----
> >>  1 file changed, 43 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> >> index 51d4b87..847f6e3 100644
> >> --- a/drivers/irqchip/irq-crossbar.c
> >> +++ b/drivers/irqchip/irq-crossbar.c
> >> @@ -13,11 +13,13 @@
> >>  #include <linux/io.h>
> >>  #include <linux/of_address.h>
> >>  #include <linux/of_irq.h>
> >> +#include <linux/of_device.h>
> >>  #include <linux/slab.h>
> >>  #include <linux/irqchip/arm-gic.h>
> >>  
> >>  #define IRQ_FREE	-1
> >>  #define IRQ_RESERVED	-2
> >> +#define IRQ_SKIP	-3
> >>  #define GIC_IRQ_START	32
> >>  
> >>  /*
> >> @@ -34,6 +36,16 @@ struct crossbar_device {
> >>  	void (*write) (int, int);
> >>  };
> >>  
> >> +/**
> >> + * struct crossbar_data: Platform specific data
> >> + * @irqs_unused: array of irqs that cannot be used because of hw erratas
> >> + * @size: size of the irqs_unused array
> >> + */
> >> +struct crossbar_data {
> >> +	const uint *irqs_unused;
> >> +	const uint size;
> >> +};
> >> +
> >>  static struct crossbar_device *cb;
> >>  
> >>  static inline void crossbar_writel(int irq_no, int cb_no)
> >> @@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops = {
> >>  	.xlate = crossbar_domain_xlate
> >>  };
> >>  
> >> -static int __init crossbar_of_init(struct device_node *node)
> >> +static int __init crossbar_of_init(struct device_node *node,
> >> +				   const struct crossbar_data *data)
> >>  {
> >>  	int i, size, max, reserved = 0, entry;
> >>  	const __be32 *irqsr;
> >> +	const int *irqsk = NULL;
> >>  
> >>  	cb = kzalloc(sizeof(*cb), GFP_KERNEL);
> >>  
> >> @@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node *node)
> >>  		reserved += size;
> >>  	}
> >>  
> >> +	/* Skip the ones marked as unused */
> >> +	if (data) {
> >> +		irqsk = data->irqs_unused;
> >> +		size = data->size;
> >> +
> >> +		for (i = 0; i < size; i++) {
> >> +			entry = irqsk[i];
> >> +
> >> +			if (entry > max) {
> >> +				pr_err("Invalid skip entry\n");
> >> +				goto err3;
> >> +			}
> >> +			cb->irq_map[entry] = IRQ_SKIP;
> >> +		}
> >> +	}
> >> +
> >>  	register_routable_domain_ops(&routable_irq_domain_ops);
> >>  	return 0;
> >>  
> >> @@ -208,18 +238,27 @@ err1:
> >>  	return -ENOMEM;
> >>  }
> >>  
> >> +/* irq number 10 cannot be used because of hw bug */
> >> +int dra_irqs_unused[] = { 10 };
> >> +struct crossbar_data cb_dra_data = { dra_irqs_unused,
> >> +				     ARRAY_SIZE(dra_irqs_unused) };
> >> +
> >>  static const struct of_device_id crossbar_match[] __initconst = {
> >> -	{ .compatible = "ti,irq-crossbar" },
> >> +	{ .compatible = "ti,irq-crossbar", .data = &cb_dra_data },
> >>  	{}
> >>  };
> > 
> > This is a bug in all implementations of this IP?  Or, a specific
> > SoC's implementation?  Would this be better expressed in the dts via a
> > property?  Can we expect future implementations to be fixed?
> > 
> > thx,
> > 
> > Jason.
>  Infact this and PATCH#10 should be merged. I will change that.
> 
>  So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
>  through a crossbar and some are directly wired to the irqchip.
>  These 'unused irqs' are those which are directly wired but they still
>  have a crossbar register. Their routing cannot be changed. So this
>  is not really expected usage of the crossbar hw ip. We initially thought
>  having a dts property separately for this, but took this path to avoid
>  loading the dts with additional bindings which may not be generic.

How do you plan to handle future SoCs with this IP and possibly
different hard-wired irqs?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/