[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56A09C42.3090209@arm.com>
Date: Thu, 21 Jan 2016 08:52:18 +0000
From: Marc Zyngier <marc.zyngier@....com>
To: Alban <albeu@...e.fr>
Cc: linux-mips@...ux-mips.org, Ralf Baechle <ralf@...ux-mips.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Alexander Couzens <lynxis@...0.eu>,
Joel Porquet <joel@...quet.org>,
Andrew Bresticker <abrestic@...omium.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] MIPS: ath79: irq: Move the CPU IRQ driver to
drivers/irqchip
On 20/01/16 19:46, Alban wrote:
> On Wed, 20 Jan 2016 12:49:48 +0000
> Marc Zyngier <marc.zyngier@....com> wrote:
>
>> On Tue, 17 Nov 2015 20:34:56 +0100
>> Alban Bedel <albeu@...e.fr> wrote:
>>
>>> Signed-off-by: Alban Bedel <albeu@...e.fr>
>>> ---
>>> arch/mips/ath79/irq.c | 81
>>> ++------------------------ arch/mips/include/asm/mach-ath79/ath79.h
>>> | 1 + drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/irq-ath79-cpu.c | 97
>>> ++++++++++++++++++++++++++++++++ 4 files changed, 105
>>> insertions(+), 75 deletions(-) create mode 100644
>>> drivers/irqchip/irq-ath79-cpu.c
>>>
>
> [...]
>
>>> +asmlinkage void plat_irq_dispatch(void)
>>> +{
>>> + unsigned long pending;
>>> + int irq;
>>> +
>>> + pending = read_c0_status() & read_c0_cause() & ST0_IM;
>>> +
>>> + if (!pending) {
>>> + spurious_interrupt();
>>> + return;
>>> + }
>>> +
>>> + pending >>= CAUSEB_IP;
>>> + while (pending) {
>>> + irq = fls(pending) - 1;
>>> + if (irq < ARRAY_SIZE(irq_wb_chan) && irq_wb_chan[irq] != -1)
>>> + ath79_ddr_wb_flush(irq_wb_chan[irq]);
>>> + do_IRQ(MIPS_CPU_IRQ_BASE + irq);
>>
>> I'm rather unfamiliar with the MIPS IRQ handling, but I'm vaguely
>> surprised by the lack of domain. How do you unsure that the IRQ space
>> used here doesn't clash with the one created in your "misc" irqchip?
>
> This driver extend the irq-mips-cpu driver which take care of setting up
> a legacy domain starting from MIPS_CPU_IRQ_BASE for these interrupts. I
> don't find this very nice either, but this patch is about moving the
> code out of arch/mips, so I tried to minimize unrelated changes.
As long as there is an underlying domain reserving the CPU range, then
this is fine.
So for this patch:
Acked-by: Marc Zyngier <marc.zyngier@....com>
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists