Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

54 Excellent

About ejtagle

  • Rank

Profile Information

  • Your Current Device(s)
    POV Mobii / N10
  1. Probably yes, it depends on the amount of free tiime i am able to dedicate to 4.4 kitkat .... ;)
  2. Yes, there is a way to get logs... You will need to use fastboot... The idea is to enable the option ANDROID_LOGGER_TO_KMSG in kernel config (i wrote it for the rel15r7 kernel, so you should have it). That option will redirect the android log to the kernel syslog. The syslog is stored in ram, but, if the system reboots, or if you are quick enough with force turning off and then turning on tablet, you will be able to get the log as lastkmsg... Alternatively, assuming the init.d script is working, just redirect the android log to the sdcard... ;) ...
  3. Yes,your check_fb is ok. On our kernel, we have an early_suspend callback that does the blanking and also switches to conservative governor... #ifdef CONFIG_HAS_EARLYSUSPEND n10_panel_early_suspender.suspend = n10_panel_early_suspend; n10_panel_early_suspender.resume = n10_panel_late_resume; n10_panel_early_suspender.level = EARLY_SUSPEND_LEVEL_DISABLE_FB; register_early_suspend(&n10_panel_early_suspender); #endif I failed to find that code on your smba related files. That piece of code is the one that must be carefully checked...
  4. What i don't like about your SERIAL log is the unbalanced enable IRQ ... That means something is pretty wrong. I don't have them. It is something related to the screen blanking. I seem to remember that it could be caused by something trying to blank the HDMI output, or perhaps you have enabled console autoblanking at the same time as android managed autoblanking... Disable console autoblanking, just let android manage it. Also, check platform_pwm_backlight_data, specifically the .check_fb function. You MUST ONLY blank the default framebuffer, NOT the HDMI framebuffer.... As it can cause this thing related to unbalanced irqs... Also check your earlysuspend routines for the framebuffers. You dont want to power down the hdmi panel...
  5. No problems... I am testing it myself, but i thought it could also solve the problems you have with your port .. ;)
  6. fosser2: Could you please try the attached hwc to see if the hdmi crashes continue ? - What i did was to disable the hwc when the screen is turned off. This seems to cure the crashes. At the same time, i get a "Cannot lock buffer" error on gralloc, but, it does not crash, and, as soon as screen is turned on again, it resumes working without issues... or at least, that is what i believe... To all the other people... Please do not integrate this hwc to any rom.. not yet... It still does not work properly. The problem i see is that when the system is turning off the screen, it still tries to render to a turned off video subsystem. When there is no hdmi connection, besides getting some flip errors, no other strange or harmful thing happens. But, when HDMI is plugged in, there is an extra thing causing trouble... The mirroring operation that copies framebuffer to HDMI bombs gralloc. I still have to figure out if the problem is that we are turning off the screen (something that was not implemented in the original hwc), our interrupt emulation, or just the something that was changed by Google at the framework level. I think it can be fixed, though. The attached hwc simply rejects calls when the screen is turned off (that is the difference to the previous hwc... This provents the crashes, but causes other issues... One of them is polluting logcat with hwc errors... But, at least, no more crashes... Really would appreciate testing of this hwc with and without hdmi plugged in... Edit2: the new hwc seems to be working pretty well, at least, it does not crash gralloc when the tablet suspends and HDMI is plugged in.. I am testing it right now... Prper HDMI output, proper video decoding, no crashes and tablet continues resuming from deep sleep without issues.. If today tablet kees waking without issues, i think we could integrate it... :) hwc_v2.rar
  7. The hciattach functionality is now included in libbt-vendor, We should need no part of bluez...
  8. Yes, i get exactly the same error... If HDMI is enabled and the tablet tries to enter suspend, i get the same crashing gralloc.... Logcat is very similar to yours. I have tracked the issue to /drivers/video/tegra/dc/ext/dev.c ... They disable dcs on suspend, and reenable them on resume. The problem is that gralloc is unaware of those disablings, so, when they try to redetect hdmi, and the dcs are disabled, they get 0 values and that crashes gralloc... It is a plain race condition between android framework and the suspend mechanism... Not synced at all... This message is the one giving some clues... NvGrPost: Failed, TEGRA_DC_EXT_FLIP 6 6= ENXIO . I partially reverse engineered gralloc, and found out this ioctl is a part of a secuence that tries to get hdmi resolution, copies output to hdmi, flips dcs to display into main ... I dont know why, but android is accessing the screen even when it is suspended... gralloc should be discarding all screen access when the video subsystem is suspended... but it does not. And that seems to be the cause of gralloc crashes... Seems the only way to fix this is to also create a gralloc wrapper...
  9. I will also post here my latest bluetooth attempts. On the ui, everything seems to work, but, i was unable to make a bt connection, so guessing something is still missing... Nevertheless, it will be interesting to know if someone is able to actually use the bluetooth... I am attaching 2 archives: >The first one contains my latest libbt-vendor, that is required so bluedroid knows how to talk to the hci layer of the linux kernel >The 2nd one is the required files that must be installed in /etc/bluetooth so the the libbtvendor is able to properly configure the bluetooth chipset etc.rar libbt-vendor.rar
  10. This seems to be a bug in the gralloc and/or surfaceflinger. I am guessing here, but seems gralloc is returning bogus values when asked tor the HDMI screen resolution, when it still not read from the display. That seems to be causing a division by 0 exception on surfaceflinger... I guess that to fix this problem, a patch to surfaceflinger is required (or a wrapper to gralloc) PD: After further investigation, the problem seems to be a race condition between gralloc and linux kernel video subsystem. When resuming, all HDMI displays are autodetected. But, that takes some time. Gralloc tries to read and set capabilities before the HDMI display is detected, and so, it gets an error and a 0x0 display. Then it tries to use that display... and crashes... This seems to be an actual tegra video subsystem bug...
  11. Well, here we go again trying to fix the SoD... Added to the previous hwc fixes (that also seem to have fixed issues on screen not repainting), there was a problem with the wifi driver (ar6002) and our configuration and handling of the sdhci slot where it is connected. I found out that the chipset was being powered down by one of our drivers (at the linux kernel level) while the system was entering deep suspend. Also, the driver itself was resseting the chipset when the system returned from deep sleep.. And the sdhci linux kernel component was powering down the sdhci bus. All the above thing resulted in a complete reinitialization of the wifi card at resume, but that sometimes clashed with the ar6002 driver, that was expecting the card to remain powered ... Result: sometimes the system just crashed at resume... Because the ar6002 driver was sending commands to a dead bus and card, and waiting for responses... The proper thing to do was (and that is exactly what is done on other platforms): -Keep the wifi card in WoW mode (powered up), WoW mode will wake the device if some traffic targeting the device is received -Keep the sdhci bus powered, othewise, the card cant wake the system -Do not implement workarounds at the wifi driver level for things that are already fixed in the kernel -Do not remove power to the card while suspended. Android, if asked to, will load and unload the driver when enabling and disabling wifi. When the driver is unloaded, the wifi card is powered down I am including the patched kernel, with the required .config file... Some changes were required, some configs were missing... Also included de patched ar6002 driver sources (i removed the workarounds that are not required anymore) rel-15r7.rar wlan_wow.rar
  12. I left the p10an01 on, so it tries to enter lp1 suspend mode. It did, as expected. 10 hours later, i pressed the physical back button, and the tablet did not wake up (this is expected behaviour, the tablet should not wake up with the back button, as that would mean it is not in deep sleep. The only physical button that is able to wake from deep sleep is the power button. Now i pressed the power button and the tablet woke up without issues. The kernel log confirms the device was in deep sleep :) -- So, maybe we have fixed the SOD issues...
  13. Regarding video, I found out that the hwcomposer wrapper i wrote was causing some trouble when screen is turned off. Specifically, it did not disable vsync interrupts, so the linux kernel tegra video subsystem started to complain about syncpoints timing out... I have fixed the hwcomposer module so now it disables vsync while screen is off. I do suspect that this could also be the cause of some SODs... Please, test and report. At least, works for me and removes all errors related to syncpoints and most errors related to gralloc. hwc.rar
  14. tegra_fb_blank , called from fb_blank, called from sys_ioctl ... I think, just guessing here, that from userspace we are getting a ioctl(fd, FBIOBLANK, fb_blank); If you are using the hwcomposer wrapper i wrote, comment out all the contents of the tegra2_blank function, and just leave the return 0; last line Seems something is trying to blank the hdmi output.... and seems the operation is unsupported. That crashes the kernel video subsystem, that in turn crashes gralloc...
  15. libcamera originated from android 2.2. Was severely modified by me to port it to android 3.0, then 4.0/4.1/4.2 ... In the way, I added some code taken from luvview, spcaview... Refactored out everything several times to make it more compatible... - luvcview: Sdl video Usb Video Class grabber © 2005,2006,2007 Laurent Pinchart && Michel Xhaard - spcaview © 2003,2004,2005,2006 Michel Xhaard - JPEG decoder from http://www.bootsplash.org/ © August 2001 by Michael Schroeder, <[email protected]> - libcamera V4L for Android 2.2 © 2009 0xlab.org - http://0xlab.org/ © 2010 SpectraCore Technologies Author: Venkat Raju <[email protected]> Based on a code from http://code.google.com/p/android-m912/downloads/detail?name=v4l2_camera_v2.patch - guvcview: http://guvcview.berlios.de Paulo Assis <[email protected]> Nobuhiro Iwamatsu <[email protected]> Regarding HDMI and the hwcomposer, i wrote a wrapper to be able to use the old hwcomposer with the 4.2 series. That is why you found the _v0.so file. That module is loaded by our wrapper. Another way to do it is to forward port the old hwcomposer support from 4.1 to 4.2...
  • Create New...

Important Information

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