[Nook Color Android Development] steven676:
Okay ... I'm a bit confused. I'm going to summarize my understanding of the situation as it stands; please correct me where I'm wrong.

With CONFIG_NO_HZ enabled: when the CPU is idle, the touchscreen fails to respond to many touch events (appears to be dropping events), and packets sent over wifi fail to wake the CPU from idle (creating high latencies). The HOME (Nook key) and POWER buttons are intermittently responsive (?). The volume buttons work normally. (If you're going to try the wifi and buttons, I'd suggest stopping the UI with stop first to try to keep the CPU idle.)

With CONFIG_NO_HZ disabled: when the CPU is idle, wifi works normally, the HOME and POWER buttons work normally (?), the touchscreen still seems to be dropping events (?). The volume buttons work normally.

In either case, if the CPU is pegged, events appear to be delivered correctly. It is irrelevant whether the process pegging the CPU is making system calls or not. (Something like

while true; do :; done

is a busy loop that runs entirely in userspace.)

With or without CONFIG_NO_HZ, and no matter what the state of the CPU is, input and output through adb on a USB connection is processed correctly and in a timely fashion.

/proc/interrupts contains the following:

CPU0
7: 31 INTC TWL4030-PIH
9: 0 INTC l3-debug-irq
10: 0 INTC l3-app-irq
11: 34 INTC prcm
12: 17519 INTC DMA
18: 0 INTC sr_mpu_iva
19: 1 INTC sr_core
20: 0 INTC gpmc
21: 7946 INTC SGX ISR
24: 0 INTC omap-iommu.0, Omap 3 Camera ISP
25: 97 INTC OMAP DISPC, omapdss_dsi1
28: 0 INTC DspBridge	iommu fault
36: 0 INTC dsp_wdt
37: 156940 INTC gp timer
56: 13765 INTC omap_i2c
57: 52 INTC omap_i2c
72: 11 INTC OMAP UART0
73: 2752 INTC
83: 5380 INTC mmc1
86: 849 INTC mmc0
92: 62008 INTC musb-hdrc
93: 62353 INTC musb-hdrc
94: 6756 INTC mmc2
174: 0 GPIO POWER
175: 500 GPIO wl12xx
208: 10 GPIO HOME
222: 0 GPIO max8903-fault-irq
259: 1 GPIO cyttsp-i2c
260: 0 GPIO max17042-irq
273: 0 GPIO kxtf9-irq
369: 15 twl4030 twl4030_keypad
371: 0 twl4030 twl4030_madc
378: 1 twl4030 twl4030_usb
379: 0 twl4030 rtc0
384: 0 twl4030 mmc1
385: 0 twl4030 mmc0
Err: 0

Note that the mmc and USB IRQs are connected to the INTC irq_chip, the volume buttons (twl4030_keypad) are connected to the twl4030 irq_chip, and POWER/HOME/wifi/touchscreen are all GPIO interrupts.

Tracing irq:irq_handler_entry (without a job pegging the CPU running) reveals that IRQs connected to INTC are handled while the system is running any of several different processes, but IRQs connected via GPIO are only ever handled in the idle thread.

Assuming all of the foregoing is correct, this is my working hypothesis:

The GPIO interrupts are not being set up correctly, causing them to fail to be reliably delivered.

While the CPU is busy, the system periodically polls interrupt lines (??), resulting in GPIO interrupts being handled correctly while the CPU is pegged.

When the kernel timer tick is enabled (CONFIG_NO_HZ=n), the CPU periodically wakes up to update the system clock (jiffies), at which point it notices the asserted GPIO interrupts (???).

The touchscreen driver has problems which extend beyond the GPIO interrupt issue (????). (This could be checked by peeking at /proc/interrupts while using the touchscreen -- the interrupt count increasing normally while the screen isn't responsive would be a sign of this.)

Corrections? Thoughts?

EDIT: Also, I have some local changes in my tree which change things to match the 2.6.32 kernel (unless I misread the .32 code): https://gist.github.com/2867753

I can't say I've noticed any improvements, though.