yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] steven676:
Possibly a stupid question, but is there a good way to get dmesg/stack trace information out of a crashed Nook Color? I ask because I tried porting dsscomp to .32 a while back -- managed to get ion + new PVR (sort of) working, and some unholy mix of ion + new PVR + new dss + dsscomp building, but the resulting kernel doesn't boot -- and poking around blind doesn't seem to work too well for me.
[Nook Color Android Development] fattire:
Depending when it's crashing, if you can get it back up, on the next boot the dmesg will usually appear in /proc/last_kmsg...
[Nook Color Android Development] steven676:
Huh, that's worked fine for me on my Nexus S on .35 and 3.0, and after just rebooting my .32 Nook Color, but I've never seen it working after a crash on my Nook. Come to think of it, though, I usually have to power-cycle my Nook to get it to reboot ... maybe I should enable reboot-on-panic ...
[Nook Color Android Development] keyodi:
you may also want to take a look at the lge sniper for back porting the ION driver

https://github.com/CyanogenMod/lge-kernel-sniper/commits/android-omap-2.6.35-ics?page=3

https://github.com/CyanogenMod/lge-kernel-sniper/commits/android-omap-2.6.35-ics?
[Nook Color Android Development] fattire:
sigh.. messed with this all day and still get

D/wpa_supplicant( 1760): Reading configuration file '/data/misc/wifi/wpa_supplicant.conf'

D/wpa_supplicant( 1760): update_config=1

D/wpa_supplicant( 1760): ctrl_interface='wlan0'

D/wpa_supplicant( 1760): ap_scan=1

D/wpa_supplicant( 1760): fast_reauth=1

D/wpa_supplicant( 1760): Could not open file /sys/class/net/wlan0/phy80211/name: No such file or directory

I/wpa_supplicant( 1760): rfkill: Cannot open RFKILL control device

D/wpa_supplicant( 1760): nl80211: RFKILL status not available

D/wpa_supplicant( 1760): nl80211: Set mode ifindex 0 iftype 2 (STATION)

D/wpa_supplicant( 1760): nl80211: Failed to set interface 0 to mode 2: -19 (No such device)

D/wpa_supplicant( 1760): nl80211: Try mode change after setting interface down

E/wpa_supplicant( 1760): Could not read interface wlan0 flags: No such device

D/wpa_supplicant( 1760): nl80211: Failed to set interface down

E/wpa_supplicant( 1760): Could not read interface wlan0 flags: No such device

D/wpa_supplicant( 1760): nl80211: Failed to set interface down

rfkill... gotta look at that some more tomorrow.
[Nook Color Android Development] krylon360:
fattire,

sent a pull request with some changes. I'll work on it more either tonight when I get back from the LMFAO concert, or tomorrow when I wake up.

haven't looked yet, but did you uncomment the rfkill refs? they were commented out at one point.
[Nook Color Android Development] fattire:
No, but I did forget to power the chip :P

Now that it's powered:

root@android:/ # netcfg

lo UP 127.0.0.1/8 0x00000049 00:00:00:00:00:00

sit0 DOWN 0.0.0.0/0 0x00000080 00:00:00:00:00:00

wlan0 DOWN 0.0.0.0/0 0x00001002 xx:xx:xx:xx:xx:xx [CHANGED]

root@android:/ # netcfg wlan0 up

action 'up' failed (Invalid argument)

It's seeing a card and a MAC. So that's progress. WPA still hung up:

D/wpa_supplicant( 1246): nl80211: Set mode ifindex 3 iftype 2 (STATION)

E/wpa_supplicant( 1246): Could not set interface wlan0 flags: Invalid argument

E/wpa_supplicant( 1246): nl80211: Could not set interface 'wlan0' UP

E/wpa_supplicant( 1246): wlan0: Failed to initialize driver interface

D/wpa_supplicant( 1246): Failed to add interface wlan0

and from dmesg:

<3>wl12xx: ERROR nvs size is not as expected: 1113 != 912

<3>wl12xx: ERROR nvs size is not as expected: 1113 != 912

<3>wl12xx: ERROR nvs size is not as expected: 1113 != 912

<3>wl12xx: ERROR firmware boot failed despite 3 retries

I bet it's the firmware is wrong.

