Guest Scanno Posted June 24, 2012 Report Share Posted June 24, 2012 (edited) @Eduardo & Brucelee666 With the 3.1 kernel it seems that the wifi problems are gone. Wifi comes back within 10 seconds. Also i have not had the "suspend of death" problem yet. Two problems left: - No sound - No SDcard Regarding SDCard, i cannot see anything in the logs. Anyway here is a logcat : https://dl.dropbox.c...3478/logcat.txt Here is a dmesg: https://dl.dropbox.c...03478/dmesg.txt Hope this helps. Edited June 24, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted June 25, 2012 Report Share Posted June 25, 2012 Scanno, All good news just got back on the PC for the first time since my last post so not looked at anything further. Will re-compile wi-fi first as at least that was an easy fix and get to looking at the other issues later today, on initial look its pretty smooth with this kernel and new libs and now with better power management people should see an improvement once its all fixed and then bring on jelly bean this week poss ? :D Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 25, 2012 Report Share Posted June 25, 2012 Scanno, All good news just got back on the PC for the first time since my last post so not looked at anything further. Will re-compile wi-fi first as at least that was an easy fix and get to looking at the other issues later today, on initial look its pretty smooth with this kernel and new libs and now with better power management people should see an improvement once its all fixed and then bring on jelly bean this week poss ? It is looking pretty good. Think that the suspend also works . Hope the sdcard and audio will work soon also. I have been looking at this for a while and trying different versions of eduardo's patches, but did not succeed. Well at least i got the kernel compiled and wifi working... Hope jelly bean will not be too much work... :D Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted June 25, 2012 Report Share Posted June 25, 2012 (edited) Scanno, Quick look at your dmesg and it would seem maybe these have something to do with sd-card and audio (just need to figure out why):- sdhci-tegra sdhci-tegra.3: SD card wake-up event registrationfailed with eroor: -22 (Above comes from sdhci-tegra.c I think) tegra-snd-alc5624 tegra-snd-alc5624: snd_soc_register_card failed (-19) Edited June 25, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest prober_v2 Posted June 25, 2012 Report Share Posted June 25, 2012 @ejtagle Dear Eduardo, many many thanks for your work on libhuaweigeneric so far!! I'm using Android-X86 on a WeTab / ExoPc with a working version of your lib from https://github.com/rbraken/wetab-ICS-device-tree. I'd like to know, if you found any improvements to the library in the meantime (compared to the last time you posted it here) and if you would like to share the latest version you have. Perhaps as rar as you did in the past. I ask for it, because I have a strange problem: 3G IS working, but no incoming SMS. My phone provider (german O2) seems to sell R-UIM type of SIM cards. In getUICCType() in huaweigeneric-ril.c the card is identified as type 3 via AT^CARDMODE, and so UiccType is set to UICC_TYPE_KNOWN. This document http://www.letswireless.com.cn/asp_bin/downfile/2009929121443234.pdf says, that AT^CARDMODE 0 is Unknown, 1 is SIM, 2 is USIM and 3 is UIM. I admit that the document's about a CDMA type of card, perhaps the atResponse is different, but in the documentation to EM770W (http://www.radiofid.ru/upload_data/at-commands/ES90_AT_COMMANDS_MANUAL_V18.pdf) the card mode command isn't even listed. That leads to the problem that in requestSIM_IO the atRespone from sendSimIOCmdICC runs through convertSimIOFcp, where parseTlv leads to "FCP Property TLV structure" error. So SMS files could not be read. As I only have one SIM card at the moment I don't have the possibility to try it with another card and to see, if this solves the problem. But from what I've read regarding the EF structure on R-UIM cards, the cards should support all three application modes (SIM/USIM/UIM). And this is why I don't understand, what's going on here. Is it possible to force a R-UIM card into a special application mode? Perhaps you have an idea what's happening... Many thanks! Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 26, 2012 Report Share Posted June 26, 2012 @Eduardo, BruceLee666 Since i am not very good in debugging kernels and do not know a lot about kernel / driver programming i am not able to pin-point the problems with sound and sdcard... However i decided to import the kernel sources into eclipse... Now eclipse is nagging about undefined symbols in sdhci-tegra.c: - Symbol CONFIG_HZ could not be resolved - Symbol MXC_GPIO_IRQ_START could not be resolved. - Symbol true could not be resolved In tegra_alc5624.c i get the following: - Field .gpio could not be resolved - Field .invert could not be resolved - Field .jack could not be resolved - Field .report could not be resolved Regards, Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted June 26, 2012 Report Share Posted June 26, 2012 @Eduardo, BruceLee666 Since i am not very good in debugging kernels and do not know a lot about kernel / driver programming i am not able to pin-point the problems with sound and sdcard... However i decided to import the kernel sources into eclipse... Now eclipse is nagging about undefined symbols in sdhci-tegra.c: - Symbol CONFIG_HZ could not be resolved - Symbol MXC_GPIO_IRQ_START could not be resolved. - Symbol true could not be resolved In tegra_alc5624.c i get the following: - Field .gpio could not be resolved - Field .invert could not be resolved - Field .jack could not be resolved - Field .report could not be resolved Regards, Scanno Please, at the start of the alc5624.c file, enable debugging by uncommenting: /*#define DEBUG*/ Also, enable debugging in tegra_alc5624.c, by uncommenting /*#define DEBUG */ at the start of that file, recompile kernel and post the resulting dmesg... I would do it myself, but i am a "little" short of time right now... My suggestion is that you should try to import my latest patchset. Specifically, take the audio parts of it board-shuttle-audio.c and the whole sound directory of my latest patch. Also, take the board-shuttle-sdhci.c to try to fix the sdcard ... and post the resulting dmesg. I have found out that the 3.1 kernel required to update the vold.stab file, as otherwise, the mmc does not automount. But, at least, we should see the mmc detected in kernel logs Link to comment Share on other sites More sharing options...
Guest ejtagle Posted June 26, 2012 Report Share Posted June 26, 2012 @ejtagle Dear Eduardo, many many thanks for your work on libhuaweigeneric so far!! I'm using Android-X86 on a WeTab / ExoPc with a working version of your lib from https://github.com/r...CS-device-tree. I'd like to know, if you found any improvements to the library in the meantime (compared to the last time you posted it here) and if you would like to share the latest version you have. Perhaps as rar as you did in the past. I ask for it, because I have a strange problem: 3G IS working, but no incoming SMS. My phone provider (german O2) seems to sell R-UIM type of SIM cards. In getUICCType() in huaweigeneric-ril.c the card is identified as type 3 via AT^CARDMODE, and so UiccType is set to UICC_TYPE_KNOWN. This document http://www.letswirel...29121443234.pdf says, that AT^CARDMODE 0 is Unknown, 1 is SIM, 2 is USIM and 3 is UIM. I admit that the document's about a CDMA type of card, perhaps the atResponse is different, but in the documentation to EM770W (http://www.radiofid...._MANUAL_V18.pdf) the card mode command isn't even listed. That leads to the problem that in requestSIM_IO the atRespone from sendSimIOCmdICC runs through convertSimIOFcp, where parseTlv leads to "FCP Property TLV structure" error. So SMS files could not be read. As I only have one SIM card at the moment I don't have the possibility to try it with another card and to see, if this solves the problem. But from what I've read regarding the EF structure on R-UIM cards, the cards should support all three application modes (SIM/USIM/UIM). And this is why I don't understand, what's going on here. Is it possible to force a R-UIM card into a special application mode? Perhaps you have an idea what's happening... Many thanks! I will try to take a look at it... Link to comment Share on other sites More sharing options...
Guest prober_v2 Posted June 26, 2012 Report Share Posted June 26, 2012 (edited) I will try to take a look at it... Thanks. I have some further information regarding this problem: First, I modified getCardStatus to return all different types of RIL_APPTYPE_*. That seems to work flawless, even though I think it is not the main problem. Second, and that's more of the real problem, I found out, that the reply to the +CRNM command in sendSimIOCmdICC seems to be too short, there must be something wrong with the interpretation of the length of the response. Have a look at https://github.com/a.../u300-ril-sim.c. Despite the fact, that it's for another kind of GSM modem, the routine is rather interesting. The author separates between sendSimIOCmdICC and sendSimIOCmdUICC. Even my C is not the best, I'll try to integrate his solution into libhuaweigeneric-lib and see what's happening. The reason, why I don't think that it has something to do with the card type beeing R-UIM can also be found in u300-ril-sim.c: his getUICCType command just evaluates +CUAD as stated in ETSI TS 127 007 V10.7.0, chapter 8.49 "UICC Application Discovery" (http://www.etsi.org/deliver/etsi_ts/127000_127099/127007/10.07.00_60/ts_127007v100700p.pdf). The command description just separates between SIM and USIM. R-UIM ist not mentioned and I think it is because the R-UIM can contain all kinds of card applications. Edited June 26, 2012 by prober_v2 Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 26, 2012 Report Share Posted June 26, 2012 Please, at the start of the alc5624.c file, enable debugging by uncommenting: /*#define DEBUG*/ Also, enable debugging in tegra_alc5624.c, by uncommenting /*#define DEBUG */ at the start of that file, recompile kernel and post the resulting dmesg... I would do it myself, but i am a "little" short of time right now... My suggestion is that you should try to import my latest patchset. Specifically, take the audio parts of it board-shuttle-audio.c and the whole sound directory of my latest patch. Also, take the board-shuttle-sdhci.c to try to fix the sdcard ... and post the resulting dmesg. I have found out that the 3.1 kernel required to update the vold.stab file, as otherwise, the mmc does not automount. But, at least, we should see the mmc detected in kernel logs I have your latest patchset from june 24. What needs to be updated in the vold.fstab?. I will enable debug and see what comes up in dmesg. Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 26, 2012 Report Share Posted June 26, 2012 @Eduardo, I uncommented the DEBUG includes in both files but i cannot see much debug info in dmesg... Anyway here is the dmesg; https://dl.dropbox.com/u/15203478/dmesg-2606.txt The problem with the SDCard could be the vold.fstab. If you know what needs to be changed, please let me know. Link to comment Share on other sites More sharing options...
Guest Cass67 Posted June 26, 2012 Report Share Posted June 26, 2012 @Eduardo, I uncommented the DEBUG includes in both files but i cannot see much debug info in dmesg... Anyway here is the dmesg; https://dl.dropbox.com/u/15203478/dmesg-2606.txt The problem with the SDCard could be the vold.fstab. If you know what needs to be changed, please let me know. Looking at that dmesg around 4 seconds in there is bitching about a mmc regulator not found.. looks suspect.. Link to comment Share on other sites More sharing options...
Guest droidbittin Posted June 26, 2012 Report Share Posted June 26, 2012 The Future looks bright, hope you will fix a working 3.0 kernel :) Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 My latest dmesg: https://dl.dropbox.com/u/15203478/dmesg2706.txt Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) My latest dmesg: https://dl.dropbox.c...8/dmesg2706.txt Scanno, You didn't say what you changed but you got rid of the messages Cass mentioned, I was not getting those messages so at a guess you re-copied some files from the patch over your kernel ? OK back to sound this is not really a solution as Eduardo has modified the audio system a bit in his latest patches, but as I could not see any comments in dmesg apart from what I posted above here (am also getting these messages) even after adding the debug option mentioned above. So back to what I did - went back and looked at my dmesg I posted a few days ago 2802patchlog and found that the sd and audio errors seen in above dmesg link were not there so I added the audio system from Eduardos old 2802 patch (basically same as old 39 audio system), doing this means I now have audio working in the 31 kernel. So Scanno find all the relevant audio files in the 2802 patch (loc. mach-tegra,mach-tegra/include,include/sound,sound) and copy over the 31 kernel files and compile this should at least give sound until the code in the latest patches is working - as I said not ideal but you get sound. Edited June 27, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 Scanno, You didn't say what you changed but you got rid of the messages Cass mentioned, I was not getting those messages so at a guess you re-copied some files from the patch over your kernel ? OK back to sound this is not really a solution as Eduardo has modified the audio system a bit since in his latest patches, but as I could not see any comments in dmesg apart from what I posted above here (am also getting these messages) even after adding the debug option mentioned above. So back to what I did - went back and looked at my dmesg I posted a few days ago 2802patchlog and found that the sd and audio errors seen in above dmesg link were not there so I added the audio system from Eduardos old 2802 patch (basically same as old 39 audio system), doing this means I now have audio working in the 31 kernel. So Scanno find all the relevant audio files in the 2802 patch (loc. mach-tegra,mach-tegra/include,include/sound,sound) and copy over the 31 kernel files and compile this should at least give sound until the code in the latest patches is working - as I said not ideal but you get sound. Thanks i will have a look at it. Right now going to sleep. It is after 3 am now (again). I really did not do much. I did a clean merge. I also edited the tegra-nand.c and removed the CONFIG_MTD_PARTITIONS from the source-code so you do not have to change the Kconfig. Also i added a #define DEBUG in the shuttle_sdhci.c file, but that sould not make any difference.... I have the 3.1 nv sources + the 24-06 patches, the tegra_clocks.c and my adjusted tegra_nand.c from the 2802 patches. I have been fiddling with the audio sources but was not succesfull yet. I also was fiddling with the tegra_clocks.c, but the one from 2802 is the only one that is working. I hope that the SDCard is just a mount thing, tried to mount manually, but not succeeded. Hope Eduardo can say something about that. Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 I could not resist and recompiled the kernel with the audio patches from 2802.... and audio is here working also... Now only SDcard left... Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) I could not resist and recompiled the kernel with the audio patches from 2802.... and audio is here working also... Now only SDcard left... Ok how about sd-card now also working - well it is for me (displays in settings storage and mnts as before no change to vold.fstab). Again this is not an ideal solution as its the same as before and using the sdhci and mmc files from the 2802 patch and leaving some files as original from the 3.1 kernel but once done I can now access the sd-card and wi-fi still works (not sure what issues may arise from doing this but it at least got sd working). Copy mach-tegra/include/mach/sdhci.h, drivers/mmc/host/sdhci-tegra.c, include/linux/mmc/sdhci.h - from the original 3.1 kernel and copy them over the files in your working kernel dir (as these were replaced by the 2406 patch but not amended by the 2802 patch). Then from the 2802 patch copy mach-tegra/board-shuttle-sdhci.c, drivers/mmc/core/core.c, drivers/mmc/host/sdhci.c, include/linux/mmc/mmc.h, also in mach-tegra/board-shuttle.h modify extern int shuttle_wifi_set_cd(int val) to extern void shuttle_wifi_set_cd(int val) (to reverse the 2406 patch). As I have said my last 2 posts are not ideal as we are going back rather than fixing and moving forward with Eduardos latest patches but both posts get audio and now sd working so at least we have a starting point where we know they work and try to work out what stops them working with the new patches. Edited June 27, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) @Eduardo, I uncommented the DEBUG includes in both files but i cannot see much debug info in dmesg... Anyway here is the dmesg; https://dl.dropbox.c.../dmesg-2606.txt The problem with the SDCard could be the vold.fstab. If you know what needs to be changed, please let me know. By inspection of the dmesg, i see the codec being detected... alc5624 0-0018: Found codec id : alc5624, Version: 3 But, then tegra-snd-alc5624 tegra-snd-alc5624: snd_soc_register_card failed (-19) This means that the static struct snd_soc_card snd_soc_tegra_alc5624 At tegra_alc5624 is not properly associating the codec driver and the tegra hardware driver to form a sound card... To be exact, the problem should be in the tegra_alc5624_dai struct... By careful inspection, i think i have found the culprit: The codec_dai_name of the BT-SCO stream should read "dit-hifi" instead of "generic_voice_codec" ... Attached latest patchset. The only change is to tegra_alc5624.c ... Hopefully, this will make audio work with the new changes...nv3.1-27jul.rar Edited June 27, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) By inspection of the dmesg, i see the codec being detected... alc5624 0-0018: Found codec id : alc5624, Version: 3 But, then tegra-snd-alc5624 tegra-snd-alc5624: snd_soc_register_card failed (-19) This means that the static struct snd_soc_card snd_soc_tegra_alc5624 At tegra_alc5624 is not properly associating the codec driver and the tegra hardware driver to form a sound card... To be exact, the problem should be in the tegra_alc5624_dai struct... By careful inspection, i think i have found the culprit: The codec_dai_name of the BT-SCO stream should read "dit-hifi" instead of "generic_voice_codec" ... Attached latest patchset. The only change is to tegra_alc5624.c ... Hopefully, this will make audio work with the new changes... Thanks.. Soundcard is detected and running.... but sound level is so low that i cannot hear any sound. I can only hear sound through headphones and volume set to max. EDIT: On second the volume through the headset seems to be ok. But no sound through speakers.. Here is a dmesg with debug enabled: https://dl.dropbox.com/u/15203478/dmesg2706-2.txt Edited June 27, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 Ok how about sd-card now also working - well it is for me (displays in settings storage and mnts as before no change to vold.fstab). Again this is not an ideal solution as its the same as before and using the sdhci and mmc files from the 2802 patch and leaving some files as original from the 3.1 kernel but once done I can now access the sd-card and wi-fi still works (not sure what issues may arise from doing this but it at least got sd working). Copy mach-tegra/include/mach/sdhci.h, drivers/mmc/host/sdhci-tegra.c, include/linux/mmc/sdhci.h - from the original 3.1 kernel and copy them over the files in your working kernel dir (as these were replaced by the 2406 patch but not amended by the 2802 patch). Then from the 2802 patch copy mach-tegra/board-shuttle-sdhci.c, drivers/mmc/core/core.c, drivers/mmc/host/sdhci.c, include/linux/mmc/mmc.h, also in mach-tegra/board-shuttle.h modify extern int shuttle_wifi_set_cd(int val) to extern void shuttle_wifi_set_cd(int val) (to reverse the 2406 patch). As I have said my last 2 posts are not ideal as we are going back rather than fixing and moving forward with Eduardos latest patches but both posts get audio and now sd working so at least we have a starting point where we know they work and try to work out what stops them working with the new patches. Thanks, sound and sdcard now working. I agree that it is not the best solution... I am testing if wifi works without the need of advanced wifi lock and if we do not get the suspend problems. If that all works we can use this until a better solution arrives. If the problems with the .39 kernel are solved with this kernel and patches i think we can use it. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted June 27, 2012 Report Share Posted June 27, 2012 Thanks.. Soundcard is detected and running.... but sound level is so low that i cannot hear any sound. I can only hear sound through headphones and volume set to max. EDIT: On second the volume through the headset seems to be ok. But no sound through speakers.. Here is a dmesg with debug enabled: https://dl.dropbox.c...dmesg2706-2.txt I suspect that now the problem is in the android side. I took some shortcuts when implementing the audio_hw.c android sound driver. Specifically, on the 2.6.39 kernel, i wqas relying on the linux sound card driver to switch between speaker and headphone outs. That is the purpose of the FORCE_AUTO_SPK_HP_SWITCH define you can find in the tegra_alc5624.c linux sound driver. But, this is incorrect. In fact, android provides its own way of switching. In fact, audio output should eb controllable by the android system, and not enforced by the linux kernel. The idea is that android receives a notification of headset plugged/unplugged, and android does the actual switching. To fix this issue, we need to do an slight modification of the audio_hw.c android driver, so it properly handles the switching at the android level. I'll do the mod and post the resulting file. Luckily, It 's not complex at all If you want to confirm that this is indeed, the problem, you can define FORCE_AUTO_SPK_HP_SWITCH at the start of the tegra_alc5624.c linux driver and let linux handle the switching, as it was done before, and audio should start working again :) Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) I suspect that now the problem is in the android side. I took some shortcuts when implementing the audio_hw.c android sound driver. Specifically, on the 2.6.39 kernel, i wqas relying on the linux sound card driver to switch between speaker and headphone outs. That is the purpose of the FORCE_AUTO_SPK_HP_SWITCH define you can find in the tegra_alc5624.c linux sound driver. But, this is incorrect. In fact, android provides its own way of switching. In fact, audio output should eb controllable by the android system, and not enforced by the linux kernel. The idea is that android receives a notification of headset plugged/unplugged, and android does the actual switching. To fix this issue, we need to do an slight modification of the audio_hw.c android driver, so it properly handles the switching at the android level. I'll do the mod and post the resulting file. Luckily, It 's not complex at all If you want to confirm that this is indeed, the problem, you can define FORCE_AUTO_SPK_HP_SWITCH at the start of the tegra_alc5624.c linux driver and let linux handle the switching, as it was done before, and audio should start working again :) Sure i will try that... Can you figure out the sd card problem? With the patches from 2802 the wifi problems return, so that is not really useable. If i can do something to give more info, let me know. EDIT: Uncommenting the FORCE_AUTO_SPK_HP_SWITCH define did NOT solve the problem... Edited June 27, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) Hey Question.... we can reboot into recovery by using the command setrecovery boot-recovery recovery. If i look in the ramdisk (init.harmony.rc) there is a line on property:sys.shutdown.requested=recovery. So i was thinking that that could be used to set the correct partition. But i did not succeed. Perhaps this line is not even called. Anyone have an idea ? EDIT: Never mind...... got it working...... rebooting into recovery from the power menu :-) I changed the following in init.harmony.rc: # Recovery daemon: configure MSC partition service recoveryd /system/bin/setrecovery boot-recovery recovery user root group root oneshot on property:sys.shutdown.requested=1recovery start recoveryd Edited June 27, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest Scanno Posted June 27, 2012 Report Share Posted June 27, 2012 (edited) The 3.1 kernel with "mixed" patches that BruceLee666 found out to make everything work, makes the wifi problems come back. However dmesg seems to give a lot of data.. Here it the dmesg: https://dl.dropbox.c...8/dmesg2806.txt EDIT: Also the suspend problems (i.e. not able to wake-up anymore) are also back. So it has to do with SDHCI implementation somehow.. With the 2706 patch no problems, but with SDCard working bases on the 2802 patches we are back to the old behavior that we have in kernel 2.6.39. Edited June 28, 2012 by Scanno Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now