Guest brucelee666 Posted July 2, 2012 Report Share Posted July 2, 2012 (edited) Scanno, From the dmesg posted I've pulled these lines out I think relevant:- <3>[ 100.046198] tegradc tegradc.1: error reading edid <6>[ 108.089917] tegradc tegradc.1: Using mode 1280x720 pclk=74250000 href=1 vref=1 <6>[ 108.099040] tegradc tegradc.1: display detected <3>[ 108.137359] tegradc tegradc.1: can't divide 2500000 clock to 74250000 -1/+9% 0 73507500 80932500 <4>[ 119.183618] WARNING: at arch/arm/mach-tegra/clock.c:299 clk_disable+0x38/0x60() <4>[ 119.191059] Attempting to disable clock hdmi with refcnt 0 Do a search for the "error reading edid" and it seems to suggest an itc/clock/timing issue, the 2500000 value seems to come from the hdmi clock value set in "board-shuttle-clocks.c". Now nvidia changed the dc clock rate to be dynamic based on the monitors/tv edid data this may be part to blame ? Edited July 3, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest Daedric1383 Posted July 2, 2012 Report Share Posted July 2, 2012 Got 3G working, chmod 7755 /system/bin/pppd might be overkill, i get : ls -la pppd -rwsr-sr-t root shell 135588 2008-08-01 13:00 pppd ifconfig ppp0 ppp0: ip 37.28.196.202 mask 255.255.255.255 flags [up point-to-point running mul ticast] going to run a few more tests, that SIM is blocked until i "charge" it (with €) Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 Scanno, From the dmesg posted I've pulled these lines out I think relevant:- <3>[ 100.046198] tegradc tegradc.1: error reading edid <6>[ 108.089917] tegradc tegradc.1: Using mode 1280x720 pclk=74250000 href=1 vref=1 <6>[ 108.099040] tegradc tegradc.1: display detected <3>[ 108.137359] tegradc tegradc.1: can't divide 2500000 clock to 74250000 -1/+9% 0 73507500 80932500 <4>[ 119.183618] WARNING: at arch/arm/mach-tegra/clock.c:299 clk_disable+0x38/0x60() <4>[ 119.191059] Attempting to disable clock hdmi with refcnt 0 Do a search for the "error reading edid" and it seems to suggest an itc/clock/timing issue, the 2500000 value seems to come from the hdmi clock value set in "board-shuttle-clocks.c". Now nvidia changed the dc clock rate to be dynamic based on the monitors/tv edid data this may be part to blame ? Eduardo, Brucelee666 I am at a loss... 3g os not working with the new kernel with the latest patches (also not with the old). Logcat keeps saying that the kernel does not support ppp. It is configured. I compared my config with the config from BruceLee666 and the lines regarding PPP are te same. Perhaps there are config changes that need to be applied with the 3.1 kernel that i am missing. With regard to HDMI... this is not working. Logcat shows messages about gralloc not available. This with both the old prop. files as with the new ones... Do not have time now for logcats because its late here and have to get to work in 6 hours... so need sleep. EDIT: Ok here is the dmesg: https://dl.dropbox.c.../logs/dmesg.txt Here is the logcat: https://dl.dropbox.c...logs/logcat.txt This is with the HDMI problem. OK while I have a moment, touchscreen not fully working but with a mixture of the touch input it has and mouse and rotating the tablet to avoid the area that does not process touches correctly I can workaround it. Have compiled a new kernel with latest patch 0107 patch change to nvec seems to have fixed not recognizing charger, ts seems to operate as before, still need amended clocks file (see below) and probably still need 2802 tegra_nand file not compared with patch yet so maybe not - and it still does not output sound through the speakers, sound via headphones works fine will look at and try to provide any logs or info that may help. Have attached a modified tegra2_clocks file that is a merge between 2802 and the original 3.1, this will work with the new nvec in the 0107 patch as it has the i2c-div value set (not done in 2802 file but need due to change in nvec) the original file still does not boot as I said before due to this commit I think as its the only thing not merged into this new file and when it is results in a non-flashing boot image. Eduardo hopefully you can see something that may be causing this as I am sure you would rather use the original file rather than another workaround. edit - attached a zip of logcat and dmesg from latest build, going to look through and see if anything stands out but may be worth checking over to see if anyone else sees something - put tablet to sleep a couple of times to give that info and listened to audio (I don't have 3g so wi-fi only also newer version of the nvidia libs used) did notice also that when mtp connected it did display the sd-card and the dirs but not the content of those dirs ? edit2 - Attached my latest config just for info, first impressions of my latest build are so far good seems more stable All these problems are caused by our board-shuttle-clocks.c file. On previous kernels, we needed to enable all clocks manually, but, on the newer kernels, most enabling/disabling and configuring of clocks is done by the drivers that use them. We must relax the clock generation tables ... :) ... As the shuttle p10an01 is based on the Nvidia Harmony design, let's use the clock tables of Harmony and see what happens :) ...board-shuttle-clocks.rar Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 Got 3G working, chmod 7755 /system/bin/pppd might be overkill, i get : ls -la pppd -rwsr-sr-t root shell 135588 2008-08-01 13:00 pppd ifconfig ppp0 ppp0: ip 37.28.196.202 mask 255.255.255.255 flags [up point-to-point running mul ticast] going to run a few more tests, that SIM is blocked until i "charge" it (with €) Thanks.... that did the trick... got 3g working again... writing this on my tablet through 3g.... Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted July 3, 2012 Report Share Posted July 3, 2012 Scanno, Okay now with Eduardos new "board-shuttle-clocks.c" file you can now use the original 3.1 version of the "tegra2_clocks.c" file, the patched one it would seem is no longer needed :) - thanks Eduardo. Compiled and flashed a boot image with both of these files and the process now completes and boots as normal, and on inital use everything seems ok but will need to test further (don't have hdmi cable to test but hopefully with the hardcoded hdmi clock values now removed from shuttle-clocks it should work). Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 Scanno, Okay now with Eduardos new "board-shuttle-clocks.c" file you can now use the original 3.1 version of the "tegra2_clocks.c" file, the patched one it would seem is no longer needed :) - thanks Eduardo. Compiled and flashed a boot image with both of these files and the process now completes and boots as normal, and on inital use everything seems ok but will need to test further (don't have hdmi cable to test but hopefully with the hardcoded hdmi clock values now removed from shuttle-clocks it should work). Tonight i will build a new kernel and try out HDMI and see if it works. Will let you know. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 So, the only thing missing is to fix the audio subsystem ... :D ... We need to know why the audio only outputs through the headphone jack... I already implemented the audio equalizer, it was in the latest patchset. Yo can modify the setting using tinyalsa utilities (it is a prt of AOSP, and already compiled into the image :) ... Link to comment Share on other sites More sharing options...
Guest Oldbarzo Posted July 3, 2012 Report Share Posted July 3, 2012 So, the only thing missing is to fix the audio subsystem ... :D ... We need to know why the audio only outputs through the headphone jack... I already implemented the audio equalizer, it was in the latest patchset. Yo can modify the setting using tinyalsa utilities (it is a prt of AOSP, and already compiled into the image :) ... Hi Sorry if I am being stupid but I am running scanno's Beta 4 and the audio through the speakers is working OK. Just watched a movie on Netflix with no problems. Stransky Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 (edited) Hi Sorry if I am being stupid but I am running scanno's Beta 4 and the audio through the speakers is working OK. Just watched a movie on Netflix with no problems. Stransky That is because I used the old audio implementation that is still working. It is not the preferred implementation of the audio drivers, but it is working pretty well. Until the new drivers are working, I am using the old audio drivers in the boot.img that is included in beta4. If the HDMI problem is solved with the latest shuttle_clocks.c i will release a new beta for people to test. But this will still include the old audio drivers. The 3g problem is hopefully solved. I have to change the install script for that. Edited July 3, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 (edited) The idea of fixing audio in the latest patchset is because, the latest patchset is closer to nvidia's mainline kernel... I suppose the problem is a very silly one, shouldn't be hard to solve. And i wouldn't be surprised if, once it works, porting the shuttle support to the latest nvidia kernel becomes trivial and works out of the box :) ... (there are nearly no changes from the 3.1 to the latest one related to hardware configuration :) )... Related to the causes of the problem, i think they could eb realted to the latest changes in ALSA SOC codec register cache implementation. I think that having a dmesg with the latest audio codec, and DEBUG enabled in it ... and plugging and unplugging the headset should output the codec register writes. With them, we can find out if something is missing or not... ;) Edited July 3, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 The idea of fixing audio in the latest patchset is because, the latest patchset is closer to nvidia's mainline kernel... I suppose the problem is a very silly one, shouldn't be hard to solve. And i wouldn't be surprised if, once it works, porting the shuttle support to the latest nvidia kernel becomes trivial and works out of the box :) ... (there are nearly no changes from the 3.1 to the latest one related to hardware configuration :) )... Related to the causes of the problem, i think they could eb realted to the latest changes in ALSA SOC codec register cache implementation. I think that having a dmesg with the latest audio codec, and DEBUG enabled in it ... and plugging and unplugging the headset should output the codec register writes. With them, we can find out if something is missing or not... ;) OK I will compile the kernel with the new audio driver and the new shuttle_clocks.c to see if all is working and give you a dmesg. Oh and hopefully not forget to uncomment the debug include :) Link to comment Share on other sites More sharing options...
Guest grnunn Posted July 3, 2012 Report Share Posted July 3, 2012 OK I will compile the kernel with the new audio driver and the new shuttle_clocks.c to see if all is working and give you a dmesg. Oh and hopefully not forget to uncomment the debug include :) If I can get a copy of the this kernel then it should be pretty easy to see what is wrong from the audio codec register map. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 If I can get a copy of the this kernel then it should be pretty easy to see what is wrong from the audio codec register map. Sometimes, it is not as easy... The last time the problem was an intermediate codec register cache implemented by ALSA, that refused to write the required values to the codec registers. Luckily, this time, the alc5624 driver intercepts the writes and reads, and dumps them to the kernel log :) ... so we are able to see if something is not being written, as it should... :) Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 (edited) @Eduardo HDMI is working now... ...and offcourse i forgot to uncomment the DEBUG include ...... Recompile.... Edited July 3, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 (edited) @Eduardo HDMI is working now... ...and offcourse i forgot to uncomment the DEBUG include ...... Recompile.... :D We are getting very close to a fully operational kernel :) Edited July 3, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 :D Dmesg: https://dl.dropbox.com/u/15203478/logs/dmesg.txt Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 I am still using the tegra_nand.c from 2802 though Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 I am still using the tegra_nand.c from 2802 though There is a way to use the mainline tegra_nand.c file, Modify the 2802 tegra_nand.c file and between the *chip_id = readl(RESP_REG); and the return 0; add pr_info("NAND: chip id: 0x%08x\n", *chip_id); Recompile and boot the kernel. using dmesg, find the NAND: chip id value and report it back. With that value, i can modify the board-shuttle-nand.c file to supply the correct nand id ... and we should be able to use the main tegra_nand.c file. My only concern is that maybe there are some shuttle tablets that are using different nand chips, and that id varies with the exact model... That is why i preferred to relax the id matching, instead of modifying the table... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 There is a way to use the mainline tegra_nand.c file, Modify the 2802 tegra_nand.c file and between the *chip_id = readl(RESP_REG); and the return 0; add pr_info("NAND: chip id: 0x%08x\n", *chip_id); Recompile and boot the kernel. using dmesg, find the NAND: chip id value and report it back. With that value, i can modify the board-shuttle-nand.c file to supply the correct nand id ... and we should be able to use the main tegra_nand.c file. My only concern is that maybe there are some shuttle tablets that are using different nand chips, and that id varies with the exact model... That is why i preferred to relax the id matching, instead of modifying the table... I do not need to use the main tegra_nand.c file. I did not realize that you preferred the old one. Using the 2802 version is perfectly fine with me. Did my dmesg help in identifying why the speakers do not work? Do you need some more information? Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 3, 2012 Report Share Posted July 3, 2012 I do not need to use the main tegra_nand.c file. I did not realize that you preferred the old one. Using the 2802 version is perfectly fine with me. Did my dmesg help in identifying why the speakers do not work? Do you need some more information? It would be nice to also enable debugging in the alc5624.c file. Probably the problem is there ;) -- I think i have such dmesg ... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 3, 2012 Report Share Posted July 3, 2012 It would be nice to also enable debugging in the alc5624.c file. Probably the problem is there ;) -- I think i have such dmesg ... If you still need it, let me know then i will recompile the kernel. For today i am quitting. I need sleep... Link to comment Share on other sites More sharing options...
Guest grnunn Posted July 3, 2012 Report Share Posted July 3, 2012 If you still need it, let me know then i will recompile the kernel. For today i am quitting. I need sleep... From your dmesg of 27 June 2012 - 10:12 AM where you first said that you had audio problems: 0x02 : 0x4040 - Full Volume on speaker amp 0x04 : 0x4040 - Full volume on headphone amp 0x0c : 0x6000 - DAC to stereo mixer selected with 12dB gain - Sometime this is set to 6808 (0dB gain) - this may be our clipping 0x1c : 0x6b00 - HP and Speaker drivers connected to stereo mixer So the basic routing looks right... Need to check: 1.) Setup of the speakers BTL vs single ended 2.) Power down registers Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted July 4, 2012 Report Share Posted July 4, 2012 (edited) Eduardo, I don't know if you still need them, but attached 2 dmesg files with both debug set on both alc5624.c and tegra_alc5624.c:- First - From boot, play youtube vid then exit and go play music, no headphones - speakers only. Second - From boot, connect/disconnect headphones a couple of times, then with headphones in go play youtube vid while video playing disconnect/re-connect headphones, then go play music with headphones in and again while playing disconnect/re-connect headphones and finally at the end just disconnect headphones. Also adb/mtp is not working PC does not recognize it is connected and android does not go into adb mode (dmesg shows nothing), do we need to add something back to the shuttle-clocks file (to late for me to check any further on this) ?dmesg_audiodeb1.zipdmesg_audiodeb2.zip Edited July 4, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 4, 2012 Report Share Posted July 4, 2012 Eduardo, I don't know if you still need them, but attached 2 dmesg files with both debug set on both alc5624.c and tegra_alc5624.c:- First - From boot, play youtube vid then exit and go play music, no headphones - speakers only. Second - From boot, connect/disconnect headphones a couple of times, then with headphones in go play youtube vid while video playing disconnect/re-connect headphones, then go play music with headphones in and again while playing disconnect/re-connect headphones and finally at the end just disconnect headphones. Also adb/mtp is not working PC does not recognize it is connected and android does not go into adb mode (dmesg shows nothing), do we need to add something back to the shuttle-clocks file (to late for me to check any further on this) ? If USB was working with the previous board-shuttle-clock.c, and now it does not, i presume some clock is missing...Attached a new board-shuttle-clocks.c that forces USB clocks to be run... Maybe that will be enough.. ;)board-shuttle-clocks.rar Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 4, 2012 Report Share Posted July 4, 2012 From your dmesg of 27 June 2012 - 10:12 AM where you first said that you had audio problems: 0x02 : 0x4040 - Full Volume on speaker amp 0x04 : 0x4040 - Full volume on headphone amp 0x0c : 0x6000 - DAC to stereo mixer selected with 12dB gain - Sometime this is set to 6808 (0dB gain) - this may be our clipping 0x1c : 0x6b00 - HP and Speaker drivers connected to stereo mixer So the basic routing looks right... Need to check: 1.) Setup of the speakers BTL vs single ended 2.) Power down registers I am a little worried about this... Maybe the ALSA soc register cache is playing with us again... :S ... 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