Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

@eduardo ... not sure if you have tested the mic yet on the new patches but there is an improvement .. no out of memory errors. but the attached will show the output i tried to describe the other day ... im saying test over and over .. sounds creepy :)

vega-mic-test1.mp3

Link to comment
Share on other sites

Guest pershoot
Link to comment
Share on other sites

Thanks Pershoot .. was actually looking at your patches last night incase we do have a need to use 36 to fix the video .. im hoping not ... i may just apply them locally to see what diff it makes to our video problems for fun just now :)

Do you have a patch handy to apply for that lot or will i have to just go pick them out and apply by hand ?

edit :- nvm .. pulled the patches ... tx !

Hmm not gonna be as easy as applying the patches .. think this will have to be done by hand ... expected no less :)

Cheers

Cass

Edited by Cass67
Link to comment
Share on other sites

Guest pershoot

i have one more patch to bring in.

on my device, i frequently get DC underflow (if really hammering the display, or coming up from sleep and then using right away) and the display blanks/unblanks.

working on it, and once sorted, ill reply back with that change id.

Edited by pershoot
Link to comment
Share on other sites

Guest pershoot

i have one more patch to bring in.

on my device, i frequently get DC underflow (if really hammering the display, or coming up from sleep and then using right away) and the display blanks/unblanks.

working on it, and once sorted, ill reply back with that change id.

i cleaned up the merges some.

i also re-backported .39 (dc/fb only) and left that reverted, if you want to play.

now on to the underflows:

i think the demand in 4.03 grew (vs 4.01), so currently testing a greater EMC ratio. if not, ill just disable the scaling, and that should hopefully sort it out.

Edited by pershoot
Link to comment
Share on other sites

Guest ejtagle

i cleaned up the merges some.

i also re-backported .39 (dc/fb only) and left that reverted, if you want to play.

now on to the underflows:

i think the demand in 4.03 grew (vs 4.01), so currently testing a greater EMC ratio. if not, ill just disable the scaling, and that should hopefully sort it out.

Hey, pershoot! ... Great work you are doing here on the video subsystem! :) ... I have an small question, and i think we will all benefit from the answer to it... Do you know the exact cause that is forcing us to keep parts of the tegra video subsystem of original 2.6.36 kernel ? ... As i understand it, you are painfully backporting part by part of the 2.6.39 kernel to the 2.6.36 kernel... You told us dc and fb and host from 2.6.39 eorks, but nvmap does not... So...

What exact binary nvidia glES/omx redistributables are you using? ... The ones supplied by Google?

You nvmap was not ported yet... ? Or you tried it and when compiled into the kernel, the graphics subsystem did not start up? Or perhaps it is just the openmax aceleration that stops working?

Now, i will complete some pieces of information i have...

Here, with Cass, we are NOT using the google supplied proprietary libs. We are using libs from... Well, Cass knows much better than i where they came from ... Probably from a HC based rom, but certainly not the google supplied ones

To make those libraries work, i had to reimplement some proprietary ioctrls in the fb subsystem of the 2.6.39... Specifically, the ones related to surface flipping. I have seen that in your git, you are using the 2.6.39 fb without those ioctrls, so, i am pretty interester to know the exact propietary nvidia libs you are using... So we can use the same ones...

The problem we are getting right now with Cass is OMX (openmax hardware acceleration) that is not working. But all the other things are working, and we are not getting DC underflows at all.

The HC openmax lib (libnvomx.so) does not load because it depends on APIs that were removed from ICS. We were able to fix that in 2 different ways... Either reimplementing the missing apis in libmedia (part of the android framework) or just by replacing the libnvomx.so of HC by the one supplied by Google. But JUST that library (libnvomx.so) - And i think this last approach is way better than the first one, as it does not require a framwork modification.

Either way the libnvomx.so loads, and almost works... "almost", because, when we try to play a video, the library is returing an error code that means "Out of memory" ... and it fails decoding video. As you know, hw decoding is done using the extra AVP processor present on Tegra2 devices (an ARM5), and the dc/nvhost/fb drivers... We have firmware for the AVP processor (*.axf and *.bin) and according to kernel logs the fw is loading and initializing properly... so..

I am right now trying to figure out the exact cause of the "Out of memory" error that is reported by the omx component...I have partially disassembled the libnvomx to find the causes of the lib returning such errors - They seem to be

1) A real malloc failure (why?) ... There is more than enough free memory ... Unless the size of the allocated block is calculated based on something returned from avp/fb/dc/nvhost that is not properly returned by onw of those drivers

2) An out of memory condition on the nvhost ...This could make more sense.. Perhaps they changed something in the user interface...

I have compared the user interfaces exposed by those drivers (except nvhost :S) and, besides the missing page flip on the fb, they are the same, even better, the 2.6.39 implements even more interfaces... And i think the 2.6.39 video subsystem is way more advanced regarding power management compared to the 2.6.36 one...

The next thing i was going to try is an strace of a test app for omx, to check if the problem is a malloc out of memory condition or not, but knowing if the 2.6.39 nvhost has any problem would give a hint ... as it could add detail to the out of memory conditions ... "Out of graphic memory conditions!" abd how to fix it... by adjusting the nvhost driver... And, while writing this, you gave me another idea... patch the libnvomx to return a different error code for each memory allocation failure, to be able to spot the exact code path leading to the fail...

BTW, in your case, i would check that missing page flip ioctl on the fb.c of the backported 2.6.39...

Regards,

Eduardo

Link to comment
Share on other sites

Guest ejtagle

i cleaned up the merges some.

i also re-backported .39 (dc/fb only) and left that reverted, if you want to play.

now on to the underflows:

i think the demand in 4.03 grew (vs 4.01), so currently testing a greater EMC ratio. if not, ill just disable the scaling, and that should hopefully sort it out.

As far as i know, EMC ratio is fixed by hw on tegra2 to 2x... Really doubt there is a problem with ICS... I the worst case , you would get less FPS, but no other adverse effects...

Link to comment
Share on other sites

Guest pershoot

Hey, pershoot! ... Great work you are doing here on the video subsystem! :) ... I have an small question, and i think we will all benefit from the answer to it... Do you know the exact cause that is forcing us to keep parts of the tegra video subsystem of original 2.6.36 kernel ? ... As i understand it, you are painfully backporting part by part of the 2.6.39 kernel to the 2.6.36 kernel... You told us dc and fb and host from 2.6.39 eorks, but nvmap does not... So...

What exact binary nvidia glES/omx redistributables are you using? ... The ones supplied by Google?

You nvmap was not ported yet... ? Or you tried it and when compiled into the kernel, the graphics subsystem did not start up? Or perhaps it is just the openmax aceleration that stops working?

Now, i will complete some pieces of information i have...

Here, with Cass, we are NOT using the google supplied proprietary libs. We are using libs from... Well, Cass knows much better than i where they came from ... Probably from a HC based rom, but certainly not the google supplied ones

To make those libraries work, i had to reimplement some proprietary ioctrls in the fb subsystem of the 2.6.39... Specifically, the ones related to surface flipping. I have seen that in your git, you are using the 2.6.39 fb without those ioctrls, so, i am pretty interester to know the exact propietary nvidia libs you are using... So we can use the same ones...

The problem we are getting right now with Cass is OMX (openmax hardware acceleration) that is not working. But all the other things are working, and we are not getting DC underflows at all.

The HC openmax lib (libnvomx.so) does not load because it depends on APIs that were removed from ICS. We were able to fix that in 2 different ways... Either reimplementing the missing apis in libmedia (part of the android framework) or just by replacing the libnvomx.so of HC by the one supplied by Google. But JUST that library (libnvomx.so) - And i think this last approach is way better than the first one, as it does not require a framwork modification.

Either way the libnvomx.so loads, and almost works... "almost", because, when we try to play a video, the library is returing an error code that means "Out of memory" ... and it fails decoding video. As you know, hw decoding is done using the extra AVP processor present on Tegra2 devices (an ARM5), and the dc/nvhost/fb drivers... We have firmware for the AVP processor (*.axf and *.bin) and according to kernel logs the fw is loading and initializing properly... so..

I am right now trying to figure out the exact cause of the "Out of memory" error that is reported by the omx component...I have partially disassembled the libnvomx to find the causes of the lib returning such errors - They seem to be

1) A real malloc failure (why?) ... There is more than enough free memory ... Unless the size of the allocated block is calculated based on something returned from avp/fb/dc/nvhost that is not properly returned by onw of those drivers

2) An out of memory condition on the nvhost ...This could make more sense.. Perhaps they changed something in the user interface...

I have compared the user interfaces exposed by those drivers (except nvhost :S) and, besides the missing page flip on the fb, they are the same, even better, the 2.6.39 implements even more interfaces... And i think the 2.6.39 video subsystem is way more advanced regarding power management compared to the 2.6.36 one...

The next thing i was going to try is an strace of a test app for omx, to check if the problem is a malloc out of memory condition or not, but knowing if the 2.6.39 nvhost has any problem would give a hint ... as it could add detail to the out of memory conditions ... "Out of graphic memory conditions!" abd how to fix it... by adjusting the nvhost driver... And, while writing this, you gave me another idea... patch the libnvomx to return a different error code for each memory allocation failure, to be able to spot the exact code path leading to the fail...

BTW, in your case, i would check that missing page flip ioctl on the fb.c of the backported 2.6.39...

Regards,

Eduardo

.36 video subsystem and .39 are basically the same, with .36 being a bit newer (+1 month in patches; and a few other misc patches). ive sync'd in full from nvidia for only those components (nvmap,nvhost,dc/fb (not media/avp)). ive reverted 2 or 3 things which were causing issue on this particular device (in the git log). there's a minute amount of extra in the .36; csi, etc. in order for ICS to work without the green (when using the new libs), overlay needs to export UV.

http://nv-tegra.nvid...5d0fa3500d4e957

theres also other changes which fix orientation glitchiness, bandwith allocation, etc., etc.. so better to sync up with what they are doing (even though they have changed location of some things). i chose .36 as its a bit newer, which contains a bit more patches then .39. you could certainly use the older .39 stuff in full as well. the video subsystem im using is unmodified (in terms of the interfaces; some custom samsung stuff exists tho). the new libs are required tho (which you are using now; ive listed the 14 libs required further back).

omx over here loads, but wont work for HD (non HD works fine). see if you have any linker errors in your logs.

ya, that ioctl has been moved to DC_EXT. doesnt apear to be needed currently, so far (maybe a need in some other applicational use will come up). i've not recently tested DC_EXT on this userspace (last time i tested i didnt have the full merge done, so didnt work out).

ive sorted the underflow (for the most part; knock on wood, hehe) by increasing EMC_TO_DDR ratio. they could still happen, but it 'should' be a very rare case (as is when working with the normal subsystem). if it comes back up, ill remove EMC scaling (they've (nvidia) done it in their tree for ventana (my device is a type of derivative, but not a ventana, per se). im probably just forcing it to ramp up to max (due to the newer given BW calculation changes in dc). it should be 2x, ya.

in 4.01 i dont recall this happening; started in 4.03 (or could be any number of patches that went in which caused this side effect, hehe). so i believe some requirements may have changed (just from an observational point of view).

Edited by pershoot
Link to comment
Share on other sites

Guest ejtagle

.36 video subsystem and .39 are basically the same, with .36 being a bit newer (+1 month in patches; and a few other misc patches). ive sync'd in full from nvidia for only those components (nvmap,nvhost,dc/fb (not media/avp)). there's a minute amount of extra in the .36; csi, etc. in order for ICS to work without the green (when using the new libs), overlay needs to export UV.

http://nv-tegra.nvid...5d0fa3500d4e957

theres also other changes which fix orientation glitchiness, bandwith allocation, etc., etc.. so better to sync up with what they are doing (even though they have changed location of some things). i chose .36 as its a bit newer, which contains a bit more patches then .39. you could certainly use the older .39 stuff in full as well. the video subsystem im using is unmodified (in terms of the interfaces; some custom samsung stuff exists tho). the new libs are required tho (which you are using now; ive listed the 14 libs required further back).

omx over here loads, but wont work for HD (non HD works fine). see if you have any linker errors in your logs.

ya, that ioctl has been moved to DC_EXT. doesnt apear to be needed currently, so far (maybe a need in some other applicational use will come up). i've not recently tested DC_EXT on this userspace (last time i tested i didnt have the full merge done, so didnt work out).

ive sorted the underflow by increasing EMC_TO_DDR ratio. they could still happen, but it should be a very rare case (as is when working with the normal subsystem). if it comes back up, ill remove EMC scaling (they've (nvidia) done it in their tree for ventana (my device is a type of derivative, but not a ventana, per se). im probably just forcing it to ramp up to max (due to the newer given BW calculation changes in dc).. it should be 2x, ya.

in 4.01 i dont recall this happening. started in 4.03. so i believe some requirements may have changed (just from an observational point of view).

The problem here seems to be that i am using android-tegra-nv-2.6.39 head, but you are using the android-tegra-2.6.36 head... You are right, the .36 seems to be newer, but... Why did you mention you are backporting from .39 ? -- It was just a mistake ? ... Seems you are applying patches from the .36 head to your custom kernel... ;)

Don't take me wrong, there's nothing bad with what you are doing, i am just trying to understand exactly what you are doing :)

