Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by DrMon

  1. We also modified our audio userspace lib as well, but the errors about DMA in dmesg and the out of memory errors were still occuring in logcat, Our recording apps also 'appeared' to capture noise, but I suspect it is nothing but junk input caused by the failures to open the PCM device. Once I removed a few SPI devices the recording was able to proceed error free, but I have yet to successfully receive any input from the microphone. I am even able to switch the ADC into capturing the DAC output and record that in android applications, so I think I haven't enabled the microphone hardware fully yet...
  2. With regards to the PCM audio issues you gentlemen were having before, did you ever sovlve them with that patch? I dived a little deeper into the dma system and found we are quite short of channels. There are 16 for Tegra 2, 4/5 of which seemed to be reserved for the AVP, 4 SPI devices using 2 channels each, 1 uart device using 2 channels which leaves 1 channel left, which we usually use for playing back sound. However, trying to record often involves pressing a button which in itself plays a sound, hence the "Out of memory" errors we're encountering. I guess the important question here is - do we need all 4 SPI devices?
  3. Can't believe I forgot about that macro! Seems like that, in combination with one or two changes in the mountains of things I changed trying to get it going has gotten it going. Goes in and out of LP1 no problem, this is great. LP0 doesn't work, but I think that has to do with our processor revision: A03. Noticed the code said that LP0 was broken with that revision - oh well! Thank you for pointing that out, saved me another day or two of headaches
  4. We're having endless troubles trying to wake our Adam tablets up over here. Seems no matter what we do, they sit in LP1/LP2 forever. One interesting observation is that, like trez, we can't hotplug out cpu1 and have it come back up. If we echo 0 > /sys/devices/system/cpu/cpu1/online the CPU shutsdown, but if we try to echo 1, we get an error saying: [ 156.212783] CPU1: failed to come online [ 156.216851] Error taking CPU1 up: -5 DerArtrem or ejtagle - since sleep seems to work for you guys, can you try that quick experiment for me and see if it's the same for you?
  5. With regards to usb, you might want to take a look at our revised board-adam.c: https://github.com/E...ra/board-adam.c We've changed up the USB init functions in there to be compatible with the new systems, board-adam-usb.c is in fact no longer used at all. For the lockups, I'll look at mounting the the debugfs - not sure how to do it, It's new to me! EDIT: I should add I upped out GPU reserved memory to 256MB to match ventana - still get lock ups.
  6. We are getting this too - the tablet becomes virtually unusable after this occurs. Not good news...
  7. Has anyone noticed transparency issues with overlays using this set of Nvidia libraries? Our popup windows appear to be blending with the windows behind them which normally wouldn't be an issue - but the alpha is far too high. This makes viewing the text in those windows rather difficult... EDIT: Update! Turns out the two were related! Seems CONFIG_FRAMEBUFFER_CONSOLE conflicts with the gamma table - probably because fbcon and another entity fights over the proper entries. The gamma table is also needed because it dims the content behind the dialogue boxes which allows them to be readable. I'm not sure if it's possible to integrate the two - I'm just happy to have figured out the issue itself.
  8. I trawled through the extra 600 or so commits on this revision and found that the frame buffer console doesnt get inited properly once the 'global gamma table' gets introduced to fb.c. The particular commit occured on the 28th of oct last year - so that should help you track it down. For us Adam folk it also caused nasty rendering issues. It should be noted that android did continue to load up for us even with the commit, but indeed the fb console was not displayed. (Just a black screen). Im typing on my phone atm. Ill get a commit url tomorrow if you cant find it.
  9. Yes, you want to set CONFIG_TEGRA_AVP_KERNEL_ON_MMU=y or bad things will happen when the AVP tried to load up during decoding (i.e. most likely a panic and reboot).
  10. An idea might be to run cat /proc/interrupts, save the output and see if it's the same IRQ that it stops on. Did you put that pr_info at the beginning or end of the function? (I.e was it about to work on 129, or was it moving on to 130?)
  11. I imagine something like pr_info("--- DEBUG: Irq: %d", irq);
  12. 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: [email protected]:/ # 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
  13. To use fastboot your phone has to be in fastboot mode. Hold VOL- while turning on the device, wait for some messages to flash up and disappear. Then ensure FASTBOOT is selected in the menu you've got and press the power button once. From this point you should connect your phone to your PC using your USB cable. You should then be able to run the fastboot commands from the PC.
  14. You shouldn't need to edit it if your CID is also HTC__E11.
  15. From the phone througha terminal emulator, though you could use adb and type: adb shell <command> (Unless of course you're bricked and can't :() All works the same in the end :(
  16. You can re-enable the SDCard using fastboot. Boot the phone into fastboot by holding down VOL- and power. Wait for the screen to flash some messages and disappear, then plug in the USB, ensure fastboot is highlighted in the menu and press the power button once. Then, from your pc (in the directory containing the fastboot executable): fastboot oem enableqxdm 0 then fastboot oem boot Should re-enable your SDCard.
  17. Hi r&a, flash_image needs to be run from your phone (so yeah, linux only I guess, heh). Copy it over to /data before you run it :(
  • Create New...

Important Information

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