[PATCH 1/2] n2100: support assigning XINT1 to UART

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Mikael Pettersson]

The Thecus n2100 has a jumper which determines if the XINT1
interrupt line is connected to the second UHCI controller
(position J3) or the serial console UART (position J4).

In position J3 (default) the second UHCI controller is fully
operational, allowing low-speed USB devices to be connected
to any of the three USB ports. However, the UART has to be
polled by a high-frequency timer, causing CPU overheads.

In position J4 the second UHCI controller is not operational,
causing low-speed USB devices to only work when connected to
the front USB port. On the other hand, the UART polling timer
is eliminated, resulting in reduced CPU overheads. This is
especially important for tickless systems.

This patch adds a compile-time option allowing the kernel to
be configured appropriately for the J3 or J4 cases.

(This could possibly be handled by a kernel boot option instead,
but I opted for a much simpler compile-time option for now.)

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
---
 arch/arm/mach-iop32x/Kconfig |   21 +++++++++++++++++++++
 arch/arm/mach-iop32x/n2100.c |   15 +++++++++++++--
 2 files changed, 34 insertions(+), 2 deletions(-)

diff -rupN linux-2.6.31/arch/arm/mach-iop32x/Kconfig linux-2.6.31.arm-n2100-1-xint1-uart/arch/arm/mach-iop32x/Kconfig
--- linux-2.6.31/arch/arm/mach-iop32x/Kconfig	2008-07-14 10:22:36.000000000 +0200
+++ linux-2.6.31.arm-n2100-1-xint1-uart/arch/arm/mach-iop32x/Kconfig	2009-09-26 13:39:20.000000000 +0200
@@ -43,4 +43,25 @@ config MACH_EM7210
 
 endmenu
 
+config N2100_XINT1_UART
+	bool "Support assigning Thecus n2100 XINT1 to UART"
+	depends on MACH_N2100 && NO_HZ
+	help
+	  The Thecus n2100 has a jumper which determines if the XINT1
+	  interrupt line is connected to the second UHCI controller
+	  (position J3) or the serial console UART (position J4).
+
+	  In position J3 (default) the second UHCI controller is fully
+	  operational, allowing low-speed USB devices to be connected
+	  to any of the three USB ports. However, the UART has to be
+	  polled by a high-frequency timer, causing CPU overheads.
+
+	  In position J4 the second UHCI controller is not operational,
+	  causing low-speed USB devices to only work when connected to
+	  the front USB port. On the other hand, the UART polling timer
+	  is eliminated, resulting in reduced CPU overheads. This is
+	  especially important for tickless systems.
+
+	  Say Y if tickless operation is important for you.
+
 endif
diff -rupN linux-2.6.31/arch/arm/mach-iop32x/n2100.c linux-2.6.31.arm-n2100-1-xint1-uart/arch/arm/mach-iop32x/n2100.c
--- linux-2.6.31/arch/arm/mach-iop32x/n2100.c	2008-12-25 15:54:13.000000000 +0100
+++ linux-2.6.31.arm-n2100-1-xint1-uart/arch/arm/mach-iop32x/n2100.c	2009-09-26 13:49:18.000000000 +0200
@@ -43,6 +43,17 @@
 #include <mach/time.h>
 
 /*
+ * N2100 IRQ assignments depend on XINT1 jumper.
+ */
+#ifdef CONFIG_N2100_XINT1_UART
+#define N2100_UART_IRQ		IRQ_IOP32X_XINT1
+#define N2100_VT6212_INTA_IRQ	-1	/* disabled */
+#else
+#define N2100_UART_IRQ		0	/* uses polling timer */
+#define N2100_VT6212_INTA_IRQ	IRQ_IOP32X_XINT1
+#endif
+
+/*
  * N2100 timer tick configuration.
  */
 static void __init n2100_timer_init(void)
