2850 replies to this topic

[ejtagle]

DerArtem, on 13 February 2013 - 07:55 PM, said:

It look like the problem is somewhere else.

There is the bdt tool to test bluedroid. When enabeling BT and then disabling is says that BT is already disabled. Looks like BT is not getting marked as enabled correctly...

root@android:/ # bdt														
set_aid_and_cap : pid 1221, uid 0 gid 0
:::::::::::::::::::::::::::::::::::::::::::::::::::
:: Bluedroid test app starting
Loading HAL lib + extensions
HAL library loaded (Success)
INIT BT
HAL REQUEST SUCCESS
>enable
ENABLE BT
HAL REQUEST SUCCESS
>disable
DISABLE BT
Bluetooth is already disabled

I/bluedroid( 778): enable
D/bt-btif ( 778): BTIF ENABLE BLUETOOTH
D/BTIF_CORE( 778): not disabled
E/BluetoothAdapterState( 778): Error while turning Bluetooth On

I/bluedroid( 1197): init
D/btif_config.c( 1197): btif_config_init(L124): in initialized:0
D/bt-btif ( 1197): in initialized:0
D/btif_config.c( 1197): dump_node(L117): root, p->name:Bluedroid, child/value:0x40548588, bytes:160, p->used:0, type:0, p->flag:0
D/bt-btif ( 1197): ts[7].used:0
D/bt-btif ( 1197): alloc_thread_slot ret:7
D/bt-btif ( 1197): h:7, cmd_fdr:7, cmd_fdw:10
D/bt-btif ( 1197): h:7, thread id:1079281200
I/bte_conf( 1197): Attempt to load stack conf from /etc/bluetooth/bt_stack.conf
D/btif_config.c( 1197): dump_node(L117): found node, p->name:Address, child/value:0x405487f0, bytes:18, p->used:18, type:1, p->flag:0
D/bt-btif ( 1197): local bdaddr from bt_config.xml is 22:22:7e:b9:ed:31
I/GKI_LINUX( 1197): gki_task_entry: gki_task_entry task_id=1 [BTIF] starting
D/bt-btif ( 1197): btif task starting
D/bt-btif ( 1197): btif_associate_evt: notify ASSOCIATE_JVM
E/BTIF_CORE( 1197): ### ASSERT : external/bluetooth/bluedroid/main/../btif/src/btif_core.c line 487 Callback is NULL (0) ###
I/bluedroid( 1197): enable
D/bt-btif ( 1197): BTIF ENABLE BLUETOOTH
D/bt-btif ( 1197): bte_main_enable
I/bt_hci_bdroid( 1197): init
I/bt_vendor( 1197): init
I/bt_vnd_conf( 1197): Attempt to load conf from /etc/bluetooth/bt_vendor.conf
I/bt-btif ( 1197): libbt-hci init returns 0
I/bt_hci_bdroid( 1197): bt_hc_worker_thread started
I/GKI_LINUX( 1197): gki_task_entry: gki_task_entry task_id=0 [BTU] starting
I/bt_userial_vendor( 1197): userial vendor open: opening hci0
I/bt_userial_vendor( 1197): device fd = 11 open
E/bt_vendor( 1197): vendor lib fw conf done
I/bt-btif ( 1197): HC preload_cb 0 [0:SUCCESS 1:FAIL]
I/	 ( 1197): BTE_InitTraceLevels -- TRC_HCI
I/	 ( 1197): BTE_InitTraceLevels -- TRC_L2CAP
I/	 ( 1197): BTE_InitTraceLevels -- TRC_RFCOMM
I/	 ( 1197): BTE_InitTraceLevels -- TRC_AVDT
I/	 ( 1197): BTE_InitTraceLevels -- TRC_AVRC
I/	 ( 1197): BTE_InitTraceLevels -- TRC_A2D
I/	 ( 1197): BTE_InitTraceLevels -- TRC_BNEP
I/	 ( 1197): BTE_InitTraceLevels -- TRC_BTM
I/	 ( 1197): BTE_InitTraceLevels -- TRC_PAN
I/	 ( 1197): BTE_InitTraceLevels -- TRC_SDP
I/	 ( 1197): BTE_InitTraceLevels -- TRC_BTAPP
D/bt-btif ( 1197): btif_task: received trigger stack init event
I/bluedroid( 1197): enable
D/bt-btif ( 1197): BTIF ENABLE BLUETOOTH
D/BTIF_CORE( 1197): not disabled

