2850 replies to this topic

[ejtagle]

Well, i found out that the CSR chipset used in the Atheros Bt/Wifi combo can be switched from BCSP to the H4 protocol, thus, making it compatible with bluedroid... At least, that is what can be assumed by reading the following site ... http://www.penguin.c.../psion5mx/blue/

Apparently, sending an initialization command to set the PSKEY_HOST_INTERFACE to 3 would do the trick for us..

Edited by ejtagle, 14 January 2013 - 01:48 PM.

[Scanno]

ejtagle, on 14 January 2013 - 01:47 PM, said:

Well, i found out that the CSR chipset used in the Atheros Bt/Wifi combo can be switched from BCSP to the H4 protocol, thus, making it compatible with bluedroid... At least, that is what can be assumed by reading the following site ... http://www.penguin.c.../psion5mx/blue/

Apparently, sending an initialization command to set the PSKEY_HOST_INTERFACE to 3 would do the trick for us..

That would be nice. I had a chat whith shane francis a while back. he is the cm maintainter for the  vega and he gave me this link regarding bt.

https://github.com/A...38ffb6f596f35c3

perhaps you can do something with this?

[ejtagle]

Scanno, on 14 January 2013 - 03:48 PM, said:

That would be nice. I had a chat whith shane francis a while back. he is the cm maintainter for the  vega and he gave me this link regarding bt.

https://github.com/A...38ffb6f596f35c3

perhaps you can do something with this?

The link is adding support for the broadcom based chipset of the Asus transformer. Already have that in place for a tablet (DVC10) that has the broadcom chipset ... Unfortunately, this does not apply to our chipset (Atheros/BlueChip combo)... The way the BlueChip handles power management is completely different. It is more automatic, does not require programming as the Broadcom does...

[Scanno]

In CM10.1 i am getting the following error when compiling the huawei ril:

In file included from device/nvidia/shuttle/huawei-generic/requestdatahandler.c:105:0:
hardware/ril/libril/ril_commands.h:65:59: error: 'responseStringsNetworks' undeclared here (not in a function)
hardware/ril/libril/ril_commands.h:65:5: warning: missing initializer [-Wmissing-field-initializers]
hardware/ril/libril/ril_commands.h:65:5: warning: (near initialization for 's_commandInfo[48].responseFunction') [-Wmissing-field-initializers]
make: *** [/home/x/cm10.1/out/target/product/shuttle/obj/SHARED_LIBRARIES/libhuaweigeneric-ril_intermediates/requestdatahandler.o] Error 1
make: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/x/cm10.1/kernel/nvidia/shuttle'
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c: In function 'print_simansw':
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c:3038:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c: In function 'decodeUSSD':
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c:6116:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]

EDIT:
Seem to have resolved the compile error by adding:
#define responseStringsNetworks dummyResponse

to requestdatahandler.c

Edited by Scanno, 16 January 2013 - 08:55 PM.

[ejtagle]

Scanno, on 16 January 2013 - 08:24 PM, said:

In CM10.1 i am getting the following error when compiling the huawei ril:

In file included from device/nvidia/shuttle/huawei-generic/requestdatahandler.c:105:0:
hardware/ril/libril/ril_commands.h:65:59: error: 'responseStringsNetworks' undeclared here (not in a function)
hardware/ril/libril/ril_commands.h:65:5: warning: missing initializer [-Wmissing-field-initializers]
hardware/ril/libril/ril_commands.h:65:5: warning: (near initialization for 's_commandInfo[48].responseFunction') [-Wmissing-field-initializers]
make: *** [/home/x/cm10.1/out/target/product/shuttle/obj/SHARED_LIBRARIES/libhuaweigeneric-ril_intermediates/requestdatahandler.o] Error 1
make: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/x/cm10.1/kernel/nvidia/shuttle'
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c: In function 'print_simansw':
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c:3038:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c: In function 'decodeUSSD':
device/nvidia/shuttle/huawei-generic/huaweigeneric-ril.c:6116:2: warning: pointer targets in return differ in signedness [-Wpointer-sign]

EDIT:
Seem to have resolved the compile error by adding:
#define responseStringsNetworks dummyResponse

to requestdatahandler.c

You did the right thing. Seems CM10.1 is not using the latest ril.h header from AOSP, probably, attempting to gain compatibility with older binary-only rils required to make some modems from older cellphones work, Í'd suggest using

#ifndef responseStringsNetworks
#define responseStringsNetworks dummyResponse
#endif

so you could unify the jb4.2 and Cm10.1 sources, at least on the RIL sources

[fosser2]

Hey guys,

We're in the process of getting CM10.1 running on the g-tablet but we're having some issues with crashing of the bootanimation. The boot animation will play 1 loop then it will crash. Here is the pastebin of the crash.
http://pastebin.com/jCQpGCs4