As Cass said some time ago, we are trying to use the .39 kernel as that is closer to the 3.0 kernel Nexus is using... There are some ICS features that need a newer kernel, or at least, backporting som stuff from the .39 to the .36... As right now we have both .36 and .39 kernels running and booting properly on our device, i just was trying to make to use the .39 as the base kernel :)

Thanks a lot for keeping us informed on your progress, I can tell you that we are very interested on it :)

Link to comment
Share on other sites

Guest pershoot

The problem here seems to be that i am using android-tegra-nv-2.6.39 head, but you are using the android-tegra-2.6.36 head... You are right, the .36 seems to be newer, but... Why did you mention you are backporting from .39 ? -- It was just a mistake ? ... Seems you are applying patches from the .36 head to your custom kernel... ;)

Don't take me wrong, there's nothing bad with what you are doing, i am just trying to understand exactly what you are doing :)

As Cass said some time ago, we are trying to use the .39 kernel as that is closer to the 3.0 kernel Nexus is using... There are some ICS features that need a newer kernel, or at least, backporting som stuff from the .39 to the .36... As right now we have both .36 and .39 kernels running and booting properly on our device, i just was trying to make to use the .39 as the base kernel :)

Thanks a lot for keeping us informed on your progress, I can tell you that we are very interested on it :)

i backported it before i realised .36 worked from them in full (for that subsystem). i left it reverted in my tree (only dc/fb from .39 tree) for those that want to play/test. as of right now, .39 is not needed (for my device at least). if you have a stable .36, id say use that, with the video subsystem sync'd up (you can use my changes as a guide) and keep .39 on the backburner (if its not as stable). im unsure if in the future more parts from it will need to be used (like when we eventually get cam userspace drivers/libraries, etc.)

3.0 has genlock, which is not used on tegra2. i believe some work is ocurring to get genlock backported to .35.

Edited by pershoot
Link to comment
Share on other sites

Guest pershoot

wanted to say..

great work by yourself/cass! you've definitely supercharged this forgotten device (by nvidia/vendor).

:)

Edited by pershoot
Link to comment
Share on other sites

Guest Cass67

@eduardo

Appears we are getting Sleep of Deaths, i thought it was just a problem with the latest patches but it appears not ... unable to resume from sleep with USB cable not plugged in ... thats why i never noticed it earlier, its always plugged in :/ Im having trouble getting logs out of the thing as to resume from the SOD you need to power it off ....

The in kernel CONFIG_PANIC_TIMEOUT=10 and cmdline panic=10 lines seems to not do anything as its not rebooting after panic ... well that it if its even panic'ing .. any idea how to get logs out of this ?

Cheers

Cass

Link to comment
Share on other sites

Guest ejtagle

@eduardo

Appears we are getting Sleep of Deaths, i thought it was just a problem with the latest patches but it appears not ... unable to resume from sleep with USB cable not plugged in ... thats why i never noticed it earlier, its always plugged in :/ Im having trouble getting logs out of the thing as to resume from the SOD you need to power it off ....

The in kernel CONFIG_PANIC_TIMEOUT=10 and cmdline panic=10 lines seems to not do anything as its not rebooting after panic ... well that it if its even panic'ing .. any idea how to get logs out of this ?

Cheers

Cass

I'll take a look tomorrow. Today i ran out of time... Lately been busy porting the .36 video subsystem to our .39 kernel ... Attached are the modified files... Compiles, but i had no time to actually test it on the device... It is the same subsystem used by peranders,... Will also test it tomorrow...

Regarding USB, you are right... When in gadget mode, and USB cable is plugged in, we are holding a wakelock so device does not enter suspend... Another thing to check ... :S

39w36video.rar

Link to comment
Share on other sites

Guest Cass67

I'll take a look tomorrow. Today i ran out of time... Lately been busy porting the .36 video subsystem to our .39 kernel ... Attached are the modified files... Compiles, but i had no time to actually test it on the device... It is the same subsystem used by peranders,... Will also test it tomorrow...

Regarding USB, you are right... When in gadget mode, and USB cable is plugged in, we are holding a wakelock so device does not enter suspend... Another thing to check ... :S

