Re: [tip: irq/core] irqchip/xilinx: Enable generic irq multi handler

[Michal Simek]

On 30. 03. 20 10:45, Marc Zyngier wrote:
> On 2020-03-30 09:32, Michal Simek wrote:
>> Hi Thomas and Marc,
>>
>> On 29. 03. 20 22:26, tip-bot2 for Michal Simek wrote:
>>> The following commit has been merged into the irq/core branch of tip:
>>>
>>> Commit-ID:ÂÂÂÂ a0789993bf8266e62fea6b4613945ba081c71e7d
>>> Gitweb:ÂÂÂÂÂÂÂ
>>> https://git.kernel.org/tip/a0789993bf8266e62fea6b4613945ba081c71e7d
>>> Author:ÂÂÂÂÂÂÂ Michal Simek <michal.simek@xxxxxxxxxx>
>>> AuthorDate:ÂÂÂ Tue, 17 Mar 2020 18:25:59 +05:30
>>> Committer:ÂÂÂÂ Marc Zyngier <maz@xxxxxxxxxx>
>>> CommitterDate: Sun, 22 Mar 2020 11:52:53
>>>
>>> irqchip/xilinx: Enable generic irq multi handler
>>>
>>> Register default arch handler via driver instead of directly pointing to
>>> xilinx intc controller. This patch makes architecture code more generic.
>>>
>>> Driver calls generic domain specific irq handler which does the most of
>>> things self. Also get rid of concurrent_irq counting which hasn't been
>>> exported anywhere.
>>> Based on this loop was also optimized by using do/while loop instead of
>>> goto loop.
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx>
>>> Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
>>> Reviewed-by: Stefan Asserhall <stefan.asserhall@xxxxxxxxxx>
>>> Link:
>>> https://lore.kernel.org/r/20200317125600.15913-4-mubin.usman.sayyed@xxxxxxxxxx
>>>
>>> ---
>>> Âarch/microblaze/KconfigÂÂÂÂÂÂÂÂÂÂ |Â 2 ++-
>>> Âarch/microblaze/include/asm/irq.h |Â 3 +---
>>> Âarch/microblaze/kernel/irq.cÂÂÂÂÂ | 21 +-------------------
>>> Âdrivers/irqchip/irq-xilinx-intc.c | 34 +++++++++++++++++-------------
>>> Â4 files changed, 23 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
>>> index 6a331bd..242f58e 100644
>>> --- a/arch/microblaze/Kconfig
>>> +++ b/arch/microblaze/Kconfig
>>> @@ -47,6 +47,8 @@ config MICROBLAZE
>>> ÂÂÂÂ select CPU_NO_EFFICIENT_FFS
>>> ÂÂÂÂ select MMU_GATHER_NO_RANGE if MMU
>>> ÂÂÂÂ select SPARSE_IRQ
>>> +ÂÂÂ select GENERIC_IRQ_MULTI_HANDLER
>>> +ÂÂÂ select HANDLE_DOMAIN_IRQ
>>>
>>> Â# Endianness selection
>>> Âchoice
>>> diff --git a/arch/microblaze/include/asm/irq.h
>>> b/arch/microblaze/include/asm/irq.h
>>> index eac2fb4..5166f08 100644
>>> --- a/arch/microblaze/include/asm/irq.h
>>> +++ b/arch/microblaze/include/asm/irq.h
>>> @@ -14,7 +14,4 @@
>>> Âstruct pt_regs;
>>> Âextern void do_IRQ(struct pt_regs *regs);
>>>
>>> -/* should be defined in each interrupt controller driver */
>>> -extern unsigned int xintc_get_irq(void);
>>> -
>>> Â#endif /* _ASM_MICROBLAZE_IRQ_H */
>>> diff --git a/arch/microblaze/kernel/irq.c b/arch/microblaze/kernel/irq.c
>>> index 903dad8..0b37dde 100644
>>> --- a/arch/microblaze/kernel/irq.c
>>> +++ b/arch/microblaze/kernel/irq.c
>>> @@ -20,29 +20,10 @@
>>> Â#include <linux/irqchip.h>
>>> Â#include <linux/of_irq.h>
>>>
>>> -static u32 concurrent_irq;
>>> -
>>> Âvoid __irq_entry do_IRQ(struct pt_regs *regs)
>>> Â{
>>> -ÂÂÂ unsigned int irq;
>>> -ÂÂÂ struct pt_regs *old_regs = set_irq_regs(regs);
>>> ÂÂÂÂ trace_hardirqs_off();
>>> -
>>> -ÂÂÂ irq_enter();
>>> -ÂÂÂ irq = xintc_get_irq();
>>> -next_irq:
>>> -ÂÂÂ BUG_ON(!irq);
>>> -ÂÂÂ generic_handle_irq(irq);
>>> -
>>> -ÂÂÂ irq = xintc_get_irq();
>>> -ÂÂÂ if (irq != -1U) {
>>> -ÂÂÂÂÂÂÂ pr_debug("next irq: %d\n", irq);
>>> -ÂÂÂÂÂÂÂ ++concurrent_irq;
>>> -ÂÂÂÂÂÂÂ goto next_irq;
>>> -ÂÂÂ }
>>> -
>>> -ÂÂÂ irq_exit();
>>> -ÂÂÂ set_irq_regs(old_regs);
>>> +ÂÂÂ handle_arch_irq(regs);
>>> ÂÂÂÂ trace_hardirqs_on();
>>> Â}
>>>
>>> diff --git a/drivers/irqchip/irq-xilinx-intc.c
>>> b/drivers/irqchip/irq-xilinx-intc.c
>>> index 1d3d273..ea74181 100644
>>> --- a/drivers/irqchip/irq-xilinx-intc.c
>>> +++ b/drivers/irqchip/irq-xilinx-intc.c
>>> @@ -124,20 +124,6 @@ static unsigned int xintc_get_irq_local(struct
>>> xintc_irq_chip *irqc)
>>> ÂÂÂÂ return irq;
>>> Â}
>>>
>>> -unsigned int xintc_get_irq(void)
>>> -{
>>> -ÂÂÂ unsigned int irq = -1;
>>> -ÂÂÂ u32 hwirq;
>>> -
>>> -ÂÂÂ hwirq = xintc_read(primary_intc, IVR);
>>> -ÂÂÂ if (hwirq != -1U)
>>> -ÂÂÂÂÂÂÂ irq = irq_find_mapping(primary_intc->root_domain, hwirq);
>>> -
>>> -ÂÂÂ pr_debug("irq-xilinx: hwirq=%d, irq=%d\n", hwirq, irq);
>>> -
>>> -ÂÂÂ return irq;
>>> -}
>>> -
>>> Âstatic int xintc_map(struct irq_domain *d, unsigned int irq,
>>> irq_hw_number_t hw)
>>> Â{
>>> ÂÂÂÂ struct xintc_irq_chip *irqc = d->host_data;
>>> @@ -177,6 +163,25 @@ static void xil_intc_irq_handler(struct irq_desc
>>> *desc)
>>> ÂÂÂÂ chained_irq_exit(chip, desc);
>>> Â}
>>>
>>> +static void xil_intc_handle_irq(struct pt_regs *regs)
>>> +{
>>> +ÂÂÂ u32 hwirq;
>>> +ÂÂÂ struct xintc_irq_chip *irqc = primary_intc;
>>> +
>>> +ÂÂÂ do {
>>> +ÂÂÂÂÂÂÂ hwirq = xintc_read(irqc, IVR);
>>> +ÂÂÂÂÂÂÂ if (likely(hwirq != -1U)) {
>>> +ÂÂÂÂÂÂÂÂÂÂÂ int ret;
>>> +
>>> +ÂÂÂÂÂÂÂÂÂÂÂ ret = handle_domain_irq(irqc->root_domain, hwirq, regs);
>>> +ÂÂÂÂÂÂÂÂÂÂÂ WARN_ONCE(ret, "Unhandled HWIRQ %d\n", hwirq);
>>> +ÂÂÂÂÂÂÂÂÂÂÂ continue;
>>> +ÂÂÂÂÂÂÂ }
>>> +
>>> +ÂÂÂÂÂÂÂ break;
>>> +ÂÂÂ } while (1);
>>> +}
>>> +
>>> Âstatic int __init xilinx_intc_of_init(struct device_node *intc,
>>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ struct device_node *parent)
>>> Â{
>>> @@ -246,6 +251,7 @@ static int __init xilinx_intc_of_init(struct
>>> device_node *intc,
>>> ÂÂÂÂ } else {
>>> ÂÂÂÂÂÂÂÂ primary_intc = irqc;
>>> ÂÂÂÂÂÂÂÂ irq_set_default_host(primary_intc->root_domain);
>>> +ÂÂÂÂÂÂÂ set_handle_irq(xil_intc_handle_irq);
>>> ÂÂÂÂ }
>>>
>>> ÂÂÂÂ return 0;
>>>
>>
>> Stephen reported compilation issue when this patch is applied because of
>> removal of xintc_get_irq() which is also used by ancient ppc405/ppc440
>> xilinx platforms. I have reported this twice to Marc already last week.
> 
> Did you? I can't possibly find these emails.

Stephen was using your arm.com email.

https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xxxxxxxxxx/

> 
>> On Friday I have also send v1 of removal of that platforms (need to
>> send v2)
>> https://lore.kernel.org/alsa-devel/cover.1585311091.git.michal.simek@xxxxxxxxxx/
>>
> 
> You want to remove exising platforms two days before the start of the
> merge window?
> I don't think this is acceptable with such short notice.

I also don't think that will go through.

> 
>> That's why please really consider next steps and let us know.
> 
> I think the only option is to revert (at least partially) the Xilinx
> series.

Unfortunately.

Thanks,
Michal