It seems the prop libs are causing the issue here and I was wondering if you guys had any issues using your libs on 4.2. The libs are designed for 4.0 so we're really pushing that limit. I'm also seeing a few of these errors in logcat

21:57:29.674 Error gralloc 111  Failed to create overlay for display 2
21:57:29.907 Error gralloc 111  NvGrPost: Failed, TEGRA_DC_EXT_FLIP 6 No such device or address

Any help would be greatly appreciated!

[ejtagle]

fosser2, on 22 January 2013 - 04:11 AM, said:

Hey guys,

We're in the process of getting CM10.1 running on the g-tablet but we're having some issues with crashing of the bootanimation. The boot animation will play 1 loop then it will crash. Here is the pastebin of the crash.
http://pastebin.com/jCQpGCs4

It seems the prop libs are causing the issue here and I was wondering if you guys had any issues using your libs on 4.2. The libs are designed for 4.0 so we're really pushing that limit. I'm also seeing a few of these errors in logcat

21:57:29.674 Error gralloc 111 Failed to create overlay for display 2
21:57:29.907 Error gralloc 111 NvGrPost: Failed, TEGRA_DC_EXT_FLIP 6 No such device or address

Any help would be greatly appreciated!

No, i have no problems ... i am using the already posted libs with a JB4.2 image. I also have sometimes the "cannot create display overlay error (display 2 does not exist.. and also the TEGRA_DC_EXT_FLIP error. They are not related to using the 4.0 libs in the 4.2 android image. I think they could be related to having compiled support for other framebuffer devices in kernel)

4.0 libs should work with 4.2 android (provided you used the patches i posted!). Remember android uses OpenGL, and requirements have not changed. I assume the bootanim crash could be caused by an out of memory condition, need dmesg to be sure... Or a compilation without the proper flags. I see libskia.so mapped into the crashing process...

Take a look at either scanno's github or at the N10 lunch target i posted for the advent2 on this same forum...

REgrds, Eduardo

[fosser2]

ejtagle, on 22 January 2013 - 01:55 PM, said:

No, i have no problems ... i am using the already posted libs with a JB4.2 image. I also have sometimes the "cannot create display overlay error (display 2 does not exist.. and also the TEGRA_DC_EXT_FLIP error. They are not related to using the 4.0 libs in the 4.2 android image. I think they could be related to having compiled support for other framebuffer devices in kernel)

4.0 libs should work with 4.2 android (provided you used the patches i posted!). Remember android uses OpenGL, and requirements have not changed. I assume the bootanim crash could be caused by an out of memory condition, need dmesg to be sure... Or a compilation without the proper flags. I see libskia.so mapped into the crashing process...

Take a look at either scanno's github or at the N10 lunch target i posted for the advent2 on this same forum...

REgrds, Eduardo

Eduardo,

I appreciate the reply. For reference here is what I'm seeing in my serial dump (dmesg).
http://pastebin.com/L5ZEVVrU
The error occurs on lines 994-1248. Above you mentioned that there were some flags that needed to be properly set. I looked through scanno's git but didn't see anything sticking out too much to me. Can you point me in the right direction there? Thank you for your help.

-fosser2

[ejtagle]

fosser2, on 22 January 2013 - 06:13 PM, said:

Eduardo,

I appreciate the reply. For reference here is what I'm seeing in my serial dump (dmesg).
http://pastebin.com/L5ZEVVrU
The error occurs on lines 994-1248. Above you mentioned that there were some flags that needed to be properly set. I looked through scanno's git but didn't see anything sticking out too much to me. Can you point me in the right direction there? Thank you for your help.

-fosser2

Those errors means you ran out of video memory... The problem is that, while bootanimation was allocating video surfaces (probably OpenGL ES textures), there was no more video memory available to allocate the required ones. Usually, that results in the app trying to allocate textures crashing (specially is it does not check for NULL pointers to textures, as that is the way opengl informs it failed to allocate the surface). When you see

>Full compaction triggered
followed by
>Relocated 0 chunks,

that means you ran out of video memory. The kernel tries desperately to garbage collect unused video memory fragments to try to fullfill the user request, but, as all textures are being used, it fails (Relocated 0 chunks) ...

You need to allocate more video memory. That is the only way to fix this problem...

[ejtagle]

Regarding misc work i am doing in the kernel side for vega:

Posting 3 things, not tested yet. I have to build a full rom for the vega to try some of them:

1) Simple IO scheduler (SIO). Tries to improve latency and throughput from access to the mmc card. Untested, but it should work. Just select it in the block layer kernel config.. It is said to be the best IO scheduler for android when using it for common tasks

2) Lulzactiveq: And improved cpufreq that tries to get the most interactive performance by using the less possible power. It is said to be the best , but could require some parameter tunings. Should be safe to try