On an initial check it boots ok .. black screen but i may have to play with the libs ... no time right now ... ill check later and let you know ...

EDIT :-

Ok tested some more ....

VegaICS Alpha 1/2 with leaked libs from Fards we currently use:-

E/SurfaceTexture( 93): [com.android.launcher/com.android.launcher2.Launcher] requestBuffer: SurfaceTexture has been abandoned!

E/SurfaceTextureClient( 393): dequeueBuffer: ISurfaceTexture::requestBuffer failed: -19

W/nvwsi ( 393): dequeueBuffer failed, error -19

D/OpenGLRenderer( 393): GL error from OpenGLRenderer: 0x506

dGroup.java:690)

D/OpenGLRenderer( 393): GL error from OpenGLRenderer: 0x506

W/HardwareRenderer( 393): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer( 393): Mountain View, we've had a problem here. Switching back to software rendering.

D/AndroidRuntime( 393): Shutting down VM

E/gralloc ( 133): GetBufferLock timed out for thread 136 buffer 0x19 usage 0x200 LockState 1

E/gralloc ( 133): GetBufferLock timed out for thread 136 buffer 0x19 usage 0x200 LockState 1

Either hangs at android splash or at unlock screen ..

the 0x0506 error seems to refer to the follwing ...

EXT_framebuffer_object enum:

INVALID_FRAMEBUFFER_OPERATION_EXT = 0x0506

With the Official Google Xoom libs we see both of these OpenGL errors, does not even boot as far as the ones we use now ... just hangs

INVALID_OPERATION = 0x0502

OUT_OF_MEMORY = 0x0505

mixing libs gets us nowhere :)

So far with all the libs i have at my disposal it seems the ones we are using now are closest to a booting system...

Many thanks

Cass

Edited by Cass67
Link to comment
Share on other sites

Guest ejtagle

On an initial check it boots ok .. black screen but i may have to play with the libs ... no time right now ... ill check later and let you know ...

EDIT :-

Ok tested some more ....

VegaICS Alpha 1/2 with leaked libs from Fards we currently use:-

E/SurfaceTexture( 93): [com.android.launcher/com.android.launcher2.Launcher] requestBuffer: SurfaceTexture has been abandoned!

E/SurfaceTextureClient( 393): dequeueBuffer: ISurfaceTexture::requestBuffer failed: -19

W/nvwsi ( 393): dequeueBuffer failed, error -19

D/OpenGLRenderer( 393): GL error from OpenGLRenderer: 0x506

dGroup.java:690)

D/OpenGLRenderer( 393): GL error from OpenGLRenderer: 0x506

W/HardwareRenderer( 393): EGL error: EGL_BAD_CURRENT_SURFACE

W/HardwareRenderer( 393): Mountain View, we've had a problem here. Switching back to software rendering.

D/AndroidRuntime( 393): Shutting down VM

E/gralloc ( 133): GetBufferLock timed out for thread 136 buffer 0x19 usage 0x200 LockState 1

E/gralloc ( 133): GetBufferLock timed out for thread 136 buffer 0x19 usage 0x200 LockState 1

Either hangs at android splash or at unlock screen ..

the 0x0506 error seems to refer to the follwing ...

EXT_framebuffer_object enum:

INVALID_FRAMEBUFFER_OPERATION_EXT = 0x0506

With the Official Google Xoom libs we see both of these OpenGL errors, does not even boot as far as the ones we use now ... just hangs

INVALID_OPERATION = 0x0502

OUT_OF_MEMORY = 0x0505

mixing libs gets us nowhere :)

So far with all the libs i have at my disposal it seems the ones we are using now are closest to a booting system...

Many thanks

Cass

I'd really would like to know what peranders is using... Supposedly, we are using the same exact video subsystem as him... and it works for him :S

Link to comment
Share on other sites

Guest Cass67

I'd really would like to know what peranders is using... Supposedly, we are using the same exact video subsystem as him... and it works for him :S

Who's peranders and why cant we ask him ? :)

Link to comment
Share on other sites

Guest Cass67

pershoot.. Sorry, not peranders ... That is what it happens when i don't read before posting.. ;)

heh .. i suspected it was him, though although his boots ok im sure he posted before that the openmax stuff is still not correct for him .. no HQ in youtube !! Im sure he'll pipe up if thats incorrect... Also i think he is running the same nv libs as us as he inititially at least used the same stuff from Fards .. he had the green flashes too ...