@@ -95,7 +106,7 @@ n2100_pci_map_irq(struct pci_dev *dev, u
 		irq = IRQ_IOP32X_XINT2;
 	} else if (PCI_SLOT(dev->devfn) == 4 && pin == 1) {
 		/* VT6212 INTA */
-		irq = IRQ_IOP32X_XINT1;
+		irq = N2100_VT6212_INTA_IRQ;
 	} else if (PCI_SLOT(dev->devfn) == 4 && pin == 2) {
 		/* VT6212 INTB */
 		irq = IRQ_IOP32X_XINT0;
@@ -177,7 +188,7 @@ static struct plat_serial8250_port n2100
 	{
 		.mapbase	= N2100_UART,
 		.membase	= (char *)N2100_UART,
-		.irq		= 0,
+		.irq		= N2100_UART_IRQ,
 		.flags		= UPF_SKIP_TEST,
 		.iotype		= UPIO_MEM,
 		.regshift	= 0,

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Aaro Koskinen]

Hello,

Mikael Pettersson wrote:
> +config N2100_XINT1_UART
> +	bool "Support assigning Thecus n2100 XINT1 to UART"
> +	depends on MACH_N2100 && NO_HZ

This shouldn't depend on NO_HZ. Some people may want to use it
just to get (much) faster serial console.

A.

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Mikael Pettersson]

Aaro Koskinen writes:
 > Hello,
 > 
 > Mikael Pettersson wrote:
 > > +config N2100_XINT1_UART
 > > +	bool "Support assigning Thecus n2100 XINT1 to UART"
 > > +	depends on MACH_N2100 && NO_HZ
 > 
 > This shouldn't depend on NO_HZ. Some people may want to use it
 > just to get (much) faster serial console.

Agreed, this configuration has benefits also for NO_HZ.
I'll drop that dependency.

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Lennert Buytenhek]

On Sat, Sep 26, 2009 at 09:53:21PM +0200, Mikael Pettersson wrote:

> The Thecus n2100 has a jumper which determines if the XINT1
> interrupt line is connected to the second UHCI controller
> (position J3) or the serial console UART (position J4).
> 
> In position J3 (default) the second UHCI controller is fully
> operational, allowing low-speed USB devices to be connected
> to any of the three USB ports. However, the UART has to be
> polled by a high-frequency timer, causing CPU overheads.
> 
> In position J4 the second UHCI controller is not operational,
> causing low-speed USB devices to only work when connected to
> the front USB port. On the other hand, the UART polling timer
> is eliminated, resulting in reduced CPU overheads. This is
> especially important for tickless systems.
> 
> This patch adds a compile-time option allowing the kernel to
> be configured appropriately for the J3 or J4 cases.
> 
> (This could possibly be handled by a kernel boot option instead,
> but I opted for a much simpler compile-time option for now.)

Making it a compile-time option will pretty much guarantee that
none of the standard ARM distros that run on the n2100 will turn it
on, and so in the end the option won't be available to most n2100
users (the majority of n2100 users runs distro kernels on their
devices as far as I can tell), which kind of reduces the usefulness
of doing this in the first place.

Can't you detect whether the 8250 IRQ is routed at boot?  E.g. cause
the UART to throw an interrupt, check the XINT, clear the interrupt,
and check the XINT again, and see if the 8250 interrupt status
corresponds to the XINT or not?  (And then printk the result of the
detection.)

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Russell King - ARM Linux]

On Mon, Sep 28, 2009 at 11:58:13AM +0200, Lennert Buytenhek wrote:
> Can't you detect whether the 8250 IRQ is routed at boot?  E.g. cause
> the UART to throw an interrupt, check the XINT, clear the interrupt,
> and check the XINT again, and see if the 8250 interrupt status
> corresponds to the XINT or not?  (And then printk the result of the
> detection.)

8250 already has support for auto-probing its interrupt.

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > On Mon, Sep 28, 2009 at 11:58:13AM +0200, Lennert Buytenhek wrote:
 > > Can't you detect whether the 8250 IRQ is routed at boot?  E.g. cause
 > > the UART to throw an interrupt, check the XINT, clear the interrupt,
 > > and check the XINT again, and see if the 8250 interrupt status
 > > corresponds to the XINT or not?  (And then printk the result of the
 > > detection.)
 > 
 > 8250 already has support for auto-probing its interrupt.

The question is how well things work if the 2nd uhci and
serial share (software) interrupt. I'll have to check.

[PATCH 1/2] n2100: support assigning XINT1 to UART

[Mikael Pettersson]

