yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] keyodi:
i tried changing the cpuidle values as suggested and................the issue remains :(

if i recall, i had a similar issue with the touchscreen while working on the .35 kernel. I worked around it by disabling PM_RUNTIME; however, making the change on the 3.0 kernel didn't have the same desired result.

Keep the ideas coming!
[Nook Color Android Development] fattire:
Okay, how's this for annoying...

I updated a couple led and display-related files to meld BN's acclaim (NT) kernel driver (w/earlysuspend support) for 1.4.2 and the zoom2 stuff.

The result... backlight works, but freezes on bootanim. **UNLESS** you "cat /dev/zero" while it's booting, in which case it works fine. Brightness still can't be adjusted tho.

Go on-- try it-- do these patches and then try to boot. Without "cat /dev/zero", it freezes.

AGH. We gotta fix this somehow. Maybe the changes I did will point someone in a direction to look again at what's triggering the issue (?) There's some timer stuff and some interrupt stuff...

Update: for anyone curious about differences from the (working) encore 2.6.32 version, here it is.

Noticed difference between these two lines:

-	omap_dm_timer_set_source(led->intensity_timer, OMAP_TIMER_SRC_32_KHZ);

+	omap_dm_timer_set_source(led->intensity_timer, OMAP_TIMER_SRC_SYS_CLK);

They have different values, but unfortunately changing this didn't do anything.
[Nook Color Android Development] krylon360:
forgot the nook at the house, but will be building some stuff tonight while here at work. hope to have this issue fixed soon so we can start concentrating on the OMAP_ENHANCEMENT code since it looks like TI has no plan to add it back.

Also, for those wanting to sync with the local_manifest posted in the OP, it'll need to look like this or it will error out. fattire, can you update the OP to reflect the change?

<?xml version="1.0" encoding="UTF-8"?>
<manifest>

<remote name = "gh"
fetch="git://github.com/" />

<remote name ="oz"
fetch="git://git.omapzoom.org" />

<remove-project name="CyanogenMod/android_hardware_ti_omap3" />

<project path="device/bn/encore"
name="fat-tire/android_device_bn_encore"
remote="gh"
revision="ics-3.0"/>

<project path="kernel/bn/encore"
name="keyodi/ti-omap-encore-kernel3"
remote="gh"
revision="encore-omap3-3"/>

<project name="platform/hardware/ti/omap3"
path="hardware/ti/omap3"
remote="oz"
revision="ics-mr1" />

</manifest>
[Nook Color Android Development] Dj-Gutz:
Looks like Lenovo released an updated version with most bugs fixed - HERE

I hope useful stuff can be extracted from it after "cat /dev/zero" bug is figured out

Here is how it works on the A1

[YOUTUBE]HYv4NFcEH7A[/YOUTUBE]
[Nook Color Android Development] steven676:
Okay, it's looking very much like some sort of issue with waking the CPU from idle ...

Here's a couple of charts generated by the perf timechart utility, both during an attempt to ping another host over wifi.

The first is without anything else running:

http://www.ocf.berkeley.edu/~sluo/nook-color/cpuidle.svg

The top bar of the chart shows the state of the CPU during the entire time -- various shades of red when idling, blue when running. Each of the other bars represents a process that ran at some point during this time -- the one for ping is at the bottom. Gray represents a sleeping process, red is a process blocking for I/O, yellow a process waiting in the run queue, and blue is a running process. The gray vertical lines represent elapsed time -- the heavy lines are spaced one second apart, the lighter ones a tenth of a second apart.

You should notice that ping wakes up once a second on the dot -- presumably to send a ping. But when it wakes up again (indicating receiving the ping) is highly variable -- typically around 100 ms (which is expected -- the wifi chip checks the beacon to figure out whether it should wake the CPU to handle traffic), but there are several instances of wider variation, including one instance where the previous reply isn't picked up by userspace until ping is woken up to send the next ping. The CPU is shown in a deep idle state in these cases, suggesting that it's failing to wake up from idle when needed.

The second is with "echo y > /dev/null" running in a tight loop:

http://www.ocf.berkeley.edu/~sluo/nook-color/cpupinned.svg

As you'd expect, the CPU is running 100% of the time, and pings are received in a timely fashion (the system is awake, so wifi will receive the ping reply as it's sent).

EDIT: Okay, it's more complicated than that ...