Update: Looks like kuzm]a30 had this issue as well w/3.0 acclaim. I tried with acclaim firmware, but no dice. 'll check w/him...

Update #2: Looks like we need a custom nvs file. I'll have to build the calibrator tonight or tomorrow unless someone else wants to do it. Krylon?

Update #3: Krylon or keyodi or whomever-- if you do try it, remember that you need to modify a few files in the compat driver... see the last three commits from verygreen here. I hardcoded emmc 3 for the wifi.
[Nook Color Android Development] steven676:
Attached. Haven't tried to build the 3.x kernel yet, so not sure I can provide actual calibration data.

EDIT: Replaced with a version that knows where Android's insmod/rmmod are located, for posterity's sake. If you look down the thread, though, you'll see that we don't actually need to run our own calibration on the Nook Color.
[Nook Color Android Development] keyodi:
fattire,

i didn't make any modifications to the compat driver; however, i'm getting the same results.

I'll look at it tomorrow...We're almost there!

btw, which source are you using for the mac80211 (p-ics-mr1 or p-ics-mr1-release)?
[Nook Color Android Development] steven676:
Are you using the firmware from the linux-firmware tree (http://git.kernel.org/?p=linux/kern...firmware.git;a=tree;f=ti-connectivity;hb=HEAD)? (I see a 912-byte wl1271-nvs.bin there.) If so, there's a 1113-byte one that might work from omapzoom: http://omapzoom.org/?p=device/ti/proprietary-open.git;a=tree;f=wl12xx/wlan;hb=ics-mr1.

For whatever it's worth, http://omappedia.org/wiki/Android_Mac80211#WLAN_firmware seems to imply that the default calibration shipped with omapzoom should work, but perhaps that you should make your own calibration anyway?

EDIT: Okay, it's the other way around ...

wl1271_error("nvs size is not as expected: %zu != %zu", wl->nvs_len, sizeof(struct wl1271_nvs_file));

so I guess it's the one from the mainline linux-firmware tree that should be tried?
[Nook Color Android Development] krylon360:
Just got back from LMFAO and Far East Movement. Ill take a look at this tomorrow.
[Nook Color Android Development] steven676:
Actually, with the wl1271-nvs_127x.bin (also 912 bytes) from omapzoom (rename the file to wl1271-nvs.bin), the firmware files from omapzoom, and the wl12xx driver from omapzoom (branch p-ics-mr1) ...

root@android:/data/misc/wifi # ip link set wlan0 up
root@android:/data/misc/wifi # netcfg
lo UP 127.0.0.1/8 0x00000049 00:00:00:00:00:00
sit0 DOWN 0.0.0.0/0 0x00000080 00:00:00:00:00:00
wlan0 UP 0.0.0.0/0 0x00001003 00:d2:8b:43:9f:fd
root@android:/data/misc/wifi # ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:d2:8b:43:9f:fd brd ff:ff:ff:ff:ff:ff

and in dmesg:

<6>wl12xx: loaded
<6>wl12xx: open_count=0, add=1, current_fw=0
<6>wl12xx: state: 0
<6>wl12xx: firmware booted (Rev 6.3.8.0.111)

I can start wpa_supplicant, but scanning gives me no results. That said, this is with a month-old userspace built for 2.6.32 (so wpa_supplicant 0.6.x with -Dwext), so I wouldn't draw any conclusions from that.

EDIT: Oops, got ninja'd -- I see fattire's in the same place I am.
[Nook Color Android Development] fattire:
So... I've built the nvm file using calibrator. For future reference of anyone who might be googling this years from now, the syntax changed slightly.. here's what I ended up using. Note, this has to be run out of /data (or somewhere writable) and you have to have adb remount -ed /system as read-write.

stop

calibrator set ref_nvs /data/TQS_D_1.7.ini ./new-nvs.bin

cat ./new-nvs.bin > /system/etc/firmware/ti-connectivity/wl1271-nvs.bin

insmod /system/lib/modules/wl12xx_sdio.ko

calibrator dev wlan0 plt power_mode on

calibrator dev wlan0 plt tune_channel 0 7

calibrator dev wlan0 plt tx_bip 1 1 1 1 1 1 1 1

calibrator dev wlan0 plt power_mode off

calibrator set nvs_mac ./new-nvs.bin 08:00:28:90:64:31

rmmod wl12xx_sdio wl12xx

rmmod wl12xx

cat ./new-nvs.bin > /system/etc/firmware/ti-connectivity/wl1271-nvs.bin

insmod /system/lib/modules/wl12xx.ko

start

The result? I got a new-nvs.bin that is IDENTICAL to the one I was already using. And still I get this:

D/wpa_supplicant( 241): Scan requested (ret=0) - scan timeout 30 seconds

D/wpa_supplicant( 241): nl80211: Event message available

D/wpa_supplicant( 241): nl80211: Scan trigger

I/wpa_supplicant( 241): wpa_driver_nl80211_driver_cmd: Unsupported command SCAN-PASSIVE

D/wpa_supplicant( 241): nl80211: Event message available

D/wpa_supplicant( 241): nl80211: New scan results available

D/wpa_supplicant( 241): Received scan results (0 BSSes)

This is delightfully an error that chrmhoffmann had w/getting wifi to work for NT.. so i'm working to find out how it went from old and busted to new hotness. :)

Is this it? Don't see anything different in the device except

-WIFI_FIRMWARE_LOADER := ""

And some kernel changes... let's see if anyone can figure out what he changed... I've gone through it once previously, but I guess maybe this time I can do the board file changes.. I can't imagine the power stuff has to do with it.. (?)
[Nook Color Android Development] steven676:
Our kernel (board file):

static struct wl12xx_platform_data zoom3_wlan_data __initdata = {
.irq = OMAP_GPIO_IRQ(ZOOM3_WIFI_IRQ_GPIO),
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};

Theirs (https://github.com/Kuzma30/kernel3NookTablet/commit/761da574958f4e9d8c491eec29bde333a28a9ee4):

static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.irq = OMAP_GPIO_IRQ(GPIO_WIFI_IRQ),
-	.board_ref_clock = WL12XX_REFCLOCK_26,
-	.board_tcxo_clock = 1,// WL12XX_TCXOCLOCK_26,
+	.board_ref_clock = WL12XX_REFCLOCK_38,
+//	.board_tcxo_clock = 1,// WL12XX_TCXOCLOCK_26,
};

Gonna try that change and check back.

EDIT: nope, not that simple ...

EDIT: That said, our /system/etc/wifi/tiwlan.ini file for 2.6.32 says

STRFRefClock = 2 # Unit: Options 5'bXX000 : Bit 0,1,2 - (0: 19.2MHz; 1: 26MHz; 2: 38.4MHz (Default); 3: 52MHz; 4: 38.4MHz XTAL) ;
# 5'bX0XXX : Bit 3 - CLK_REQ type; 0 = wired-OR (Default) ,
# 5'b0XXXX : Bit 4 - CLK_REQ polarity; 0 = Normal (Default)

which would seem to imply that the clock should be running at 38.4 MHZ anyway.

EDIT #3: Okay, it is that simple after all. See below.
[Nook Color Android Development] fattire:
You can give it a shot and let me know.. the 2.6.32 explicitly says something about /* encore 26 mhz */ or something although i can't remember where. I'm trying some other insanity right now that will never work...

are you on IRC?

Talked to Chrmhoffmann briefly-- he said the PASSIVE thing isn't a problem, but he can't remember the solution. I think this is RIDICULOUSLY close..... I'm just trying some extra stupidity here...
[Nook Color Android Development] steven676:
It works!

D/wpa_supplicant( 292): wpa_supplicant_scan: scan_req = 0, ap_scan = 1
D/wpa_supplicant( 292): Starting AP scan (broadcast SSID)
D/wpa_supplicant( 292): wpa_driver_wext_combo_scan: Start
E/wpa_supplicant( 292): ioctl[SIOCSIWPRIV] (cscan): -1
D/wpa_supplicant( 292): Scan requested - scan timeout 10 seconds
W/wpa_supplicant( 292): Failed to initiate AP scan.

which looks like a wext problem to me. Guess I need to try nl80211 ...

I'm sluo on #nookcolor (it's been a long, long time since I've been on freenode ...)

EDIT: Okay, got it.

https://gist.github.com/2842326

It was the refclock after all. I believe the idea to look there is due to chrmhoffmann who was working on the Nook Tablet's wifi:
[Nook Color Android Development] fattire:
Update:

Steven got the last piece! It was the clock after all. Thanks chrmhoffmann (in spirit)!

I now have wifi working via the UI.

Some notes:

the interrupt issue or whatever it is not only affects the touchscreen but the network as well. We gotta fix this cuz it's SLOOWWWWWW... cat /dev/zero seems to "fix" it.

Hah! I just figured out why I missed this! When "encore" was substituted in for "zoom" in the peripherals file, suddenly "/* zoom ref clock is 26 MHz */" became the totally wrong note "/* encore ref clock is 26 MHz */" (!) and that's why I plugged in WL12XX_TCXOCLOCK_26 and thought it shouldn't be changed! Because... because I thought someone (I assumed at BN) had specifically noted "encore" was 26 mhz... D'OH!

those of you building at home, don't forget to cd device/ti/proprietary-open/wl12xx/wlan and then cp wl1271-nvs_127x.bin wl1271-nvs.bin so you get the right-sized nvs file in your build. At some point (soon) we can just move these to the device and copy them manually.

pushing these changes...pushed!

Great job everyone! On to the next issue: This stupid slowness.
[Nook Color Android Development] frankusb:
Just a guess, but is it possible the gpio irq controller for wifi/touchscreen is present but not enabled? Then when other irqs happen, the interrupt controller logic reads the gpio irq status and services them. That's the only thing common that I see between wifi and touchscreen. Both wifi and touchscreen irqs would have to come in on a gpio line.

Frank
[Nook Color Android Development] Divine_Madcat:
I am happy that we made it this far before I had to post, but...

For the devs sake, who are at a lighting pace right now, if it isn't dev related, DO NOT POST IT. You are welcome to make a separate discussion thread in general, but anything not dev related (or said by FT, etc) will be removed without warning..

Carry on folks..
[Nook Color Android Development] fattire:
This makes sense, but I have no idea where to look for where it might not be enabled.. it seems to match omapzoom as well as the acclaim settings and I've been hunting for anything referring to irq_enable or anything irq-ish that might account for it not working... but what you suggest makes sense.

FWIW keyodi reported that an earlier 2.6.35 port attempt also had something like this.

Update:

cat /proc/interrupts

Shows interrupts generated when touching the screen... why they aren't handled immediately, I don't know.
[Nook Color Android Development] fattire:
Because I haven't posted anything new in a few hours...

The OP now tells you how to replace your hardware/ti/omap3 with the TI stuff from omapzoom using local_manifest.xml

This, plus adding some minor changes (add "libion" to device.mk) which I'll push maybe tonight, will build the libion.so and other new bits... not important now but will be at a later time.

Scoring ~1587 in Quadrant w/interactive gov/1000 max fwiw. I don't remember if that' s good or terrible or what. What it probably really is is irrelevant.
[Nook Color Android Development] frankusb:
Instrument cyttsp_irq next? Make sure none of the bailing states are true? Make sure it's getting to cyttsp_report_tchdata. From there it looks like the data has been delivered to the input queue.

Frank
[Nook Color Android Development] fattire:
Random stuff...

I don't know the first thing about instrumenting (kprobes?) a kernel. I'm just a civilian :) But I threw in a buttload of printks all over that driver, especially in cyttsp_irq() and it seems that either a touch shows up or it doesn't-- I don't see any kind of errors, and I was using printks to tell me if any errors were being tripped ("bailing states") as well. Everytime we get to cttsp_irq, it seems to work as expected. The problem is, we don't get there enough.