I did an small modification (attached!) to the bluedroid library, to add debug dumps on reads and writes of the HCI channel. After deselecting the following options in the kernel config, i seem to be getting answers to the queries of the bluedroid stack -- Nevertheless, something seems to be missing. Maybe you will be luckier than me with the ar6003...


# CONFIG_BT_L2CAP is not set
# CONFIG_BT_SCO is not set
# CONFIG_BT_RFCOMM is not set
# CONFIG_BT_RFCOMM_TTY is not set
# CONFIG_BT_BNEP is not set
# CONFIG_BT_BNEP_MC_FILTER is not set
# CONFIG_BT_BNEP_PROTO_FILTER is not set
# CONFIG_BT_HIDP is not set

Also attached, for reference, the userial_vendor.c I am using...

Attached Files

•  userial_vendor.rar   1.75K   12 downloads
•  userial.rar   3.92K   7 downloads

[Scanno]

Eduardo,

I asked in the google android forum about support  for other bt  chipsets. I got the answer below:

=====================================

Bluedroid does support other chipsets. Nexus 4 uses Qualcomm Bluetooth controller. You can take it as an example.
Multi-channel transport is supported. Please see: external/bluetooth/bluedroid/hci/src/hci_mct.c

All the source codes are provided.

====================================

I am sure you haad a look thus, but just in case....

[ejtagle]

Scanno, on 17 February 2013 - 08:31 PM, said:

Eduardo,

I asked in the google android forum about support  for other bt  chipsets. I got the answer below:

=====================================

Bluedroid does support other chipsets. Nexus 4 uses Qualcomm Bluetooth controller. You can take it as an example.
Multi-channel transport is supported. Please see: external/bluetooth/bluedroid/hci/src/hci_mct.c

All the source codes are provided.

====================================

I am sure you haad a look thus, but just in case....

