[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL1qeaGNF_8XNTQiWomiJjbuN0mVgayFNKWfMVzrd=bBtwEY7g@mail.gmail.com>
Date: Wed, 17 Sep 2014 09:36:06 -0700
From: Andrew Bresticker <abrestic@...omium.org>
To: Qais Yousef <qais.yousef@...tec.com>
Cc: Ralf Baechle <ralf@...ux-mips.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Jeffrey Deans <jeffrey.deans@...tec.com>,
Markos Chandras <markos.chandras@...tec.com>,
Paul Burton <paul.burton@...tec.com>,
Jonas Gorski <jogo@...nwrt.org>,
John Crispin <blogic@...nwrt.org>,
David Daney <ddaney.cavm@...il.com>,
Linux-MIPS <linux-mips@...ux-mips.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/24] MIPS: Provide a generic plat_irq_dispatch
On Wed, Sep 17, 2014 at 1:56 AM, Qais Yousef <qais.yousef@...tec.com> wrote:
> Hi Andrew,
>
>
> On 09/16/2014 12:51 AM, Andrew Bresticker wrote:
>>
>> For platforms which boot with device-tree or have correctly chained
>> all external interrupt controllers, a generic plat_irq_dispatch() can
>> be used. Implement a plat_irq_dispatch() which simply handles all the
>> pending interrupts as reported by C0_Cause.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@...omium.org>
>> ---
>> arch/mips/kernel/irq_cpu.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
>> index ca98a9f..f17bd08 100644
>> --- a/arch/mips/kernel/irq_cpu.c
>> +++ b/arch/mips/kernel/irq_cpu.c
>> @@ -94,6 +94,21 @@ static struct irq_chip mips_mt_cpu_irq_controller = {
>> .irq_eoi = unmask_mips_irq,
>> };
>> +asmlinkage void __weak plat_irq_dispatch(void)
>> +{
>> + unsigned long pending = read_c0_cause() & read_c0_status() &
>> ST0_IM;
>> + int irq;
>> +
>> + if (!pending) {
>> + spurious_interrupt();
>> + return;
>> + }
>> +
>> + pending >>= CAUSEB_IP;
>> + for_each_set_bit(irq, &pending, 8)
>> + do_IRQ(MIPS_CPU_IRQ_BASE + irq);
>> +}
>> +
>
>
> If I read the for_each_set_bit() macro correctly it'll iterate through the
> bits from least to most significant ones which is the reversed priority
> expected. Some platforms set timer interrupt to bit 7 which is should be the
> highest priority interrupt. Also when cpu_has_vint is set the hardware
> prioritirise from most significant to least significant bits so if
> plat_irq_dispatch() is used with set_vi_handler() it'll cause interrupts to
> be serviced in the wrong order.
Ah, right. I'll flip the order here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists