Advent Vega kernel source code now available!

[Guest devurandom]

-deleted -

Edited September 22, 2011 by devurandom

[Guest redscorpion]

If you give me the video format that is being used by the recorder while recording, we can easily swap blue by red tints (it is just U plane swapped with V plane) ... Arghh.. I wish Google had documented the video formats .... In a sensible way, and enforced manufacturers to obey those definitions...

Thanks to all the people who has tested/worked on this - The cameralib is , right now, the collective result of all that hard work :D !

Regards,

Eduardo

Hi Eduardo,

great job!

Now we have two working camera libraries ;-)

Recorder also works fine for me... and for recording recorder uses the yuv420p format - it should be YCrCb, but for some reason the OMX encoder needs YCbCr... I've noticed that problem some time ago...

Kamil

BTW: My here is my latest camera... ;-)

libcamera.so.zip

camera_src.zip

[Guest ejtagle]

Well, here we go!... This is my latest version of the libcamera. Pretty much the same as the previous one, but fixes colors in the video recordings (yes, i was able to make video recording work on my tablet... Seems, somehow, one the libraries got corrupted. Eventually, reinstalling modstock and then the VC9 fixed the problems...) ...

Well, there's not too much left to do regarding kernel development... All major issues are fixed right now (and the ones that are not, probably can't be fixed... ie, LP0 that requires a new bootloader that we dont' have ... or the EMC freq scaling. Both things are not critical at all, and i doubt they would improve standby battery time under normal use of a tablet... )

Well, there's not too much to say... HDMI problems are probably not related to kernel itself, accelerometer issues seems more to be related to differences between android apps that were not targetting tablets... so they don't work optimally on them... There are a bunch of problems probably caused by corrupted installations, or to some degree, caused by restoring backups from previous Android versions... or application incompatibilities...

If some of you have something in mind that should be fixed, please tell... will discuss it and try to fix if it is an actual bug!

Thanks to all the people involved in this project, HC3.x would be just a dream without the added and continuous effort of all us (and, i may say, if you really want to know how much time it takes to do something such as incredible as this, you should be involved in development ;) -- Honestly, i can-t believe how far this has come, taking into account no HC source code is available!

Well, thanks to all, it was and is a pleasure to be part of this,

Eduardo

uvc4.rar

uvc4-compiled.rar

[Guest pdotb]

Eduardo,

I know LOTS of people have been involved in this project and I thank them all, but I wanted to personally thank you for the huge numbers of hours you've put in to getting the kernel side of things better.

I sent you a little beer money in gratitude.

My company makes embedded ARM devices all the time, so what are the problems on the bootloader side?

Is setup of much of the Tegra done in the bootloader or just once Linux kicks in?

What other things (other than the rewind to last good image button combo) and obvious clock and RAM timing set up needs doing?

[Guest pizzaboy75]

If some of you have something in mind that should be fixed, please tell... will discuss it and try to fix if it is an actual bug!

There seems to be a problem when i try to tether my phone to the vega via bluetooth now. According to the Forums others are also experiencing this. Worked in 8.1. I have attached a log i made while trying to connect to my phone.

bluez.log.zip

Otherwise I am really impressed by the work of the whole Team! You really did an amazing job over the last few weeks.

[Guest WWEpsp]

If some of you have something in mind that should be fixed, please tell... will discuss it and try to fix if it is an actual bug!

hey, Cass67 told me to send him some logcats connecting to EAP wifi spots so he can solve the problem of vegacomb not connecting to EAP.

This use to work on Vegacomb 1.7 that was based on Android 3.0, so maybe you could mix libraries or something like that.

Anyway if you can please see this logs :P

Hey Cass67(or any other dev) i have my logdogs :P (i know its a bad joke) right over here.

There are 3 files logs, one trying to connect to the spot, and the other 2 are configuring the connection(from 0) and trying connect to the wifi-spot(named UPVNET or UPVNET2, cant remember which i tried). I made two because one has the wifi word filter and the other one doesnt have it.

so this is the first one: alogcat.2011-09-24-11-04-44+0100.txt

this is the second one: alogcat.2011-09-24-11-12-28+0100.txt

third one: alogcat.2011-09-24-11-16-04+0100.txt

hope they help you, i dont know how you gonna read that, 'cause its seems way difficult :P

And of course, thank you...

P.D: Consider the wifi configurations of Vegacomb 1.7(Android 3.0)

Again a HUGE thanks for the work, and for the awesome usb host app, WOW it just changes so fast into a mode or another...

[Guest ejtagle]

Eduardo,

I know LOTS of people have been involved in this project and I thank them all, but I wanted to personally thank you for the huge numbers of hours you've put in to getting the kernel side of things better.

I sent you a little beer money in gratitude.

My company makes embedded ARM devices all the time, so what are the problems on the bootloader side?

Is setup of much of the Tegra done in the bootloader or just once Linux kicks in?

What other things (other than the rewind to last good image button combo) and obvious clock and RAM timing set up needs doing?

The problem with the bootloader is related to a bug in the bootrom the Tegra2 part (i mean, the hardware revision of the Tegra2 chipset that is used in Shuttle) has. LP0 in Tegra2 is a mode where all the chip is supposed to be shutdown. I tend to see it as a extremely low power suspend to RAM , as the CPU is shut down, all SOC peripherals are shut down... But, the SDRAM is kept in self refresh mode, so it does not lose its contents.

The hw supports a limited set of wake up sources... In the shuttle case, we can use hw keys (the buttons) to do it. But, when resuming, the bootrom kicks in, as the CPU was shut down, so it seems to be a reset ... But, the bootrom should see it was caused not by a turn off of the device, rather than as a resume from LP0, and, instead of reloading the linux kernel, it should take out of self refresh the SDRAM, and jump to the resume vector of the kernel.

The bug is that the bootrom is unable to take out of self refresh the sdram in a proper way.. This was handled by Nvidia with a patch to the bootloader (the bootrom loads from NAND a bootloader and executes it. In turn, that bootloader loads the linux kernel, or loads using USB if no kernel image is found in NAND)

The bootloader has a patch that seems not to be working. That patch detects the LP0 resume and should do what the bootrom failed to do... But it does not work... Or at least, we failed to make it work.

Rewriting a bootloader is a hard thing, as there is absolutely no documentation on the Nvidia Tegra2 ... Except under NDA agreements That is the main problem here... Absolute lack of documentation. I won't go telling the problems i had to face when i had to fix USB host mode. All i had was a header from NVidia (that is part of the linux kernel) telling register names and bits, but absolutely no explanation on the way it works... Arggg.... :(

So, perhaps, i will try again to make LP0 work, but i don't know if it is even possible to make it work in this Hw revision of Tegra2. NVidia simply says that LP0 is unsupported on this Hw revision...

Eduardo

[Guest Cass67]

hey, Cass67 told me to send him some logcats connecting to EAP wifi spots so he can solve the problem of vegacomb not connecting to EAP.

This use to work on Vegacomb 1.7 that was based on Android 3.0, so maybe you could mix libraries or something like that.

Anyway if you can please see this logs :P

Thanks, the logs dont really tell much except that it selects peap then disconnects for whatever reason ... Can you provide the /data/misc/wifi/wpa_supplicant.conf too ? id like to see how its setup with regards to this network ... obscure any personal details of course but leave the rest of the detail in there ... it could be that you have to edit this file by hand ...

What protocols does your wifi network use for authentication MS-Chap ?

How do you add the network in android, does it auto detect the wifi and then you click on it ? have you tried adding a new network by hand and inputting the detail like that?

Cheers

[Guest WWEpsp]

Thanks, the logs dont really tell much except that it selects peap then disconnects for whatever reason ... Can you provide the /data/misc/wifi/wpa_supplicant.conf too ? id like to see how its setup with regards to this network ... obscure any personal details of course but leave the rest of the detail in there ... it could be that you have to edit this file by hand ...

What protocols does your wifi network use for authentication MS-Chap ?

How do you add the network in android, does it auto detect the wifi and then you click on it ? have you tried adding a new network by hand and inputting the detail like that?

Cheers

Ok, gonna get it with root explorer and send it back to you in an hour or so (i cant now), i imagine i can open it like other txt, can i?

I connect to the network by previously selecting it from the list, i mean is discoverable. I tried to configure the network from wifi advanced configurator without detecting it and then actually try to connect and nothing...

Phase 2 authentication is MSCHAPV2.

BTW, when i select to modify the network it doesnt appear filled the phase2 aunthentication type its says none, maybe its no getting well saved...

Edited September 23, 2011 by WWEpsp

[Guest rebel1]

Well... Those are very good news! ... And i also have another "fix".. mrz_hun and i , now with the IT7260 datasheet at hand, we both realized there was a bug in the IT7260 touchscreen driver. The Calibration command was not properly formed , so the command sent when asking for touchscreen calibration was not that command. Instead we were sending an undefined command ... So, esentially, no calibration of the touchscreen was done, even if the user triggered it.

Now, using the datasheet we have, i have fixed that, so it is possible to do touchscreen calibration, and the right command is sent to the touchscreen controller. No other changes, except, maybe, fixing deinitialization of power management of wlan/bt....

Attached my latest version. I really hope this time this will solve the touchscreen issues some people are having ;)

Regards,

Eduardo

Regarding accelerometer, dont forget to use my patched accelerometer library ;) ... And, we could, if needed, speed the accelerometer updates a bit... Right now, we are getting 25 readings per second...

Now. to the libcamera ;)

Hi Eduardo,

unfortunately we have a bug in the latest patch set, because I wondered this day that my battery is draining faster than before.

So I look to the kernel log and see that my Pov did not go really to suspend:

[  531.419490] platform reg-dummy: LATE suspend

[  531.419517] power power.0: LATE suspend

[  531.419589] pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11

[  531.419626] PM: Device power.0 failed to suspend late: error -11

[  531.419665] platform reg-dummy: EARLY resume

[  531.419695] tegra-i2c tegra-i2c.0: EARLY resume

Suspend log

Rene

P.D.: This is not caused by the latest patch set, i test earlier builds and all have the same problem?!

But no one noticed it before,like me ??

Edited September 23, 2011 by rebel1

[Guest CoWPlagued]

Hi Eduardo,

unfortunately we have a bug in the latest patch set, because I wondered this day that my battery is draining faster than before.

So I look to the kernel log and see that my Pov did not go really to suspend:

P.D.: This is not caused by the latest patch set, i test earlier builds and all have the same problem?!

But no one noticed it before,like me ??

I had also noticed this, but hadn't really looked into it as I generally leave it on the dock over night, and then use it throughout the day. If you just leave it "suspended" there's little difference to it being on other than the screen being off, everything continues to run, notifications still sound and if you check the battery usage I find that "Android OS" has used just about all of the battery.

While I'm rambling, I looked into the microphone noise issue.

I've chucked on alsa_amixer and had a play bout with the levels. The mic boost is definitely causing the issues. Changing the mic volume doesn't seem to make much difference, but the mic boost resolves the issue, but unfortunately the boost level jumps from 33% to 67% and you don't seem to be able to set anything in-between. 33% seems a little quiet, but definitely solves the large background noise, a value of about 45% maybe a happy medium but doesn't seem to be supported. I've not looked into why this may be the case, but if I get a moment I'll have a look. I might also write a quick app to let us change the mic settings from a gui.

Cheers

[Guest ejtagle]

Hi Eduardo,

unfortunately we have a bug in the latest patch set, because I wondered this day that my battery is draining faster than before.

So I look to the kernel log and see that my Pov did not go really to suspend:

[  531.419490] platform reg-dummy: LATE suspend

[  531.419517] power power.0: LATE suspend

[  531.419589] pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11

[  531.419626] PM: Device power.0 failed to suspend late: error -11

[  531.419665] platform reg-dummy: EARLY resume

[  531.419695] tegra-i2c tegra-i2c.0: EARLY resume

Suspend log

Rene

P.D.: This is not caused by the latest patch set, i test earlier builds and all have the same problem?!

But no one noticed it before,like me ??

Now, that you point it out, yes.. I was investigating this.. But, in the rush to make USB host work, i just forgot about that.. There is a device that is preventing the tablet to suspend, but that device is not one of the listed ones. Seems to be a core device, as it is not listed at all... The approach i'd take would be to modify the function platform_pm_suspend_noirq in base/platform.c to print the returned value and the device name (the name is available in the device struct) so we know what device is causing trouble... And then, fix the device ;) -- Will try to do it later...

Eduardo

[Guest ejtagle]

I had also noticed this, but hadn't really looked into it as I generally leave it on the dock over night, and then use it throughout the day. If you just leave it "suspended" there's little difference to it being on other than the screen being off, everything continues to run, notifications still sound and if you check the battery usage I find that "Android OS" has used just about all of the battery.

While I'm rambling, I looked into the microphone noise issue.

I've chucked on alsa_amixer and had a play bout with the levels. The mic boost is definitely causing the issues. Changing the mic volume doesn't seem to make much difference, but the mic boost resolves the issue, but unfortunately the boost level jumps from 33% to 67% and you don't seem to be able to set anything in-between. 33% seems a little quiet, but definitely solves the large background noise, a value of about 45% maybe a happy medium but doesn't seem to be supported. I've not looked into why this may be the case, but if I get a moment I'll have a look. I might also write a quick app to let us change the mic settings from a gui.

Cheers

That is what i was fearing... the ALC supports 20 db boost, 40db boost and no boost. 40 db is what is selected by default. 20db seems a bit low... a value in between is not possible... perhaps, using 40db and lowering the mic recording level ? ---

[Guest armdroid]

Hi Eduardo and the rest of the team.

Great work on the Kernel and Vegacomb. I've been using the kernel for a MeeGo port I'm helping out with:

Forgive the upside-down-ness but here's a video of it in action. I fire up QtCreator and make an example.

The filesystem lives on a partition on the SD card, I wonder if there's any interest in a dual-boot system?

[Guest Cass67]

Hi Eduardo and the rest of the team.

Great work on the Kernel and Vegacomb. I've been using the kernel for a MeeGo port I'm helping out with:

Forgive the upside-down-ness but here's a video of it in action. I fire up QtCreator and make an example.

The filesystem lives on a partition on the SD card, I wonder if there's any interest in a dual-boot system?

From my perspective there is an interest for sure ... but are you proposing to make a secondary boot loader to select on boot or checking to see if we are interested in helping out with one ?

Cheers

Cass

[Guest armdroid]

From my perspective there is an interest for sure ... but are you proposing to make a secondary boot loader to select on boot or checking to see if we are interested in helping out with one ?

Cheers

Cass

I'm very new to kernel/ROM hacking (I must thank vgrade for his assistance in getting me this far), so maybe a bit of both.

Here's some files and instructions if anyone's interested in playing around (won't mess with your vegacomb, well except the boot partition of course, unless you're already fastbooting).

Kernel:

http://dl.dropbox.co...17108768/zImage

Kernel (framebuffer console for debugging):

http://dl.dropbox.co...68/zImage-fbcon

Kernel config:

http://dl.dropbox.co...68/config-meego

Kickstart file:

http://dl.dropbox.com/u/17108768/tablet-armv7hl-tegra2-v02-1.2.0.0.0.20110518.3.ks

Initrd:

http://dl.dropbox.co...nitrd-noinit.gz

Kernel modules:

http://dl.dropbox.co...6.3-modules.bz2

ar6000 fw:

http://dl.dropbox.co...o-ar6000-fw.bz2

install mic2 (meego-image-creator)

my command line:

sudo mic-image-creator --config=meego-vega.ks --arch=armv7hl --format=raw --logfile=mic-test-tablet-1.2.0.log --run-mode=1

--run-mode=1 is needed if running on Ubuntu.

This should make a disc image that ends in "-mmcblk0p.raw"

dd this to your sd card, e.g.:

sudo dd bs=4096 if=meego-vega-mmcblk0p.raw of=/dev/sdb

untar the kernel modules and ar6000 fw to the root of your sd card.

I use fast boot (http://android.modac...-your-vega-dev/) with the following commandline:

fastboot -i 0x955 -c "root=/dev/mmcblk0p2 rootdelay=15 noinitrd video=tegrafb rw mem=512M@0M vmalloc=192M udev.log-priority=debug udev.children-max=1 usbcore.old_scheme_first=1 mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),155008K@23680K(system),32768K@179200K(cache),4096K@212480K(staging),306688K@217088K(userdata)" boot zImage hardcoded-initrd-noinit.gz

It should boot up to the UI and you should be able to plug in a mouse and/or keyboard. The first boot can take ages and be pretty slow. OpenGL is in software currently, so that's also not great either. If it fails to boot up, use zImage-fbcon which will output debug info to the framebuffer (X will not start with framebuffer console).

You can ssh in as well, however I couldn't get the settings program to launch (or find how to launch wifi config) so if you can't figure this out either you can force a connection by adding (and changing) the following to sdcard/etc/rc.d/rc.local

SSID=MYSSID

PSWD=MYPSWD

STATIC_IP=SOMEIP

DEF_GATEWAY=MYGATEWAY

echo "ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel" > /tmp/wpa_supplicant.conf

wpa_passphrase $SSID $PSWD >> /tmp/wpa_supplicant.conf

cp /tmp/wpa_supplicant.conf /var/log/wpa_supplicant.conf-copy

sleep 10

ip link set wlan0 up

sleep 10

wpa_supplicant -B -Dnl80211,wext -dd -i wlan0 -c /tmp/wpa_supplicant.conf > /var/log/wpa_supplicant.log 2>&1

sleep 5

if [ "$STATIC_IP" = "" ] ; then

dhcpcd wlan0 > /var/log/dhcp-wlan0.log

else

ifconfig wlan0 $STATIC_IP

fi

sleep 5

route add default gw $DEF_GATEWAY wlan0

Edit: Added a ks file (tablet-armv7hl-tegra2-v02-1.2.0.0.0.20110518.3.ks) with cursor fix from vgrade (libmeegotouch).

Edited September 24, 2011 by armdroid

[Guest armdroid]

Do you think it might be possible to achieve this with a small change to the init program so that it reads one of the HW buttons? (or a fake init that launchs MeeGo kernel or else the real init)?

[Guest Cass67]

I'm very new to kernel/ROM hacking (I must thank vgrade for his assistance in getting me this far), so maybe a bit of both.

Here's some files and instructions if anyone's interested in playing around (won't mess with your vegacomb, well except the boot partition of course, unless you're already fastbooting).

Kernel:

http://dl.dropbox.co...17108768/zImage

Kernel (framebuffer console for debugging):

http://dl.dropbox.co...68/zImage-fbcon

Kernel config:

http://dl.dropbox.co...68/config-meego

Kickstart file:

http://dl.dropbox.co...8/meego-vega.ks

Initrd:

http://dl.dropbox.co...nitrd-noinit.gz

Kernel modules:

http://dl.dropbox.co...6.3-modules.bz2

ar6000 fw:

http://dl.dropbox.co...o-ar6000-fw.bz2

install mic2 (meego-image-creator)

my command line:

sudo mic-image-creator --config=meego-vega.ks --arch=armv7hl --format=raw --logfile=mic-test-tablet-1.2.0.log --run-mode=1

--run-mode=1 is needed if running on Ubuntu.

This should make a disc image that ends in "-mmcblk0p.raw"

dd this to your sd card, e.g.:

sudo dd bs=4096 if=meego-vega-mmcblk0p.raw of=/dev/sdb

untar the kernel modules and ar6000 fw to the root of your sd card.

I use fast boot (http://android.modac...-your-vega-dev/) with the following commandline:

fastboot -i 0x955 -c "root=/dev/mmcblk0p2 rootdelay=15 noinitrd video=tegrafb rw mem=512M@0M vmalloc=192M udev.log-priority=debug udev.children-max=1 usbcore.old_scheme_first=1 mtdparts=tegra_nand:2048K@6784K(misc),5120K@9344K(recovery),8192K@14976K(boot),155008K@23680K(system),32768K@179200K(cache),4096K@212480K(staging),306688K@217088K(userdata)" boot zImage hardcoded-initrd-noinit.gz

It should boot up to the UI and you should be able to plug in a mouse and/or keyboard. The first boot can take ages and be pretty slow. OpenGL is in software currently, so that's also not great either. If it fails to boot up, use zImage-fbcon which will output debug info to the framebuffer (X will not start with framebuffer console).

You can ssh in as well, however I couldn't get the settings program to launch (or find how to launch wifi config) so if you can't figure this out either you force a connection by adding (and changing) the following to sdcard/etc/rc.d/rc.local

SSID=MYSSID

PSWD=MYPSWD

STATIC_IP=SOMEIP

DEF_GATEWAY=MYGATEWAY

echo "ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel" > /tmp/wpa_supplicant.conf

wpa_passphrase $SSID $PSWD >> /tmp/wpa_supplicant.conf

cp /tmp/wpa_supplicant.conf /var/log/wpa_supplicant.conf-copy

sleep 10

ip link set wlan0 up

sleep 10

wpa_supplicant -B -Dnl80211,wext -dd -i wlan0 -c /tmp/wpa_supplicant.conf > /var/log/wpa_supplicant.log 2>&1

sleep 5

if [ "$STATIC_IP" = "" ] ; then

dhcpcd wlan0 > /var/log/dhcp-wlan0.log

else

ifconfig wlan0 $STATIC_IP

fi

sleep 5

route add default gw $DEF_GATEWAY wlan0

Nice, i may have a play with this when i have some time, wrt to software GL rendering, whats stopping the hw rendering, userland support? X? .36 should provide hw GL support, is meego not able to make use of that ? i thought also vgrade had the trimslice stuff working .. is this not the case ? i admit ive not followed meego too closely but last i looked he was happy we had .36 running and there was talk of the trimslice drivers being usefull ..

Cheers

Cass

[Guest Cass67]

Do you think it might be possible to achieve this with a small change to the init program so that it reads one of the HW buttons? (or a fake init that launchs MeeGo kernel or else the real init)?

its probably entirely possible to have a fake init display a menu as to what os to boot, we used fake init in HD2 android in the early days so what able to be scripted is able to be used ... the hard part is getting the hw keys or sw kb to respond ... i doubt very much this can be achieved without any real code .. This i fear will not be a quick solution ...

[Guest armdroid]

Nice, i may have a play with this when i have some time, wrt to software GL rendering, whats stopping the hw rendering, userland support? X? .36 should provide hw GL support, is meego not able to make use of that ? i thought also vgrade had the trimslice stuff working .. is this not the case ? i admit ive not followed meego too closely but last i looked he was happy we had .36 running and there was talk of the trimslice drivers being usefull ..

Cheers

Cass

Its still in it's infancy, you may run into problems like no cursor on-screen (has just happened to me now) and touchscreen working, but not delivering button presses to widgets (and it's spewing a load of debug info to the logs). Also the host usb mouse and keyboard support can be erratic (took a while to connect with X before I made that video), but please do have a play. I've just started trying out some HW gfx drivers, but I don't think they're working.

Although very rough around the edges, when I had a cursor on-screen and the mouse and keyboard working, running Qt Creator and being able to actually code and run on the device went surprisingly smoothly, a few config tweaks and it should be there again.

For now, I'm doing my vega specific tweaks in the %post part of the kickstart file. The turnaround with this is quite slow (rebuild image, dd it, copy in kernel modules and ar6000 fw), so instead you can ssh in, change config-ury things, then sudo telinit 3; sudo telinit 5 and it'll re-start the UX. The most important bugs at present are to do with the X config.

Edited September 24, 2011 by armdroid

[Guest CoWPlagued]

That is what i was fearing... the ALC supports 20 db boost, 40db boost and no boost. 40 db is what is selected by default. 20db seems a bit low... a value in between is not possible... perhaps, using 40db and lowering the mic recording level ? ---

I've worked out what the issue was with the Mic settings was, I was changing the wrong value. I was changing "Mic 2" and "Mic 2 Boost" where "Mic 2" did nothing, Setting the "Mic 2 Boost" back down to 20db and setting "Rec" to around 50% we get the same sound volume without the background hiss, a Rec of 60% gives us more volume than before with about the same background hiss we already have. The wave forms look a lot cleaner and voice commands seem better for me.

Unfortunately for me .. I mean my son, there's a loud click that happens each time the mic is initiated that triggers things like talking tom as it turns the mic on and hears the click and starts recording. Minor issue really and maybe not fixable.

[Guest ejtagle]

Now, that you point it out, yes.. I was investigating this.. But, in the rush to make USB host work, i just forgot about that.. There is a device that is preventing the tablet to suspend, but that device is not one of the listed ones. Seems to be a core device, as it is not listed at all... The approach i'd take would be to modify the function platform_pm_suspend_noirq in base/platform.c to print the returned value and the device name (the name is available in the device struct) so we know what device is causing trouble... And then, fix the device ;) -- Will try to do it later...

Eduardo

Turns out that the cause of the kernel not being able to suspend, is a wakelock.. To find exactly what wakelock is the culprit, you can do:

echo 15 > /sys/module/wakelock/parameters/debug_mask

And, when trying to suspend, the kernel will print out the problematic wakelock ...

I am at it right now ;)

Update: The wakelock called "event3-143" is the one preventing the kernel to enter suspend ... Tracing what kernel component is using it...

Update2: Found the culprit. It is a "race" condition between the suspend process and the accelerometer driver... Everytime the accelerometer driver sends an event, a wakelock is locked with timeout of 5 seconds (this happens in /drivers/input/evdev.c) ... So, as the accelerometer is posting 25 events per second, then, we can assume this wakelock called "event3-143" is being held all the time... effectively preventing the kernel to enter suspend mode. Even, if the accelerometer is disabled at suspend time (as it is right now), there is still 5 seconds remaining of locked wakelock. So, the suspend fails. As soon as the kernel fails to suspend, the accelerometer is reenabled and relocks the wakelock...

I will have to patch evdev.c, as with some input devices, it makes no sense to hold a wakelock for such a huge amount of time... This is probably a bug of the android kernel itself, but it does not show in any HC3.x as there, the used accelerometers are being exposed as files, and not as input devices, as it should be... Now, i have to figure out a way to fix this...

Edited September 24, 2011 by ejtagle

[Guest mrz_hun]

I was really hoping that 9n would cure my touchscreen problems, but unfortunately the problem is still appearing.

I have noticed the following:

• the touchscreen is not responsive after the device is powered off for a long period (hours)
• the touchscreen gradually regains full functionality after around 5 minutes of being powered on
• the touchscreen is fully functional after a full power off/ power on cycle if it was functional before the shutdown.
• touchscreen calibration does not cure it.