Yes, but Qualcomm also supports H4. I wrote a utility that was supposed to switch our bt chipset to the H4 from the BCSP protocol, and found out that the rom inside the bt chipset does not support it - When trying to switch it to H$, the bt chip`just stops responding.

I have written a h4 to linux kernel HCI layer, and i got some sort of pseudo working thing... But bluedroid stack seems to talk to the chip, but something seems to be missing... I still have to investigate this issue a little bit more  ...

[fosser2]

Hey ejtagle,

I'm wondering what the function of the file "board-shuttle-bootinfo.c" is. I'm trying to figure out if it will help our tablet or if its just for debugging purposes. Thanks!

[ejtagle]

fosser2, on 24 February 2013 - 02:42 AM, said:

Hey ejtagle,

I'm wondering what the function of the file "board-shuttle-bootinfo.c" is. I'm trying to figure out if it will help our tablet or if its just for debugging purposes. Thanks!

Debugging purposes, only...

[fosser2]

ejtagle, on 24 February 2013 - 09:55 PM, said:

Debugging purposes, only...

That's what I thought thanks

EDIT:  I'm attempting to figure out where the libcamera drivers you guys are using originated from. If you could point me to them it would be a great help. Thanks!

EDIT2: Does the vega have hdmi and how is that working? I switched over to your libs yesterday and I lost the video portion of hdmi (I still have audio over hdmi).
EDIT3: After renaming hwcomposer.tegra_v0.so to hwcomposer.tegra.so hdmi is back and working. I'm wondering if you guys have that lib named incorrectly (just a heads up)

Edited by fosser2, 25 February 2013 - 06:08 PM.

[ejtagle]

fosser2, on 24 February 2013 - 10:01 PM, said:

That's what I thought thanks

EDIT:  I'm attempting to figure out where the libcamera drivers you guys are using originated from. If you could point me to them it would be a great help. Thanks!

EDIT2: Does the vega have hdmi and how is that working? I switched over to your libs yesterday and I lost the video portion of hdmi (I still have audio over hdmi).
EDIT3: After renaming hwcomposer.tegra_v0.so to hwcomposer.tegra.so hdmi is back and working. I'm wondering if you guys have that lib named incorrectly (just a heads up)

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, <mls@suse[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.c...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...

[fosser2]

ejtagle,

I'm wondering what happens when you guys have hdmi plugged into your tablet and you try to sleep it. Our tablet surfaceflinger crashes because of gralloc.tegra.so. Was gralloc patched also for 4.2? Below is the crash.

ADB: http://pastebin.com/v15a0WGP
SERIAL: http://pastebin.com/dx0Xb23Y

I believe it is a lib issue related to the gralloc. As for the IRQ issue in the serial file, I believe this is caused from some i2c settings. I'm not overly concerned about that right now because I'm pretty sure they are 2 separate issues. Lastly HDMI does output as well as hdmi audio. Just likes to crash when someone attempts to sleep w/ hdmi plugged in.

[ejtagle]

fosser2, on 28 February 2013 - 08:34 PM, said:

ejtagle,

I'm wondering what happens when you guys have hdmi plugged into your tablet and you try to sleep it. Our tablet surfaceflinger crashes because of gralloc.tegra.so. Was gralloc patched also for 4.2? Below is the crash.

ADB: http://pastebin.com/v15a0WGP
SERIAL: http://pastebin.com/dx0Xb23Y

I believe it is a lib issue related to the gralloc. As for the IRQ issue in the serial file, I believe this is caused from some i2c settings. I'm not overly concerned about that right now because I'm pretty sure they are 2 separate issues. Lastly HDMI does output as well as hdmi audio. Just likes to crash when someone attempts to sleep w/ hdmi plugged in.

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...

[ejtagle]

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.

Attached Files

•  hwc.rar   11.62K   8 downloads

[ejtagle]

ejtagle, on 02 March 2013 - 04:28 AM, said:

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.

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...

[Scanno]

ejtagle, on 02 March 2013 - 02:33 PM, said:

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...

Thanks,

I am building a new version of CM10.1 with the new hwc.
I will post it as alpha13 (lucky number hopefully).

Edited by Scanno, 02 March 2013 - 02:40 PM.

[Scanno]

Sadly the new hwcomposer did not solve the SOD problem

[fosser2]

Ejtagle,

I tried out the new HWC and although hardware decoding still works I'm having the same issues with HDMI.

ADB: http://pastebin.com/wJkasPxp (at 16:10:01.341 I pushed sleep button)
Serial: http://pastebin.com/t11uHjiw

Scanno: we seem to have sleep working (without HDMI) on our tablet. From this log you can see that my tablet enters and exits LP1 as it should. We are having other users tablets SOD though. Their last_kmsg files look similar to the following.
http://pastebin.com/9xd96dVz

Edited by fosser2, 03 March 2013 - 10:18 PM.

[ejtagle]

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)

Attached Files

•  rel-15r7.rar   304.69K   12 downloads
•  wlan_wow.rar   1.05MB   12 downloads

Edited by ejtagle, 03 March 2013 - 10:20 PM.

[ejtagle]

fosser2, on 03 March 2013 - 10:12 PM, said:

Ejtagle,

I tried out the new HWC and although hardware decoding still works I'm having the same issues with HDMI.

ADB: http://pastebin.com/wJkasPxp (at 16:10:01.341 I pushed sleep button)
Serial: http://pastebin.com/t11uHjiw

Scanno: we seem to have sleep working (without HDMI) on our tablet. From this log you can see that my tablet enters and exits LP1 as it should. We are having other users tablets SOD though. Their last_kmsg files look similar to the following.
http://pastebin.com/9xd96dVz

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...

Edited by ejtagle, 04 March 2013 - 02:55 AM.

[ejtagle]

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

Attached Files

•  etc.rar   1.81K   7 downloads
•  libbt-vendor.rar   50.48K   7 downloads

[fosser2]

ejtagle, on 03 March 2013 - 11:08 PM, said:

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)

Does this crash happen on the vega too like I posted?

ejtagle, on 03 March 2013 - 11:08 PM, said:

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...

I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi.

Edited by fosser2, 04 March 2013 - 03:06 AM.

[ejtagle]

fosser2, on 04 March 2013 - 03:06 AM, said:

Does this crash happen on the vega too like I posted?


I don't actually try to resume my tablet when this crash happens. As soon as I put it to sleep while on hdmi is when everything errors. It never makes it into LP1 while on hdmi.

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...

Edited by ejtagle, 04 March 2013 - 03:33 AM.

[Scanno]

ejtagle, on 04 March 2013 - 01:21 AM, said:

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

Great I will have a go at this. The old Bluetooth stuff is that still needed or can in remove that?
I mean the hciattach. Is that now included?