Re: [Patch v7 3/7] irqchip: xilinx: restructure and use jump label api

On 15.11.2016 17:03, Zubair Lutfullah Kakakhel wrote:

Hi,

On 11/15/2016 12:49 PM, Michal Simek wrote:

quoted

On 14.11.2016 13:13, Zubair Lutfullah Kakakhel wrote:

quoted

Add a global structure to house various variables.
And cleanup read/write handling by using jump label api.

Signed-off-by: Zubair Lutfullah Kakakhel <redacted>

...

quoted

quoted

@@ -138,59 +136,75 @@ static const struct irq_domain_ops

xintc_irq_domain_ops = {
 static int __init xilinx_intc_of_init(struct device_node *intc,
                          struct device_node *parent)
 {
-    u32 nr_irq, intr_mask;
+    u32 nr_irq;
     int ret;
+    struct xintc_irq_chip *irqc;

-    intc_baseaddr = of_iomap(intc, 0);
-    BUG_ON(!intc_baseaddr);
+    if (xintc_irqc) {
+        pr_err("irq-xilinx: Multiple instances aren't supported\n");
+        return -EINVAL;
+    }

I don't agree with this.
Pretty long time ago we were added support for multiple instances in
xilinx private tree.
You can look here.

https://github.com/Xilinx/linux-xlnx/blob/master/drivers/irqchip/irq-xilinx-intc.c


Not sure if this the latest way how to do it but as you can see
we were setting up
irq_set_handler_data(irq, intc);

and then when you need that structure we were calling
struct intc *local_intc = irq_data_get_irq_chip_data(d);

And that should be it to support multiple instance of this driver.

Based on 5/7 you are describing your interrupt subsystem like this.

Peripherals --> xilinx_intcontroller -> mips_cpu_int controller
If mips_cpu_int has more than one input you can connect more xilinx intc
controllers.
If not you still have an option to connect
xilinx_intcontroller(up to 32 peripherals) -> xilinx_intcontroller(one
intc + up to 31 peripherals)  -> mips_cpu_int controller

That configuration in FPGA is technically possible. Although not
done/needed in the
way we use the Xilinx Interrupt Controller IP block in MIPSfpga.

This series takes the drivers out of arch code and makes it accessible.
Any further development on the driver would be common to all architectures.
Support for multiple instances would be a 'new feature'.

I say this as this series keeps growing and mutating in terms of its scope
and work.

fair enough - it can be added in separate patch.

Would it be possible to ack this so that the restructure out of arch code
can move forward?

I have tested the whole series on Microblaze and I can't see any problem
in running it there.

That's why
Tested-by; Michal Simek [off-list ref]

If everything is right needs to be checked by irqchip experts.

Thanks,
Michal