I have created the following kmsg dump, which points to an i2c problem...

kmsg dump

Can someone please explain what might be going on?

Edited September 24, 2011 by mrz_hun

[Guest ejtagle]

I was really hoping that 9n would cure my touchscreen problems, but unfortunately the problem is still appearing.

I have noticed the following:

• the touchscreen is not responsive after the device is powered off for a long period (hours)
• the touchscreen gradually regains full functionality after around 5 minutes of being powered on
• the touchscreen is fully functional after a full power off/ power on cycle if it was functional before the shutdown.
• touchscreen calibration does not cure it.

I have created the following kmsg dump, which points to an i2c problem...

kmsg dump

Can someone please explain what might be going on?

It is an i2c problem, but caused by the touchscreen controller... I don't know why, but seems like the touchscreen takes a long time to initialize... And it shouldn't. What you see in the logs is that the touchscreen controller is not responding to i2c commands... Are you absolutely sure this didn't happen with the original android 2.2 ROM ? -- Cause it could be a hw problem... "Not reasponding" means that some areas do not work, or that no screen area works at all ?

Regards,

Eduardo

[Guest ejtagle]

Well.. here it is the last kernel version:

-Fixes the sleep problems, as explained in the previous posts... It was an android bug, not a driver bug ...

-Fixes pops in audio capture and playback... No promises, but it works for me

-Tries to reduce noise in recording, using the tricks outlined by CowPlagued

-The camera defaults now to powered down. The libcamera will turn it on demand, saving power

Well, thats all

Eduardo

11.2.13-SLEEPFIX-POPFIX.rar