Advent Vega kernel source code now available!

[Guest Cass67]

Tried both commits, some code we already had .. i added / removed what was contained that was required and it made no diff here.. still same results ... keep trying though, good to have another set of eyes helping out :)

edit . may be worth looking to see if there is anything you can spot in LP1 that we dont have .. thats what we use ..

Cheers

Cass

Interestingly just tried LP2 mode .. that hangs up too, which im surprised about as it was suspected the lack of response to irq was the problem in waking up in LP1, LP2 mode should not shut down the irq controller or memory controller ..

Anyone know what the last component is to go to sleep ? thought it might be fun to let everything else be shutdown and add a wakelock to that device and keep it from suspending to see what occurs

edit :- so much for the irq controller not sleeping in LP2 .. emergency_restart() does not work in that mode either :( ach well worth a shot ....

Edited January 14, 2012 by Cass67

[Guest brucelee666]

Re. omx InsufficientResources message you had while testing, have you tried increasing the gpu memory to see if that has any effect ?

looking at code think its set to 90mb "#define SHUTTLE_GPU_MEM_SIZE (45*SZ_2M)", maybe setting it to 128m for a test or is that not possible due to ics memory requirements.

[Guest Cass67]

Re. omx InsufficientResources message you had while testing, have you tried increasing the gpu memory to see if that has any effect ?

looking at code think its set to 90mb "#define SHUTTLE_GPU_MEM_SIZE (45*SZ_2M)", maybe setting it to 128m for a test or is that not possible due to ics memory requirements.

Not in this test but i have done in the past tests as well as disabling dynamic allocation .... ill try again tomorrow with the last patches .. 128 would be my preferred size, i just got fed up updating this value everytime we had a patch :)

Cheers

Cass

Edited January 14, 2012 by Cass67

[Guest brucelee666]

Another couple of nvidia commits relating to suspend/resume, you may have seen and not implemented as not relevant but thought I would post link.

mfd: disable/enable irq in suspend/resume

This one slightly amends the one above:-

mfd: fix build warning

[Guest ejtagle]

Not in this test but i have done in the past tests as well as disabling dynamic allocation .... ill try again tomorrow with the last patches .. 128 would be my preferred size, i just got fed up updating this value everytime we had a patch :)

Cheers

Cass

I have tried up to 256Mbytes reserved as GPU memory... It justdon't decode video... I have to tell...there is a catch... ifyou are getting

OMX plugin failed w/ error 0x80001001

Probably a dependency lib is missing... At least, try my tool called demo_decode ... It is already compiled. Just push it into the device. The tool will try to load libnvomx.so, and even if you don't understand what it is doing, if the library can't be loaded for any reason, it will tell the exact cause. This is pretty important, as i think the green-fix libs had a dependency on a lib not present on the .zip package ... ;)

<div><br></div><div>Before trying to perform any tests, the first thing to check is that all dependencies of libnvomx.so are satisfied,otherwise, libnvomx won-t load atall, and no hw acceleratin of video is possible ;)</div>

Edited January 15, 2012 by ejtagle

[Guest DerArtem]

Hello All,

I was playing with some nvidia blobs and some minor kernel changes to get audio working on my folio.

And suddenly the folio went into sleep.

I have just removed a few nvidia audio blobs and changed one audio GPIO and suspend is working for me now.

There is just no chance to wake it up again yet...

I think that you might find it interesting as you have the same suspend problems like me...

Also for the video acceleration: If you think that that video decoding stuff is related to the amount of RAM you may get in touch with the ADAM guys. They have 1GB of RAM and are running basically the same kernel sources.

They could test if the nvidia blobs are working for them...

[Guest Areo]

@Cass,

If you want to help people with oversensitive touchscreen issues on ICS Alpha 2. (when charger is not plugged in). You need to revert these changes:

https://github.com/w...55e74dbe#diff-2

Also you may like to take a look @ this:

http://www.tabletrom....html#post46361

Kind Regards,

Areo

edit: only revert the changes for it7260.c

Edited January 15, 2012 by Areo

[Guest brucelee666]

Found this on the tiamat xoom ics kernel git, remember seeing a few pages ago stuff on mmc so thought I would post:-

tiamat xoom mmc bus update

Also has anyone tested removing all sleep/resume code/config from the source so nothing sleeps and then introduce them one at a time ?

For example set sleep/resume for screen only try to resume if it works then move on and add next and carry on until you hit one that stops resume, if it does not resume with just screen then maybe that tells you something.

I know gpio/irq/lp0/lp1 has been mentioned and smarter people then me have looked at this, just trying to post some things that may not have been seen that may help.

Edit - re. tiamat xoom ics kernel, I see back on page 55 cass mentioned that suspend was not a problem, if you look at the pm.c file in this kernel they seemed to have copied the suspend.c file into the 39 kernel or at least modified it to work (maybe thats why it worked):-

tiamat ics kernel pm file with suspend code

Edited January 15, 2012 by brucelee666

[Guest BillyBobJoe]

Yeah Cass, Ed, etc...

I expect that you have sen that there is a beta version of the ICS update for the Xoom. The guys over at XDA have a copy that you can grab.

It may helping your quest to get the Vega version running as the libraries shouldn't be to far away from full release versions.

Billy..

[Guest DerArtem]

ejtagle: have you also ported the nvec_event.c ?

We need this on the folio to get the power button work.

[Guest Cass67]

I have tried up to 256Mbytes reserved as GPU memory... It justdon't decode video... I have to tell...there is a catch... ifyou are getting

OMX plugin failed w/ error 0x80001001

Probably a dependency lib is missing... At least, try my tool called demo_decode ... It is already compiled. Just push it into the device. The tool will try to load libnvomx.so, and even if you don't understand what it is doing, if the library can't be loaded for any reason, it will tell the exact cause. This is pretty important, as i think the green-fix libs had a dependency on a lib not present on the .zip package ... ;)

<div><br></div><div>Before trying to perform any tests, the first thing to check is that all dependencies of libnvomx.so are satisfied,otherwise, libnvomx won-t load atall, and no hw acceleratin of video is possible ;)</div>

Hi,

I tried the tests on the alpha we currnently have with the green flash libs and i got the same 80001000 error .. so taking on board what you mention with regards to missing libs, i used the currently working A500 build with apparently no problems and put it on the Vega ..

http://pastebin.com/i1Cs5RZ1

The build does not boot mind you with their gralloc our ours or indeed with our libmedia or not and it seems the NV libs do not load .. same results as i had on our build with the A500 / Xoom / Google libs ... You will also note the error code on the omx_play log ... familiar it seems ....

Pastebin shows above the dmesg / logcat and results from the tests ...

Need to work further to see what i need to do to make this build boot to the state we get from ours but have a look to the logs incase you catch anything meantime ..

What i did notice with our build/libs and your demo_decode app was that we seem to have a lib that was out of place or a problem being that it did not match the rest of the nvlibs, not sure which right now ...

libnvwinsys.so

not got the error to hand right now but it was bitching about some NV function .. ill update the exact error when i get back to a normal state .. cant find it to hand right now ... Its probably the same error as we had a while back when we run ld on the libs to check for sanity.

edit :-

root@android:/data # ./omx_play sample_mpeg4.mp4

link_image[1936]: 1617 could not load needed library 'libnvomx.so' for './omx_play' (link_image[1936]: 1617 could not load needed library 'libnvwinsys.so' for 'libnvomx.so' (reloc_library[1285]: 1617 cannot locate '_ZN7android21SurfaceComposerClient22closeGlobalTransactionEv'...

))CANNOT LINK EXECUTABLE

removing this file removes the error but thats understandable :)

or converted to proper function

./libnvwinsys.so: undefined reference to `android::SurfaceComposerClient::closeGlobalTransaction()'

At the risk of going down another rathole .. we dont see this problem with the libnvomx from the A500 as its libnvomx does not use this file, omx_play still fails with

Setup tunneling

test22 8000100c

and the other one

VD_OMX:Got event 1 80001000 2

but mixing libs is not good or will probably never work as we'd like

Rgds

Cass

Edited January 16, 2012 by Cass67

[Guest Cass67]

@Cass,

If you want to help people with oversensitive touchscreen issues on ICS Alpha 2. (when charger is not plugged in). You need to revert these changes:

https://github.com/w...55e74dbe#diff-2

Also you may like to take a look @ this:

http://www.tabletrom....html#post46361

Kind Regards,

Areo

edit: only revert the changes for it7260.c

Thanks. . ill have a look .. though what impact does this have with people who do not see an issue right now ?

[Guest Cass67]

Hello All,

I was playing with some nvidia blobs and some minor kernel changes to get audio working on my folio.

And suddenly the folio went into sleep.

I have just removed a few nvidia audio blobs and changed one audio GPIO and suspend is working for me now.

There is just no chance to wake it up again yet...

I think that you might find it interesting as you have the same suspend problems like me...

Also for the video acceleration: If you think that that video decoding stuff is related to the amount of RAM you may get in touch with the ADAM guys. They have 1GB of RAM and are running basically the same kernel sources.

They could test if the nvidia blobs are working for them...

Yeah the Adam chaps appear to have the exact same issues with video decoding too .... their suspend appears to work a bit better too .... i.e it wakes up :) Ive not looked throught their kernel code yet to see if they have many diffs from us but i did sync up my .config with theirs as they had quite a few differences, once i reverted enough of my changes to get me booting and working again we still did not susupend :)

Edit .. scratch that comment about the Adams resuming from sleep .. they have a SOD too .. just found out there was a wakelock in the BT boardfile keeping it alive ... think ill add it meantime :)

edit2 .. though its not possible to add the same wakelock .. seems our files are from scartch and not based on a similar ventana one ...

Cheers

Cass

Edited January 16, 2012 by Cass67

[Guest Cass67]

Found this on the tiamat xoom ics kernel git, remember seeing a few pages ago stuff on mmc so thought I would post:-

tiamat xoom mmc bus update

Also has anyone tested removing all sleep/resume code/config from the source so nothing sleeps and then introduce them one at a time ?

For example set sleep/resume for screen only try to resume if it works then move on and add next and carry on until you hit one that stops resume, if it does not resume with just screen then maybe that tells you something.

I know gpio/irq/lp0/lp1 has been mentioned and smarter people then me have looked at this, just trying to post some things that may not have been seen that may help.

Edit - re. tiamat xoom ics kernel, I see back on page 55 cass mentioned that suspend was not a problem, if you look at the pm.c file in this kernel they seemed to have copied the suspend.c file into the 39 kernel or at least modified it to work (maybe thats why it worked):-

tiamat ics kernel pm file with suspend code

Thanks .. the first patch makes no difference .. actually it needs fixed too in order to compile correctly .. even with that fix its no good for us .. second one needs work too in order to compile in our environment ... not did that yet or not sure i will to be honest as we seem to have many more changes than average .. im not even sure where half our suspend code comes from ... Im comparing the Adams code also and they differ from us in the second patch (pm.c) only by the fact (i think) Eduardo added some L2 cache sync function... They have many changes to the mmc stuff as their bus.c is the same as ours but their core.c is quite a bit changed ... Seems the more i look at this the further down a rat hole i appear .. everyone seems to be using different versions of code ..

Cheers

Cass

Edited January 15, 2012 by Cass67

[Guest treznorx]

Thanks .. the first patch makes no difference .. actually it needs fixed too in order to compile correctly .. even with that fix its no good for us .. second one needs work too in order to compile in our environment ... not did that yet or not sure i will to be honest as we seem to have many more changes than average .. im not even sure where half our suspend code comes from ... Im comparing the Adams code also and they differ from us in the second patch (pm.c) only by the fact (i think) Eduardo added some L2 cache sync function... They have many changes to the mmc stuff as their bus.c is the same as ours but their core.c is quite a bit changed ... Seems the more i look at this the further down a rat hole i appear .. everyone seems to be using different versions of code ..

Cheers

Cass

I'm working on the gtab and we have the same issue with sod.

I've tried porting the entire suspend process from that tiamat kernel, basically this goes back to what we all have in the .36 kernel. The tab still wouldn't wake up.

I have also tried using lp2 and again the tab would not wake up.

The only time I have seen the tab go all the way to sleep and then wake up is when there was a wake alarm that caused the tab to sleep and wake up over and over on its own, but this only happens occasionally.

I also have Eduardo's cache sync function in my kernel and I've tried all the above patches to no avail.

I think the adam, shuttle and gtab are all in the same boat as far as this goes.

Anyone I have come across who thought they didn't have the problem actually had a wakelock preventing the tab from sleeping.

Treznorx

[Guest Cass67]

I'm working on the gtab and we have the same issue with sod.

I've tried porting the entire suspend process from that tiamat kernel, basically this goes back to what we all have in the .36 kernel. The tab still wouldn't wake up.

I have also tried using lp2 and again the tab would not wake up.

The only time I have seen the tab go all the way to sleep and then wake up is when there was a wake alarm that caused the tab to sleep and wake up over and over on its own, but this only happens occasionally.

I also have Eduardo's cache sync function in my kernel and I've tried all the above patches to no avail.

I think the adam, shuttle and gtab are all in the same boat as far as this goes.

Anyone I have come across who thought they didn't have the problem actually had a wakelock preventing the tab from sleeping.

Treznorx

Interesting .. thanks for sharing .. wonder if all Tegra2 devices are in the same boat and the Xoom and A500 do have the problem and have a wakelock too ... funny :)

[Guest treznorx]

Here is a dmesg that shows the cpu actually comes out of lp1 and then crashes http://pastebin.com/JFpd5u1W

[Guest Cass67]

Here is a dmesg that shows the cpu actually comes out of lp1 and then crashes http://pastebin.com/JFpd5u1W

How did you get that log ? I cant force a panic or crash when it enters suspend !!

Also as another note i tried removing the NOHZ mode yesterday .. no diff :)

[Guest treznorx]

OK I removed SMP and it still doesn't wake up. As far as console output it shows the same thing just without the cpu1 booting back up.

Gtab has a hard reset button that allows the ram console to work. (For anyone who missed the IRC chat)

[Guest treznorx]

Ok so when the tab isn't coming back on its not really crashed. If I plug my usb serial converter in while its sleeping I get errors in the ram console after the reboot. It seems its just sitting there waiting for something to tell teh rest of teh devices to wake up. In the .36 kernel there was a legacy_irq.c file that handles what gic.c does now. I did not port this over when I tried the moto pm.c patch earlier. Have to try again when I have time.

[Guest DrMon]

Yeah the Adam chaps appear to have the exact same issues with video decoding too .... their suspend appears to work a bit better too .... i.e it wakes up :) Ive not looked throught their kernel code yet to see if they have many diffs from us but i did sync up my .config with theirs as they had quite a few differences, once i reverted enough of my changes to get me booting and working again we still did not susupend :)

Edit .. scratch that comment about the Adams resuming from sleep .. they have a SOD too .. just found out there was a wakelock in the BT boardfile keeping it alive ... think ill add it meantime :)

edit2 .. though its not possible to add the same wakelock .. seems our files are from scartch and not based on a similar ventana one ...

Cheers

Cass

The new function in ICS takes a bool as a parameter in it's new home of libgui.so . If you want to do some testing, you could add a routing function, as the bool defaults to false anyway. The bool's variable name is 'synchronous'.

[EDIT] Should probably add I'm MrGuy from TR. Just realized my nickname on here is different.

[EDIT 2] Cass, using the libs we're on now (Us Adam folk) we were able to add the routing function and grab this output:

root@android:/ # demo_decode

NvAvpOpen: Error opening nvavp device (No such file or directory)

om init 0

Requesting 4 buffers of 38016 bytes

buf_out[0]=0x1db4110

buf_out[1]=0x1db8af0

buf_out[2]=0x1db5c08

buf_out[3]=0x1db5fc8

Requesting 10 buffers of 1566720 bytes

buffers: 1566720 x 10

buf_in[0]=0x1db4480

buf_in[1]=0x1db4830

buf_in[2]=0x1db4af8

buf_in[3]=0x1db4be0

buf_in[4]=0x1db5760

buf_in[5]=0x1db55f0

buf_in[6]=0x1db5480

buf_in[7]=0x1db5310

buf_in[8]=0x1db51a0

buf_in[9]=0x1db5030

idle

Edited January 16, 2012 by DrMon

[Guest brucelee666]

Found this re. mach-tegra kconfig, relates to errata's, i see "ARM_ERRATA_742230" is in the config but this lists another couple T20 arm errata details:-

"PL310_ERRATA_753970 if CACHE_PL310" - cache sync operation may be faulty

"PL310_ERRATA_769419 if CACHE_L2X0" - no automatic store buffer drain

I see from kernel config both PL310 and L2X0 are set to yes so maybe these need to added, have a read ?

[Guest ejtagle]

Ok so when the tab isn't coming back on its not really crashed. If I plug my usb serial converter in while its sleeping I get errors in the ram console after the reboot. It seems its just sitting there waiting for something to tell teh rest of teh devices to wake up. In the .36 kernel there was a legacy_irq.c file that handles what gic.c does now. I did not port this over when I tried the moto pm.c patch earlier. Have to try again when I have time.

Great news! -- Could you do us a big, big favor and add to your kernel command arguments the following ones:

initcall_debug ignore_loglevel

and re capture the kernel log while the CPU resumes ? --- initcall_debug will print out not only the initialization sequence of devices, but most importantly here, the resume sequence ... before trying to call each resume function of each device, it prints out its name (the name of the device driver) ,,, and also prints out if an error was detected.

I think, after seeing at your log that the kernel core is resuming properly, but some device is preventing the system to complete the resume ;) -- Once we get its name, we will be able to fix it ;)

Pretty thanks for this piece of information !

[Guest treznorx]

Great news! -- Could you do us a big, big favor and add to your kernel command arguments the following ones:

initcall_debug ignore_loglevel

and re capture the kernel log while the CPU resumes ? --- initcall_debug will print out not only the initialization sequence of devices, but most importantly here, the resume sequence ... before trying to call each resume function of each device, it prints out its name (the name of the device driver) ,,, and also prints out if an error was detected.

I think, after seeing at your log that the kernel core is resuming properly, but some device is preventing the system to complete the resume ;) -- Once we get its name, we will be able to fix it ;)

Pretty thanks for this piece of information !

I'll try this tonight, I'm at work right now. Thanks!

[Guest treznorx]

Here is the dmesg with those enabled. My kernel config has smp, earlysuspend, and caches disabled. This should eliminate any of those as the cause. http://pastebin.com/635KPxUX

It looks like the memory is not being restored, it gets copied into iram but the next step of the restore should be to copy it back and it fails to do so.

Edited January 17, 2012 by treznorx