Mikael Pettersson writes:
 > Russell King - ARM Linux writes:
 >  > On Mon, Sep 28, 2009 at 11:58:13AM +0200, Lennert Buytenhek wrote:
 >  > > Can't you detect whether the 8250 IRQ is routed at boot?  E.g. cause
 >  > > the UART to throw an interrupt, check the XINT, clear the interrupt,
 >  > > and check the XINT again, and see if the 8250 interrupt status
 >  > > corresponds to the XINT or not?  (And then printk the result of the
 >  > > detection.)
 >  > 
 >  > 8250 already has support for auto-probing its interrupt.
 > 
 > The question is how well things work if the 2nd uhci and
 > serial share (software) interrupt. I'll have to check.

Auto-probing doesn't seem to work.

If I disable the new option, making the n2100 board support code
assigns interrupts as before, and set CONFIG_SERIAL_8250_DETECT_IRQ=y,
I get

irq 28: nobody cared (try booting with the "irqpoll" option)
Backtrace: 
[<c002433c>] (dump_backtrace+0x0/0x110) from [<c0238364>] (dump_stack+0x18/0x1c)
 r7:00000000 r6:10000000 r5:c02e1988 r4:c02e1988
[<c023834c>] (dump_stack+0x0/0x1c) from [<c00584ec>] (__report_bad_irq+0x3c/0x94)
[<c00584b0>] (__report_bad_irq+0x0/0x94) from [<c0058694>] (note_interrupt+0x150/0x1e0)
 r4:c02e1988
[<c0058544>] (note_interrupt+0x0/0x1e0) from [<c0058f94>] (handle_level_irq+0xb0/0xe4)
[<c0058ee4>] (handle_level_irq+0x0/0xe4) from [<c0020070>] (_text+0x70/0x8c)
 r5:df823e48 r4:0000001c
[<c0020000>] (_text+0x0/0x8c) from [<c0020ac8>] (__irq_svc+0x48/0x80)
Exception stack(0xdf823da0 to 0xdf823de8)
3da0: c02fa940 00000000 c02fa940 20000013 df822000 00000000 10000200 00000102 
3dc0: df822000 df846b40 0000000a df823e1c df823e20 df823de8 c0034244 c003412c 
3de0: 20000013 ffffffff                                                       
 r5:df823dd4 r4:ffffffff
[<c00340e4>] (__do_softirq+0x0/0x11c) from [<c0034244>] (irq_exit+0x44/0x88)
[<c0034200>] (irq_exit+0x0/0x88) from [<c0020074>] (_text+0x74/0x8c)
[<c0020000>] (_text+0x0/0x8c) from [<c0020ac8>] (__irq_svc+0x48/0x80)
Exception stack(0xdf823e48 to 0xdf823e90)
3e40:                   df914f80 00000001 00000007 00000004 00000037 df914c00 
3e60: df914800 00000038 df822000 df846b40 df914f80 df823ee4 df823e30 df823e90 
3e80: c0137c38 c0239104 80000013 ffffffff                                     
 r5:df823e7c r4:ffffffff
[<c01379e4>] (n_tty_write+0x0/0x3b0) from [<c01354fc>] (tty_write+0x18c/0x22c)
[<c0135370>] (tty_write+0x0/0x22c) from [<c0135620>] (redirected_tty_write+0x84/0x94)
[<c013559c>] (redirected_tty_write+0x0/0x94) from [<c00816dc>] (vfs_write+0xb0/0xd8)
 r7:00000038 r6:df823f70 r5:be821680 r4:df846b40
[<c008162c>] (vfs_write+0x0/0xd8) from [<c00817c8>] (sys_write+0x44/0x70)
 r6:df846b40 r5:00000000 r4:00000000
[<c0081784>] (sys_write+0x0/0x70) from [<c0020e60>] (ret_fast_syscall+0x0/0x3c)
 r8:c0021004 r7:00000004 r6:401d6688 r5:be821680 r4:00000038
handlers:
[<c0193168>] (usb_hcd_irq+0x0/0xa0)
Disabling IRQ #28

when the kernel starts init, and the serial console remains in polling mode.

If I add "| UPF_AUTO_IRQ" to the plat_serial8250_port .flags, the serial
core does detect and use irq 28 for the uart, but so does the 2nd uhci,
and uhci appears to swallow everything on irq 28 because the console goes
silent as init is started and the uart switches to irq mode.

So a boot option or a probe in the n2100 board support code, with followup
adjustments of the irq assignments, seems like the only ways to do this
dynamically without a compile-time option.

/Mikael