I still get random latency even after I disable all the CPU idle states other than C1 in cpuidle34xx.c (https://gist.github.com/2862775). That would seem to point towards interrupt issues ...
[Nook Color Android Development] steven676:
Okay, I have a workaround for the failure to wake to respond to IRQs: disable CONFIG_NO_HZ in your kernel configuration.

That's not a permanent solution because it comes with a significant penalty in battery life -- with the timer tick enabled, the CPU is forced to wake up hundreds of times a second (exactly how often depends on the value of CONFIG_HZ), which means it can never drop to the deeper idle states. It should allow progress on developing the 3.0 kernel without developing the urge to smash your tablet with a hammer, though ...
[Nook Color Android Development] keyodi:
I tried disabling CONFIG_NO_HZ, but it didn't seem to make any difference. Was there any other changes that i need to make?
[Nook Color Android Development] steven676:
Huh. git diff shows no code changes in my tree (a few differences, but they're either all #if 0'ed out or in the perf code). Here's the diff between encore_defconfig and my .config: https://gist.github.com/2865154

Lots of noise in that diff, though -- the changed scheduler, cpufreq governor, RCU implementation, ThumbEE change, and so on shouldn't have any impact. That leaves:

CONFIG_OMAP_32K_TIMER_HZ increased from 128 to 512. 512 is the value in the .32 kernel config. This also affects the value of CONFIG_HZ -- a higher HZ value might make the system more responsive with CONFIG_NO_HZ disabled.

CONFIG_WLAN_POWER_EVT1 enabled. This is also enabled in the .32 config, but I have no idea whether it's used in the 3.0 code.

Tracing stuff, notably CONFIG_KPROBES, CONFIG_FUNCTION_TRACER, CONFIG_FUNCTION_GRAPH_TRACER, CONFIG_IRQSOFF_TRACER, CONFIG_SCHED_TRACER, CONFIG_KPROBE_EVENT, and CONFIG_DYNAMIC_FTRACE. Theoretically should have little or no impact, but it wouldn't be the first time I've seen instrumentation change the behavior of the system ...

By the way, there are a few things in this config I think we should adopt generally:

CONFIG_CGROUPS=n: cgroups are awesome on servers (where they enable isolation like FreeBSD jails or Solaris zones), but unused on Android, and there is some overhead to having the feature enabled.

CONFIG_ARM_THUMBEE=y: the CPU supports the instructions, we should enable them.

CONFIG_DEVKMEM=n: historically used to give userspace access to the kernel's address space, nowadays almost exclusively used by rootkits.

CONFIG_STRICT_DEVMEM=y: the only legitimate use of /dev/mem is for something like X11 which needs to do memory-mapped I/O from userspace. This option prevents /dev/mem from being used for anything else. (That said, CONFIG_DEVMEM=n probably works just as well for Android.)

EDIT:

How are you changing config options -- by editing .config/encore_defconfig by hand, or via make config/make menuconfig? I couldn't even get the 3.0 kernel to build with CONFIG_PM_RUNTIME disabled without disabling half a dozen other things and enclosing some code with #ifdef CONFIG_PM_RUNTIME, and the result didn't boot.

If you just edited the .config/encore_defconfig, it's likely that the build system reenabled the option for you because of dependencies -- CONFIG_ARCH_OMAP2PLUS_TYPICAL depends on CONFIG_PM_RUNTIME. CONFIG_IKCONFIG/CONFIG_IKCONFIG_PROC is useful for this reason -- you can see the exact configuration which the running kernel was built with.
[Nook Color Android Development] fattire:
Hmmm. I tried it too and still have the touch issues. It sucks because not only do touches not get detected in their entirety, but lift-off finger events also are missed so the ends of swipes are never recognized, so android tihnks you're still holding your finger down when you're not.

I'm going to check in the defconfig I'm using for the hell of it, which has most of the suggestions above, including CONFIG_HZ=512 and # CONFIG_NO_HZ is not set and some other things.

Also-- I guess those diffs in the gists above was actually helpful-- keyodi got the backlight dimming to work and checked that in as well. So that's something for today, and anyone reading this should find a post and thank him.
[Nook Color Android Development] krylon360:
I did some changes myself locally tonight. I rebased the board-encore-peripherals.c off a newer board-evt-peripherals.c that was built for encore.

Doing this pretty much fixes the scrolling issue. but I broke wifi in the process so I'll fix that tonight. Now it's just a touch issue. I'm seeing that the screen still thinks it's being touched even though it's not.

This could be 1 of 2 things. a kxtf9 driver issue (this is the accelerometer driver which also controls single and double taps); or its in fact a cyttsp driver issue. This is some of the new code I put into the peripherals file which matches up with the 3.4 cyttsp driver we are using.

/* change act_intrvl to customize the Active power state
* scanning/processing refresh interval for Operating mode
*/
.act_intrvl = CY_ACT_INTRVL_DFLT,
/* change tch_tmout to customize the touch timeout for the
* Active power state for Operating mode
*/
.tch_tmout = CY_TCH_TMOUT_DFLT,
/* change lp_intrvl to customize the Low Power power state
* scanning/processing refresh interval for Operating mode
*/
.lp_intrvl = CY_LP_INTRVL_DFLT,

Here is what the driver states these intervals are; I think these are in decimal, but cant remember how it's defined in c. This can be found in cyttsp.h

/* Active Power state scanning/processing refresh interval */
#define CY_ACT_INTRVL_DFLT 0x00 /* ms */
/* touch timeout for the Active power */
#define CY_TCH_TMOUT_DFLT 0xFF /* ms */
/* Low Power state scanning/processing refresh interval */
#define CY_LP_INTRVL_DFLT 0x0A /* ms */
/* Active distance in pixels for a gesture to be reported */
#define CY_ACT_DIST_DFLT 0xF8 /* pixels */

We may just need to tweek these intervals, or try to find a newer kxtf9 source, which I did find, however, it looks a HELL of a lot different than the one we are using, however, it's using a separate

Here is a video of the scrolling with my changes. You can see how it kinda hangs thinking I still have my finger on the screen.

[YOUTUBE]bhtM3t5BaZQ[/YOUTUBE]

as you can see, I'm not plugged in nor am I running termemu so I wasn't running cat /dev/zero like we have been to get touch to be this responsive. Once I fix wifi tonight I'll push my changes. For now, here's the PB if fattire or anyone else wants to have a look. Im sure I just messed up a gpio for wlan or something. BT works, just not wlan.

http://pastebin.com/HKY8C11G
[Nook Color Android Development] fattire:
Where'd you get the newer board-evt-peripherals.c?

What is the scrolling issue that it fixed? The side-to-side swiping sensitivity do you mean? In the video it looked sensitive until the boot "settled down" at which point it looked not-sensitive again. Does the working touchscreen continue even after cpu usage settles?

Well the original 2.6.32 cyttsp driver was totally replaced with the pretty-different 3.4 driver. I don't know that we did that with the kxf9 one, which was spitting out that debug info into dmesg. Did anyone try simply turning debug off on the driver?

..separate..? Did you try playing with those #s to see if they make any difference..

It looked a little bit like the current issue-- sensitivity during the first 30 seconds (when I assume the processor is still doing stuff) with decreased sensitivity later...

One thing that may help for debugging is to go to Settings->Developer and turn on the options for seeing touches, etc... Thanks guys (and gals?).. we're getting closer and closer I think :)
[Nook Color Android Development] keyodi:
I just read the last couple of posts and i had to take some aspirin for my headache.

Anyways...overall i agree w/ fattire. Based on the video it looks like our current issue.

I don't think the tap/double tab correlates with the touchscreen, but the KXTF9_GPIO_FOR_PWR and CYTTSP_I2C_SLAVEADDRESS do share the same GPIO number (34). At this point, i don't

think

it's a driver issue. I could be wrong

reference: source for KXTF9

Timers and Thresholds

Tap ODR – The output data rate for the tap/double-tap engine is variable between 50Hz and

400Hz. The Tap ODR is dictated by the OTDTA and OTDTB bits in Control Register 3. All tap

timers are based on this ODR, which defaults to 400Hz. Each count in every tap timer equals

one cycle of this Tap ODR.

TDT (Tap/Double-Tap) Timer – This timer establishes the minimum time separation between the

first tap and the second tap in a double tap event. This timer defaults to 0.3 seconds.

Haven't had any issues with the HOME (Nook key) and POWER buttons. Make sure to pull in the latest changes for the display, which should fix waking the screen while in sleep.

I still haven't noticed any difference with CONFIG_NO_HZ disabled. it seems to work the same as having it enabled. So far everything you (steven676) have stated makes sense, just not sure how to fix it.
[Nook Color Android Development] Dj-Gutz:
Excuse me if I'm diving way out of my pool of knowledge

Can we check the GPIO conflict by getting someone with ft5x06 touchscreen to see if this bug exists on their device?

cuz FT5x06_I2C_SLAVEADDRESS is (0x70 >> 1) and not 34

Since NT doesn't seem to have this issue , and I'm guessing ( haven't checked ) our ktxf9 driver is the same

Maybe it's needed to disable the cyttsp driver completely so it doesn't interrupt? that way we can isolate the issue

Seems like a easy check , I don't know if any of you devs have the newer nook version ( I don't :\ )
[Nook Color Android Development] fattire:
Maybe there's something here but probably not

Well I have another useless diff for y'all to contemplate.

What I did

Looked more at the peripheral i2c setup on acclaim's 3.0 port and tried to mirror it a little more on our device. I noticed that there was some spinlock stuff on acclaim which I brought into ours, as well as using two buses... I also disabled internal pullup (whatever that is) as is done on the 2.6.32 board file..

I also recopied the kxtf9 driver from acclaim, which basically has the effect of taking out the debug instruction. There is a kxtj9 (note j instead of k) in the 3.4 kernel, which I started to move over and though maybe is "close" but then went with acclaim's instead since we KNOW that works with 3.0. It's basically the same as ours, just with some formatting differences.

I also commented out the cyttsp from the i2c device init so it would never be initialized.

The result

Nothing. commenting out the cyttsp removed all touchscreen behavior so that was kinda useless. Putting it back though, even with all the changes in the diff above-- everything still works. Touchscreen and everything. It's just htat we have the sensitivity issue.

This diff might actually be the "right" way to do things, or at least closer to acclaim-- I think it may be using newer functions or something. But since it doesn't fix anything I'm not gonna push it. It's up there for reference at the moment.

It think it's gotta be down DEEP deep somewhere.
[Nook Color Android Development] krylon360:
Where'd you get the newer board-evt-peripherals.c?

I based it off this one that was pushed 4 months ago:

https://github.com/martinezjavier/nook_color/commit/2d0e807622305923a18a29bc861a60ce1f2595bb

What is the scrolling issue that it fixed? The side-to-side swiping sensitivity do you mean? In the video it looked sensitive until the boot "settled down" at which point it looked not-sensitive again. Does the working touchscreen continue even after cpu usage settles?

Yes, its smooth non-stop. It just thinks I still had my finger on the screen which is why it looked like it was stuttering. I've had the nook plugged in and turned on for about 30 minutes now, and it's still smooth. It just thinks the screen is being tapped when it's not.

Well the original 2.6.32 cyttsp driver was totally replaced with the pretty-different 3.4 driver. I don't know that we did that with the kxf9 one, which was spitting out that debug info into dmesg. Did anyone try simply turning debug off on the driver?

not yet

..separate..? Did you try playing with those #s to see if they make any difference..

Didnt have a chance this morning. This is the one I saw online.

http://asf.atmel.com/docs/latest/xm...-a3bu_avrsbin1_wake/html/kxtf9_8h_source.html

00154 #define INT_SRC_REG2_TD_SINGLE (0x04) /* single tap */

00155 #define INT_SRC_REG2_TD_DOUBLE (0x08) /* double tap */

However, I just found a patch, which would allow the NC to use the KXTJ9 driver like the NT does.

http://www.spinics.net/lists/linux-input/msg19038.html

the Iconia devs used the same patch here, as well as a few bug fixes within the KXTJ9 driver

https://github.com/astarasikov/iconia-gnu-kernel/commit/edaa453540ffb7dcc10b2a60991c08005e471e8f

It looked a little bit like the current issue-- sensitivity during the first 30 seconds (when I assume the processor is still doing stuff) with decreased sensitivity later...

As stated above, its still smooth even after being asleep for a while. just during scrolling the driver still senses a "ghost" finger

One thing that may help for debugging is to go to Settings->Developer and turn on the options for seeing touches, etc... Thanks guys (and gals?).. we're getting closer and closer I think :)
[Nook Color Android Development] steven676:
Having finally managed to get the UI to come up on a 3.0 kernel ... there appear to be some interesting behavior changes depending on whether the UI is up or not.

All of the following tests are run with a kernel with CONFIG_NO_HZ enabled; I won't have the time to test the other way around until closer to the end of the week.

Boot the tablet. Connect the tablet to your computer with a USB cable and get an adb shell. My results: touchscreen is intermittently unresponsive; pinging a host on the wifi network shows variable but acceptable latencies; HOME and POWER buttons work and cause the appropriate entry in /proc/interrupts to increase by 2 for each press; volume buttons work and cause the twl4030-keypad entry in /proc/interrupts to increase by 3 for each press.

Pin the CPU with a "while true; do :; done". My results: touchscreen is responsive, pinging a host on the wifi network shows acceptable latencies, HOME and POWER buttons work, volume buttons work.

Stop the UI with "stop". My results: pinging a host on the wifi network shows unacceptable latency, HOME and POWER buttons don't work (don't increment /proc/interrupts), volume buttons work.