cttsp_irq is called by this:

error = request_threaded_irq(ts->irq, NULL, cyttsp_irq,

IRQF_TRIGGER_FALLING | IRQF_ONESHOT,

pdata->name, ts);

Again, if there's an error, I think I should see it. Instead I see it just walking cleanly through cyttsp_probe() without any of the errors being tripped.

Last night steve also noticed pings dropping unless cat /dev/zero was in effect, so I'm thinking whatever is wrong is happening at a pretty low level indeed. This touchscreen kernel has been used successfully in 2.6.32 and its grandson from 3.4 that we're using now has been through a lot of debugging too no doubt...

Any ideas, anyone?

Update:

Some changes I made to defconfig:

diff arch/arm/configs/encore_defconfig .config

36c36

< # CONFIG_BROKEN_ON_SMP is not set

---

> CONFIG_BROKEN_ON_SMP=y

86d85

< CONFIG_CGROUP_CPUACCT=y

89,91c88

< CONFIG_CGROUP_SCHED=y

< CONFIG_FAIR_GROUP_SCHED=y

< CONFIG_RT_GROUP_SCHED=y

---

> # CONFIG_CGROUP_PERF is not set

133a131

> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set

148a147

> CONFIG_HAVE_HW_BREAKPOINT=y

156c155