3) Tegra2 overclocking to 1.7Ghz and GPU overclocking to 400Mhz. This is completely untested, and it could be dangerous. I ported it from the NotionInk Adam kernel, and the 1.7Ghz setting was taken from the CM7 kernel. I haven't tried this yet. I would appreciate if someone could take a look at the code and tell me if something seems suspicious or wrong. As soon as i build a ROM for the Vega, i will try it myself. (i need to be able to build from AOSP in order to start debugging the modifications i did to the bluedroid stack in order to test and fix it)

Regards,
Eduardo

Attached Files

•  simple io scheduler.rar   4.23K   1 downloads
•  lulzactiveq cpufreq.rar   17.72K   1 downloads
•  oc to 1.7Ghz.rar   54.88K   6 downloads

[Scanno]

@EJTagle,

Thanks for the updates on the kernel. I am building a new version of CM10.1 that includes the kernel with the SIO schedular added and set as default schedular. As soon as it is ready i will post it as an experimental version so people can try it out. Did not add the other two additions yet.

[Scanno]

Eduardo, I have added the SIO scheduler to the kernel and it seems to speed things up. I have also added the new governor and that seems to work also but I have not tested it very well yet. I am not able to set it as the default governor. If I do I an not able to boot.

The over clock I have not tested added yet.

[fosser2]

Eduardo,

Thank you very much for the help with the out of memory error. Increasing our GPU memory from 85 to 128 solved that issue. Was hoping we could run 4.2 with 85M because that really helped on 4.1.2 with free memory. We did run into 1 more big issue with 4.2. Our tablet uses LP1 because LP0 is not supported due to the processor revision. Basically the tablet will go to sleep then after like 0.090 seconds it will snap back awake. It will basically loop this over and over until the tablet is "woken" up by the power button. From our previous releases the tablet will go into LP1 and stay there like it should. I'm trying to figure out what is waking it up. I do not believe this is a wakelock issue because the tablet DOES actually go into LP1 mode, its just something kicking it out of the mode. Here is a dmesg of the tablet sleeping and waking.

http://pastebin.com/1C8UsFH0

Starting around line 1031 you can see the "sleep loop." Any help on that would be greatly appreciated.

EDIT: I have tried this on both AOSP and CM10.1 The issue is on both roms.

-fosser2

Edited by fosser2, 27 January 2013 - 08:27 PM.

[ejtagle]

fosser2, on 27 January 2013 - 08:25 PM, said:

Eduardo,

Thank you very much for the help with the out of memory error. Increasing our GPU memory from 85 to 128 solved that issue. Was hoping we could run 4.2 with 85M because that really helped on 4.1.2 with free memory. We did run into 1 more big issue with 4.2. Our tablet uses LP1 because LP0 is not supported due to the processor revision. Basically the tablet will go to sleep then after like 0.090 seconds it will snap back awake. It will basically loop this over and over until the tablet is "woken" up by the power button. From our previous releases the tablet will go into LP1 and stay there like it should. I'm trying to figure out what is waking it up. I do not believe this is a wakelock issue because the tablet DOES actually go into LP1 mode, its just something kicking it out of the mode. Here is a dmesg of the tablet sleeping and waking.

http://pastebin.com/1C8UsFH0

Starting around line 1031 you can see the "sleep loop." Any help on that would be greatly appreciated.

EDIT: I have tried this on both AOSP and CM10.1 The issue is on both roms.

-fosser2

wakeup wake lock: power-supply

It is a wake lock. I have been fooled by the same behaviour a lot of times.. Probably the wake lock system is cancelling the LP1 sleep...

Regarding the lack of ram... zRam will be your friend in a short time

Edited by ejtagle, 27 January 2013 - 09:07 PM.

[fosser2]

ejtagle, on 27 January 2013 - 08:57 PM, said:

wakeup wake lock: power-supply

It is a wake lock. I have been fooled by the same behaviour a lot of times.. Probably the wake lock system is cancelling the LP1 sleep...

Regarding the lack of ram... zRam will be your friend in a short time

Ya we did get zRam set up and it does help a ton. Kinda sucks only having 512M ram but we're making do. As for system cancelling sleep do you have any more info on this? Would this be a rom or kernel related issue? I know the kernel provides wakelocks but I'm not really sure where to start looking.... Thank you.

[ejtagle]

fosser2, on 28 January 2013 - 01:29 AM, said:

Ya we did get zRam set up and it does help a ton. Kinda sucks only having 512M ram but we're making do. As for system cancelling sleep do you have any more info on this? Would this be a rom or kernel related issue? I know the kernel provides wakelocks but I'm not really sure where to start looking.... Thank you.