Pin the CPU again. My results: pinging a host on the wifi network shows acceptable latencies, HOME and POWER buttons work, volume buttons work.

Start the UI again with "start". My results: touchscreen is intermittently unresponsive, pinging a host on the wifi network shows variable but acceptable latencies, HOME and POWER buttons work, volume buttons work.

Pin the CPU again. My results: touchscreen is still intermittently unresponsive, pinging a host on the wifi network shows acceptable latencies, HOME and POWER buttons work, volume buttons work.

Could someone else run these tests and see if they get the same results?

Hypotheses:

GPIO interrupts are incorrectly set up. INTC and twl4030 interrupts are.

The UI polls the hardware buttons for events, making the problems with GPIO keys irrelevant.

The UI's network traffic indicator (the arrows displayed on the wifi icon in the notification area) keeps the CPU busy when network packets are sent or received, keeping wifi latencies low when the UI is running regardless of whether something else is pinning the CPU.

The touchscreen has issues above and beyond the GPIO interrupt problem ...

EDIT: For reference, with 2.6.32 running on a (nearly*) identical userspace, for any of the scenarios above: touchscreen is responsive, ping shows acceptable latencies which do not vary based on CPU load, HOME and POWER buttons work, volume buttons work.

(*) Changes between .32 and 3.0: kernel, ramdisk, modules, /system/lib/libhardware_legacy.so, /system/lib/hw/*, /system/etc/wifi/wpa_supplicant.conf, /system/bin/wpa_supplicant.
[Nook Color Android Development] speedfreak007:
Hey all! I was searching the net (hoping to find something useful that you guys did not see yet). I've found an interesting thread on the TI forums: http://e2e.ti.com/support/embedded/android/f/509/t/165482.aspx?pi24527=2

be sure to check the latest post (it's from today). Is this useful?
[Nook Color Android Development] fattire:
sounds about right.

I keep running out of battery (thanks to NO_HZ I'm guessing) so I can't test it right now, but what youv'e described sounds pretty right-on, with the exception that I didn't notice issues with HOME/POWER at all. Those are both detected via GPIO (as opposed to volume keys) FWIW. I'm doing a new, fresh build now so hopefully I'll be charged up enough to test it.

More things I've tried that did nothing.

turning off smartreflex

adding "omap3-opp.h" and removing "timer-gp.h" from board-encore.c

messing with mux.h to try to make it more like the .32 version.
[Nook Color Android Development] douginoz:
The AM3517EVM board in that post uses OMAP3517. The NC uses OMAP3630 (or OMAP3621, depending on website....)
[Nook Color Android Development] krylon360:
I've been trying several things as well, including the new peripherals.c, enabling the cyttsp_spi driver, and working on patching KXTJ9 driver to work with the KXTF9 hardware. (still need to recode peripherals to work with that; have to get the GPIO's correct.) So far no change.
[Nook Color Android Development] fattire:
today's nothing.

Okay today's lack-of-progress report:

* tried about a zillion defconfig combinations and ultimately restored most of the settings we'd used to at least get some normal battery and better functionality.

* among the changes are the netfilter for guid so that network feature thing works. Probably a ton of other stuff I turned on... I mean I buried at least six hours in playing with various defconfigs.

* I made a ton of changes to the device, and now it builds a whole lot of OMX stuff in the latest omapzoom hardware/ti/omap3 directory, including cexec.out, which is used to load the userside half of the DSP. To get the new omap3 stuff to build, I had to substitute hardware/ti/omap3/ion/ion.h with the one from our kernel.

* I'm able to get cexec to work, much as it does in cm7.

# /system/bin/cexec.out -v /system/lib/dsp/baseimage.dof

Verbose mode: ON

DSP device detected !!

DSPProcessor_Attach succeeded.

DSPProcessor_Stop succeeded.

DSPProcessor_Load succeeded.

DSPProcessor_Start succeeded.

Hit any key to terminate cexec.

But when I try to load a video or something, such as a youtube video, it fails with a known error. I tried swapping out the media_profiles.xml in our device from the cm7 one to the omapzoom zoom2 one, but no dice.

Non-HD youtube plays fine & fast even in full screen. It probably did before tho too :/

That infernal touchscreen issue is still here... :( Next to play with is probably sound as a lot of the OMX errors seem to be audio related.
[Nook Color Android Development] Dj-Gutz:
Getting closer to official sources

Another release from Lenovo , only this time it's not a leak but an OTA

No sources yet though , but I'm keeping my eyes open :)

ftp://lenovo.download.akamai.com/slates/a1/ICS_OTA/

login: slatesftp

pass: sprt!42tes