Re: [PATCH 02/35] ARM: davinci: select GENERIC_IRQ_MULTI_HANDLER

Sekhar Nori
2019-02-06T12:39:54Z

On 31/01/19 7:08 PM, Bartosz Golaszewski wrote:

> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
> index 67805ca74ff8..b9aec3c48a6a 100644
> --- a/arch/arm/mach-davinci/cp_intc.c
> +++ b/arch/arm/mach-davinci/cp_intc.c
> @@ -19,6 +19,7 @@
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
>
> +#include <asm/exception.h>
> #include <mach/common.h>
> #include "cp_intc.h"
>
> @@ -97,6 +98,16 @@ static struct irq_chip cp_intc_irq_chip = {
>
> static struct irq_domain *cp_intc_domain;
>
> +static asmlinkage void __exception_irq_entry
> +cp_intc_handle_irq(struct pt_regs *regs)
> +{
> + int irqnr = cp_intc_read(CP_INTC_PRIO_IDX);
> +
> + irqnr &= 0xff;
> +
> + handle_domain_irq(cp_intc_domain, irqnr, regs);

This leaves out spurious interrupt handling present in existing assembly
code. Can you add it back. May be use omap_intc_handle_irq() as an
example for handling spurious IRQs.

> +}
> +

> diff --git a/arch/arm/mach-davinci/irq.c b/arch/arm/mach-davinci/irq.c
> index 952dc126c390..3bbbef78d9ac 100644
> --- a/arch/arm/mach-davinci/irq.c
> +++ b/arch/arm/mach-davinci/irq.c
> @@ -28,11 +28,13 @@
> #include <mach/cputype.h>
> #include <mach/common.h>
> #include <asm/mach/irq.h>
> +#include <asm/exception.h>
>
> #define FIQ_REG0_OFFSET 0x0000
> #define FIQ_REG1_OFFSET 0x0004
> #define IRQ_REG0_OFFSET 0x0008
> #define IRQ_REG1_OFFSET 0x000C
> +#define IRQ_IRQENTRY_OFFSET 0x0014
> #define IRQ_ENT_REG0_OFFSET 0x0018
> #define IRQ_ENT_REG1_OFFSET 0x001C
> #define IRQ_INCTL_REG_OFFSET 0x0020
> @@ -45,6 +47,11 @@ static inline void davinci_irq_writel(unsigned long value, int offset)
> __raw_writel(value, davinci_intc_base + offset);
> }
>
> +static inline unsigned long davinci_irq_readl(int offset)
> +{
> + return __raw_readl(davinci_intc_base + offset);
> +}

Can we use readl_relaxed() here? I know there is existing __raw_writel()
usage. May be add a patch to fix the existing code first.

Thanks,
Sekhar