Seems to be kernel related. The definition of that wakelock is in drivers/power/power_supply_core.c. And the function that takes it is power_supply_changed(struct power_supply* psy)

That function is called by your battery/charger driver to inform linux the battery stats changed, or the charger status changed. Maybe you are calling from a timer, and you are forgetting to stop the timer when the kernel suspends. When the battery/charger driver is suspended, no calls to the power_supply_changed function should be done. In fact, you should NOT call this function unless there is a change in some value. Otherwise, you would be preventing the system to suspend by continuously holding a wakelock...

[fosser2]

ejtagle, on 28 January 2013 - 03:42 AM, said:

Seems to be kernel related. The definition of that wakelock is in drivers/power/power_supply_core.c. And the function that takes it is power_supply_changed(struct power_supply* psy)

That function is called by your battery/charger driver to inform linux the battery stats changed, or the charger status changed. Maybe you are calling from a timer, and you are forgetting to stop the timer when the kernel suspends. When the battery/charger driver is suspended, no calls to the power_supply_changed function should be done. In fact, you should NOT call this function unless there is a change in some value. Otherwise, you would be preventing the system to suspend by continuously holding a wakelock...

I disabled our battery code and charger code (smba-battery & gpio-charger.c). It is still looping through sleep mode, so I don't think that power_supply_changed is causing the issue. Here is a new paste of what is going on...

http://pastebin.com/FpNHgB4j

The only thing that I can really see in that log is this:

<6>Wake24 for irq=362
<6>Disabling wake24
<6>gpio bank wake found: wake24 for irq=119
<6>Disabling wake24

IRQ 362 is "GPIO  power" according to the IRQ dump that I made. Do you see anything else in that log that I may be missing? Thanks for the reply.

Edited by fosser2, 28 January 2013 - 04:53 AM.

[ejtagle]

fosser2, on 28 January 2013 - 04:00 AM, said:

I disabled our battery code and charger code (smba-battery & gpio-charger.c). It is still looping through sleep mode, so I don't think that power_supply_changed is causing the issue. Here is a new paste of what is going on...

http://pastebin.com/FpNHgB4j

The only thing that I can really see in that log is this:

<6>Wake24 for irq=362
<6>Disabling wake24
<6>gpio bank wake found: wake24 for irq=119
<6>Disabling wake24

IRQ 362 is "GPIO  power" according to the IRQ dump that I made. Do you see anything else in that log that I may be missing? Thanks for the reply.

By disabling the battery driver, you removed one of the wakelock that was causing trouble... But, now, there is another one:

wakeup wake lock: event1-354 ...

That name seems to be generated from something. We have to figure out the culprit here... Buyt, still the problem is a wakelock... What I usually do is to grep though all kernel sources looking for usages of wake_lock_init(), looking for that particular wakelock name to figure out the culprit... If not found, it could be the android framework or an application...
Also, do

echo 15 > /sys/module/wakelock/parameter/debug_mask
echo 1 > /sys/module/kernel/parameters/initcall_debug

And increasing printk verbosity to all is not a bad idea here...

Edited by ejtagle, 28 January 2013 - 12:53 PM.

[fosser2]

ejtagle, on 28 January 2013 - 12:40 PM, said:

By disabling the battery driver, you removed one of the wakelock that was causing trouble... But, now, there is another one:

wakeup wake lock: event1-354 ...

That name seems to be generated from something. We have to figure out the culprit here... Buyt, still the problem is a wakelock... What I usually do is to grep though all kernel sources looking for usages of wake_lock_init(), looking for that particular wakelock name to figure out the culprit... If not found, it could be the android framework or an application...
Also, do

echo 15 > /sys/module/wakelock/parameter/debug_mask
echo 1 > /sys/module/kernel/parameters/initcall_debug

And increasing printk verbosity to all is not a bad idea here...

Here is a dump with the 2 echo commands run. I will start grepping the kernel source looking for the wake lock.
http://pastebin.com/gvRSK5xU

Thanks for the help so far!

Edited by fosser2, 28 January 2013 - 06:53 PM.

[ejtagle]

fosser2, on 28 January 2013 - 06:41 PM, said:

Here is a dump with the 2 echo commands run. I will start grepping the kernel source looking for the wake lock.
http://pastebin.com/gvRSK5xU

Thanks for the help so far!

Several wakelocks are preventing the tablet to enter suspend... Not all of them at the same time. I suggest to disable wlan ... There is an option to keep tablet awake while wlan is active. Make sure it is not checked. Sometimes, the alarm wakelock prevents the tablet to enter suspend. That is perfectly normal, as android wakes periodically to check for emails (gmali, dropbox sync, etc). There is also the PowerManagerService sometimes preventing the tablet to enter suspend.

My suggestion is to test suspend without gapps installed, with wlan disabled.... Without the charger plugged in and without usb plugged in...