Edit .. just re-read pershoots comments to the reply to your last long thread ...

"the video subsystem im using is unmodified (in terms of the interfaces; some custom samsung stuff exists tho). the new libs are required tho (which you are using now; ive listed the 14 libs required further back).

He is using the same libs as us ... and

"omx over here loads, but wont work for HD (non HD works fine). see if you have any linker errors in your logs."

he has the same problems ...

Edited by Cass67
Link to comment
Share on other sites

Guest ejtagle

heh .. i suspected it was him, though although his boots ok im sure he posted before that the openmax stuff is still not correct for him .. no HQ in youtube !! Im sure he'll pipe up if thats incorrect... Also i think he is running the same nv libs as us as he inititially at least used the same stuff from Fards .. he had the green flashes too ...

There must be a reason behind the openmax failures.. I think i will readd the private ioctls to the fb.c file so we can keep using our gralloc with this newer video subsystem. It is true that the .36 video subsystem is newer than the one present on the .39 kernel, so i'd guess we better keep it... And i will continue investigation on the out of memory issues on openmax ;)

Also, i will again compare the moto .39 kernel with ours to try to find out why the suspend is not working. Moto and ours kernel are nearly the same ones on the tegra specific arch files... There was an snmall difference regarding cache .. They were saving and restoring cache contents when suspending and resuming, and our .39 kernel does not. Perhaps that is the problem with suspend ... No other significant differences that i could remember right now

Link to comment
Share on other sites

Guest ejtagle

While we are still trying to sort out the gl issue, i took a break and fixed the camera... Attached the libcamera sources (replace the ones i posted in the initial support of shuttle for AOSP) and compile it... You need to rename the resulting module as camera.$(BOARD_NAME).so and copy it to /system/lib/hw

Attached the source code and a precompiled version of the lib ;) -- Camera works, yeah! :)

libcamera.rar

camera.Shuttle.rar

Link to comment
Share on other sites

Guest ejtagle

I have also attached my first attempt at fixing the suspend of death problem. I implemented the cache save-restore functionality .. It compiles and boots, but i was unable to test suspend ... Ran out of time (again!)

patch2.6.39.rar

Link to comment
Share on other sites

Guest misterjoji

hi cass & eduardo, i manage to put in the required line, and still no luck. have these lines in logcat -b radio. seems like some lte issues. i dont know.


D/RILJ    (  351): [0235]> SIGNAL_STRENGTH

D/RIL     (  107): on_request: SIGNAL_STRENGTH, sState:4

D/RIL     (  107): AT> AT+CSQ

D/RIL     (  107): AT< +CSQ: 7,99

D/RIL     (  107): AT< OK

E/RILC    (  107): invalid response length

D/RIL     (  107): onRequest: SIGNAL_STRENGTH, Local implementation,  AT cmd sen

t

D/RILJ    (  351): [0235]< SIGNAL_STRENGTH error: com.android.internal.telephony

.CommandException: INVALID_RESPONSE

D/RILB    (  351): getLteOnCdmaMode=0 curVal=-1 product_type='' lteOnCdmaProduct

Type=''

D/RILB    (  351): getLteOnCdmaMode=0 curVal=-1 product_type='' lteOnCdmaProduct

Type=''

Link to comment
Share on other sites

Guest Cass67

I have also attached my first attempt at fixing the suspend of death problem. I implemented the cache save-restore functionality .. It compiles and boots, but i was unable to test suspend ... Ran out of time (again!)

Hi Eduardo,

Initial tests suggest this patch does not resolve the suspend issue... im back at work today so not so much chance to get into this for long but compiling patch and booting then sleeping the device still gives same result, no wakeup when not on usb .. no time to try and get debug out of this yet, probably later... ill give the camera a shot later too ...

edit :- Just tested camera, works as does the video camera, although playback is sketchy, to be expected.. so nice work :) just have to use the GoogleCamera app as the default ICS Camera app is crashy ...

Cheers

Cass

Edited by Cass67
Link to comment
Share on other sites

Guest ejtagle

Hi Eduardo,

Initial tests suggest this patch does not resolve the suspend issue... im back at work today so not so much chance to get into this for long but compiling patch and booting then sleeping the device still gives same result, no wakeup when not on usb .. no time to try and get debug out of this yet, probably later... ill give the camera a shot later too ...

Cheers

Cass

No problems... I fear suspend will be a pain in the neck to debug... :S

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.