linux-mips
[Top] [All Lists]

Re: [PATCH] au1x00 serial real interrupt

To: Russell King <rmk@arm.linux.org.uk>
Subject: Re: [PATCH] au1x00 serial real interrupt
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Sat, 09 Sep 2006 20:58:48 +0400
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>, Ralf Baechle <ralf@linux-mips.org>, Rodolfo Giometti <giometti@linux.it>, linux-mips@linux-mips.org
In-reply-to: <20060909163907.GA24012@flint.arm.linux.org.uk>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20060522165244.GA16223@enneenne.com> <44FD9587.3030708@ru.mvista.com> <4502ED14.6080506@ru.mvista.com> <20060909163907.GA24012@flint.arm.linux.org.uk>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Russell King wrote:

Well, after looking at drivers/serial/8250.c a bit more, I think this may be even more simlified since that driver seems to treat the negative values as completely invalid anyway. IOW, we can just:

#define is_real_interrupt(irq)  1

  Russel, what do you think?

That's Russell 8)

   I'm sorry. :-)

Well, if you need IRQ0 to be real then redefining is_real_interrupt()
is the correct way forward.

However, Linus' policy is that IRQ0 shall be invalid at least on PCI
systems, and architectures _should_ remap their real IRQ0 to some other
number.

  Hm, given that NO_IRQ is #defined as -1 (when it's defined at all)...

 Personally I don't like this.

   Hm, me neither but I can undestand the reasoning. 0 is the usual default
value of the PCI interrupt line register, meaning interrupt is unassigned.

> Hence why I prefer to give people the option.

   Thanks for the explanation.
Would be better probably to have that #define in 8250.c going after #include <asm/serial.h> but as this seems the first and only case of the override needed, it's good enough this way. :-) As for the PCI UARTs possibly plugged into Alchemy board, I really don't know... This macro has no provision to check for the UART type. So, skipping its invocation in 8250.c for UPIO_AU case might be a better (though not cleaner) solution...

WBR, Sergei

<Prev in Thread] Current Thread [Next in Thread>