< # CONFIG_RT_MUTEXES is not set

---

> CONFIG_RT_MUTEXES=y

287,288d285

< CONFIG_OMAP_MUX_DEBUG=y

< CONFIG_OMAP_MUX_WARNINGS=y

339d335

< # CONFIG_MACH_TI8168EVM is not set

484,486c480

< CONFIG_CPU_IDLE=y

< CONFIG_CPU_IDLE_GOV_LADDER=y

< CONFIG_CPU_IDLE_GOV_MENU=y

---

> # CONFIG_CPU_IDLE is not set

765a760

> # CONFIG_IP6_NF_TARGET_HL is not set

839a835

> # CONFIG_LIB80211_DEBUG is not set

875c871

< CONFIG_FW_LOADER=m

---

> CONFIG_FW_LOADER=y

Basically I removed CONFIG_CPU_IDLE* and here was the result:

The backlight is reversed. Bright=dark and vice-versa.

the touch printks look totally different now. Touches seem to be more sensitive, but I don't have a visible screen to verify that it's working.
[Nook Color Android Development] steven676:
Yeah, it pretty much can't be in the drivers themselves, has to be below that. Without any experience in working on ARM/embedded board support to back this hunch up, I'd look for differences between how the .32 kernel sets up the board (GPIO/pinmux, interrupt controller, power domain stuff, and so on) and what our 3.0 kernel is currently doing.

