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

[Michal Simek]

On 15.11.2016 17:03, Zubair Lutfullah Kakakhel wrote:
> Hi,
> 
> On 11/15/2016 12:49 PM, Michal Simek wrote:
>> On 14.11.2016 13:13, Zubair Lutfullah Kakakhel wrote:
>>> Add a global structure to house various variables.
>>> And cleanup read/write handling by using jump label api.
>>>
>>> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel at imgtec.com>
>>>
> 
> ...
> 
>>> @@ -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 <michal.simek at xilinx.com>

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

Thanks,
Michal