Another thought: disable the ability to suspend the system in the kernel config? I highly doubt this is the cause, since Android opportunistic suspend is supposed to ignore whatever's happening in userspace unless it takes a wakelock (which cat /dev/zero doesn't), but ... it couldn't hurt.

I believe the infrastructure you're looking for is provided by the "perf events" subsystem. Sadly, to say it's sparsely documented would be an understatement; there's an introduction at https://perf.wiki.kernel.org/index.php/Tutorial which barely even touches on the system's ability to trace arbitrary non-hardware events. Documentation/trace/tracepoint-analysis.txt in the kernel source seems to be a good introduction on using perf to look at kernel-defined tracepoints. The perf tool referred to in the documentation ships in tools/perf and has its own set of documentation under tools/perf/Documentation.

perf events provides timing information, statistics, and a set of tracepoints inserted into the kernel code by its developers, which I think should be most useful in debugging this problem. If you need more control, there are at least two more interfaces you could use (I know ... ridiculous):

ftrace basically generates a graph for each function call in the kernel. It won't provide you with things like page faults and stuff, though, and it can't give you any visibility into what happens inside the body of a function.

kprobes basically allows you to create custom tracepoints for anything you could possibly want in the kernel, but doing so is ... complicated. Since you control your kernel source, it's probably easier just to add your own tracepoints if you feel the need. There's a three-part tutorial by one of the developers published in LWN on how to add tracepoints: Part 1, Part 2, Part 3.

(I love LWN, by the way; it's THE source to go to for information on what's happening in core Linux kernel development now, and a ton of kernel features end up documented as LWN articles.)

---------- Post added at 01:54 AM ---------- Previous post was at 01:52 AM ----------

Huh, that's weird. I think the CPU idle stuff has to be configured in the board support files -- I'd check for differences with .32 and working (EDIT: with 3.0) boards.

You could check responsiveness without a touchscreen through manually setting up a wifi interface via adb and checking with ping, I suppose.
[Nook Color Android Development] fattire:
A lot of good info here. keyodi, you'll do this all, right? ;) Steve? Feel free to jump in and fix it too :)

FWIW, we have a liblights (from acclaim maybe?) in the device, and the new hardware/ti/omap3 from omapzoom has another one... maybe irrelevant. Just saying.

I also have been looking carefully at .32 vs 3.0.. maybe I'm missing stuff on similarity/differences in how its' set up. I think this is maybe a case where many eyeballs really will help find the issue.
[Nook Color Android Development] steven676:
Looks like C1-C2 idle states are set up differently in the .32 kernel and the 3.0 kernel.

2.6.32:

/* struct cpuidle_params defined in arch/arm/mach-omap2/pm.h */
struct cpuidle_params {
u8 valid;
u32 sleep_latency;
u32 wake_latency;
u32 threshold;
};
/* default params defined in arch/arm/mach-omap2/cpuidle34xx.c */
static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
{1, 0, 12, 15},
/* C2 */
{1, 0, 18, 20},
/* C3 */
{1, 50, 50, 300},
/* C4 */
{1, 1500, 1800, 4000},
/* C5 */
{1, 2500, 7500, 12000},
/* C6 */
{1, 3000, 8500, 15000},
/* C7 */
{1, 10000, 30000, 300000},
};

3.0:

/* struct cpuidle_params defined in arch/arm/mach-omap2/pm.h */
struct cpuidle_params {
u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
u32 target_residency;
u8 valid; /* validates the C-state */
};
/* default params defined in arch/arm/mach-omap2/cpuidle34xx.c */
static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
{2 + 2, 5, 1},
/* C2 */
{10 + 10, 30, 1},
/* C3 */
{50 + 50, 300, 1},
/* C4 */
{1500 + 1800, 4000, 1},
/* C5 */
{2500 + 7500, 12000, 1},
/* C6 */
{3000 + 8500, 15000, 1},
/* C7 */
{10000 + 30000, 300000, 1},
};

I think the net result is that the 3.0 kernel is more willing to transition into and out of the C1 state. Instinct suggests to me that this shouldn't be causing a problem (these are defaults set by TI which should in theory work for all OMAP3xxx boards), but it may be worth considering changing these to match the .32 setup. I think the equivalent for 3.0 is

static struct cpuidle_params cpuidle_params_table[] = {
/* C1 */
{0 + 12, 15, 1},
/* C2 */
{0 + 18, 20, 1},
/* C3 and below as before ... */

Technically, we should create a copy of this table in our own board file and register it with omap3_pm_init_cpuidle() in our own omap_zoom_init() -- see what board-rx51.c (the Nokia N900 board) does.

EDIT: It looks like some stuff in omapzoom's p-android-omap-2.6.32 tree never made it to p-android-omap3-3.0:

http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=65edde98e574fd0ab5b23c7236e30752750d9965

Looking farther up the history for cpuidle34xx.c turns up this rather interesting patch:

http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=7aaeb1d22134777e790693314b19635e28d224db

Unfortunately, there's been some pretty significant change in this code since .32 -- here's the history for the same file in p-android-omap3-3.0:

http://omapzoom.org/?p=kernel/omap....ch-omap2/cpuidle34xx.c;hb=p-android-omap3-3.0

At a glance, it looks like this code was reworked to move more of the responsibility into the kernel's generic idle framework.

I have to sleep now, but someone should look at the .32 changes that weren't picked up, particularly the ones I called out, and see if they can be added to the 3.0 kernel.

EDIT 2: Had a peek at the 3.0 code. It appears to do something similar to the 2.6.32 code, but unconditionally, so the patch I called out shouldn't in principle be relevant.
[Nook Color Android Development] frankusb:
OK, I think Steve is right, this is an overall scheduling/idle thing then. Maybe not GPIO IRQ related. It just seems odd that other things like the file system block device (SDHC controller) would not be broken in the same way if so. But maybe the others don't do threaded IRQs.

FWIW, the backlight is generated from a 32kHz timer that is divided down to 128Hz and controlled by one of the internal timers toggling a GPIO. The timer takes the brightness value and changes it to a count that is used by the timer to turn on/off the GPIO.

In contrast to the touchscreen driver, the backlight driver uses request_irq instead of request_threaded_irq. But it does schedule_work so maybe that's how the idle change is changing the backlight behavior.

Frank