Guest brucelee666 Posted July 4, 2012 Report Share Posted July 4, 2012 Eduardo, Thanks the new shuttle clocks fixed the adb/mtp problem, adb connects as normal and mtp mounts and can now see both dirs and the files in those dirs. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 4, 2012 Report Share Posted July 4, 2012 Well, another try at fixing the audio codec... Attached an updated alc5624.c ... I found out that while initializing the codec registers, i was accidentally resetting the codec. That can easily cause problems, as the codec register cache gets out of sync with the values of the codec register. I also found, while inspecting the logs, that when you plug/unplug a headphone, the proper parts of the codec where powered up/down, but no audio routing was done to the proper output was done. To fix that, i had to modify audio_hw.c from our shuttle lunch AOSP device target. Also attached the modified version. I have ran out of time today, so i did not try to compile them. Tomorrow i will do it. Please, if someone wants to try them, first make sure audio_hw,c works with the working audio codec (2802 kernel patch), and then, try the attached codec. Or you can do the opposite, try the codec first, and then, the audio_hw.c. The idea is, if something fails, to be able to identify the culprit. Eduardoalc5624.raraudio_hw.rar Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted July 4, 2012 Report Share Posted July 4, 2012 (edited) Eduardo, My initial findings:- Had to modify the audio_hw.c to get it to compile, I think you changed PERC_TO_CAPTURE_VOLUME to PERC_TO_MIC_VOLUME but had not created a #define or modified the capture define to mic which also meant I changed the intval on MIXED_MIC_CAPTURE to the PREC_TO_MIC - hopefully this was correct. Also as we are using a newer libtinyalsa than the one in aosp to fix the skipping issues we had, the out->config.avail_min was removed and mixer_Ctl_get_name just has (x), this gets it to compile for me) no changes to codec file needed to compile. What I found the audio_hw with the 01/07 audio patch made no change - no sound through speakers but sound via headphones. 28/02 audio with new audio_hw - initially no audio through speakers, plug in headphones and you get audio through them, unplug heaphones and you now get audio through the speakers - got audio through speakers straight away when using old audio_hw and 28/02. 01/07 audio with new codec and audio_hw - no change still no audio via speakers but audio via headphones - attached dmesg with the new files playing music video then plugging/unplugging headphones while playingdmesg_naudcod.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, My initial findings:- Had to modify the audio_hw.c to get it to compile, I think you changed PERC_TO_CAPTURE_VOLUME to PERC_TO_MIC_VOLUME but had not created a #define or modified the capture define to mic which also meant I changed the intval on MIXED_MIC_CAPTURE to the PREC_TO_MIC - hopefully this was correct. Also as we are using a newer libtinyalsa than the one in aosp to fix the skipping issues we had, the out->config.avail_min was removed and mixer_Ctl_get_name just has (x), this gets it to compile for me) no changes to codec file needed to compile. What I found the audio_hw with the 01/07 audio patch made no change - no sound through speakers but sound via headphones. 28/02 audio with new audio_hw - initially no audio through speakers, plug in headphones and you get audio through them, unplug heaphones and you now get audio through the speakers - got audio through speakers straight away when using old audio_hw and 28/02. 01/07 audio with new codec and audio_hw - no change still no audio via speakers but audio via headphones - attached dmesg with the new files playing music video then plugging/unplugging headphones while playing The most strange thing is that, at first sight, erverything seems right.. It would be interesting to try the new alc5624.c with the old tegra_alc5624.c ... Link to comment Share on other sites More sharing options...
Guest grnunn Posted July 4, 2012 Report Share Posted July 4, 2012 01/07 audio with new codec and audio_hw - no change still no audio via speakers but audio via headphones - attached dmesg with the new files playing music video then plugging/unplugging headphones while playing A bit more investigation from the codec end of things.... I have attached an annotated dmesg.txt showing what is happening when the jack is inserted and removed... Basically a lot of sequencing to reduce clicks and pops... very complicated through I understand why they are doing it :) I have also attached a comparison of a register dump from the old audio setup while playing through the speaker with what is written to the device for the same setup. Unfortunately a lot of these registers are undocumented :( It may be worth working through the comparison.txt and checking the undocumented registers.dmesg.txtcomparison.txt Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 4, 2012 Report Share Posted July 4, 2012 A bit more investigation from the codec end of things.... I have attached an annotated dmesg.txt showing what is happening when the jack is inserted and removed... Basically a lot of sequencing to reduce clicks and pops... very complicated through I understand why they are doing it :) I have also attached a comparison of a register dump from the old audio setup while playing through the speaker with what is written to the device for the same setup. Unfortunately a lot of these registers are undocumented :( It may be worth working through the comparison.txt and checking the undocumented registers. Undocumented ? ... Not at all ... All of them are in the datasheet. Registers above 0x7F are, indiced registers... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 4, 2012 Report Share Posted July 4, 2012 Undocumented ? ... Not at all ... All of them are in the datasheet. Registers above 0x7F are, indiced registers... Eduardo, The latest shuttle_clocks.c seems to make USB (at least for me) unstable and makes the tablet lockup... Link to comment Share on other sites More sharing options...
Guest grnunn Posted July 4, 2012 Report Share Posted July 4, 2012 Undocumented ? ... Not at all ... All of them are in the datasheet. Registers above 0x7F are, indiced registers... The ones of interest for me would be 18, 2c and 32. They are all in the control / powerdown section of the register map. Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 4, 2012 Report Share Posted July 4, 2012 Eduardo, The latest shuttle_clocks.c seems to make USB (at least for me) unstable and makes the tablet lockup... From the 3 usb clock lines i added, try to leave just the usbd line... I will post the resulting file later... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 4, 2012 Report Share Posted July 4, 2012 (edited) From the 3 usb clock lines i added, try to leave just the usbd line... I will post the resulting file later... Here is the changed file. Compiled it and flashed it... Will see tomorrow how it holds up... EDIT: I guess that was not the solution.... EDIT2: FYI if i switch to hostmode and back and put in the usb cable i can get an adb connection with the shuttle_clocks.c before you added tose three lines. EDIT3: Hmmm also with the original i get this now... still something funky with usb.. board-shuttle-clocks.c.zip Edited July 4, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted July 4, 2012 Report Share Posted July 4, 2012 (edited) Eduardo / Scanno, I have been trying most of today to get my tablet to freeze unsuccesfully until now, funny thing this happened not long after using shuttle tools to change the usb mode (is it me or do alot of the locks/freezes reported seem to include changing usb mode for ext 3g etc.? or internal 3g/gps) - anyway attached a dmesg for you to look at but copied a brief summary below of what I think is where the lock happens:- [ 2677.397759] tegra-i2c tegra-i2c.3: unexpected status [ 2677.403085] tegra-i2c tegra-i2c.3: unexpected status [ 2678.406098] ------------[ cut here ]------------ [ 2678.410876] WARNING: at drivers/i2c/busses/i2c-tegra.c:664 tegra_i2c_xfer+0x2f0/0x404() [ 2678.437407] Modules linked in: ar6000 [last unloaded: ar6000] [ 2678.443961] [<c0013990>] (unwind_backtrace+0x0/0xf0) from [<c0043618>] (warn_slowpath_common+0x4c/0x64) [ 2678.454596] [<c0043618>] (warn_slowpath_common+0x4c/0x64) from [<c0043648>] (warn_slowpath_null+0x18/0x1c) [ 2678.464496] [<c0043648>] (warn_slowpath_null+0x18/0x1c) from [<c02fe634>] (tegra_i2c_xfer+0x2f0/0x404) [ 2678.474064] [<c02fe634>] (tegra_i2c_xfer+0x2f0/0x404) from [<c02fc410>] (i2c_transfer+0xb4/0x10c) [ 2678.483591] [<c02fc410>] (i2c_transfer+0xb4/0x10c) from [<c02fc8a8>] (i2c_smbus_xfer+0x3ac/0x4f0) [ 2678.492800] [<c02fc8a8>] (i2c_smbus_xfer+0x3ac/0x4f0) from [<c02fca88>] (i2c_smbus_read_i2c_block_data+0x44/0x68) [ 2678.504232] [<c02fca88>] (i2c_smbus_read_i2c_block_data+0x44/0x68) from [<c02ee6c0>] (it7260_read_point_buffer+0x1c/0x50) [ 2678.515801] [<c02ee6c0>] (it7260_read_point_buffer+0x1c/0x50) from [<c02ef7f4>] (it7260_ts_work_func+0x4c/0xe3c) [ 2678.527000] [<c02ef7f4>] (it7260_ts_work_func+0x4c/0xe3c) from [<c0056488>] (process_one_work+0x248/0x3a4) [ 2678.536880] do_write_oob: dma completion timeout [ 2678.542211] [<c0056488>] (process_one_work+0x248/0x3a4) from [<c00569bc>] (worker_thread+0x21c/0x3d8) [ 2678.552474] [<c00569bc>] (worker_thread+0x21c/0x3d8) from [<c005c280>] (kthread+0x80/0x88) [ 2678.560930] [<c005c280>] (kthread+0x80/0x88) from [<c000e7b0>] (kernel_thread_exit+0x0/0x8) [ 2678.569550] ---[ end trace 94a7f5c6d5a0e4f6 ]--- [ 2678.574430] tegra-i2c tegra-i2c.3: i2c transfer timed out, addr 0x0046, data 0xe0 [ 2678.582488] it7260 4-0046: read point buffer failed [ 2678.582635] tegra-i2c tegra-i2c.3: I2c error status 0x00000006 [ 2678.582650] tegra-i2c tegra-i2c.3: arbitration lost during communicate to add 0x34 [ 2678.582664] tegra-i2c tegra-i2c.3: Packet status 0x00010003 [ 2678.582824] tps6586x 4-0034: failed reading at 0x10 [ 2678.582858] tegra-i2c tegra-i2c.3: I2c error status 0x00000006 [ 2678.582871] tegra-i2c tegra-i2c.3: arbitration lost during communicate to add 0x34 [ 2678.582884] tegra-i2c tegra-i2c.3: Packet status 0x00000003 [ 2678.583031] tps6586x 4-0034: failed reading at 0x23 [ 2678.583059] tegra-i2c tegra-i2c.3: I2c error status 0x00000006 [ 2678.583071] tegra-i2c tegra-i2c.3: arbitration lost during communicate to add 0x34 [ 2678.583085] tegra-i2c tegra-i2c.3: Packet status 0x00000003 [ 2678.583228] tps6586x 4-0034: failed reading at 0x10 [ 2678.583239] Failed to set dvfs regulator vdd_cpu [ 2678.666054] it7260 4-0046: failed to read points [2] [ 2678.666465] tegra-i2c tegra-i2c.3: I2c error status 0x00000006 [ 2678.666480] tegra-i2c tegra-i2c.3: arbitration lost during communicate to add 0x34 [ 2678.666494] tegra-i2c tegra-i2c.3: Packet status 0x00000003 Everything before the unexpected status seems normal and after is basically a continuation of the 3 tegra-i2c lines, to me it appears the lock is due to the loss of cummunication with the touchscreen as no touch points are getting through nothing happens so tablet appears frozen but may also may be something in the tps6586x lines ? I have a last_kmsg from a couple of days ago that shows the exact same info above but this was old patches and an old build so is a mess, the one attached is the latest patches (01/07, new audio and clocks with extra usb although not removed the couple of usb entries Scanno has done) edit - for info from between changing the usb mode and the screen frozen the screen got very sensitive and erratic.last_kmsgfrz.zip Edited July 5, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 The ones of interest for me would be 18, 2c and 32. They are all in the control / powerdown section of the register map. No, i don't have info on those regs... Link to comment Share on other sites More sharing options...
Guest Daedric1383 Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) Mine is much worse, i also posted this on vegaream: http://pastebin.com/KMawNFZs Edited July 5, 2012 by Daedric1383 Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 Mine is much worse, i also posted this on vegaream: http://pastebin.com/KMawNFZs Your dmesg is caused by a null pointer in the yaffs filesystem driver, specifically when trying to read the nand chip... Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 Maybe the "lockups" are just the touchscreen that stops responding... At least, that is exactly what i am seeing in the logs. Attached a revised touchscreen driver that tries to recover the touchscreen controller when it detects it is not responding. Hopefully, it will solve the touchscreen issues...nv3.1-4jul.rar Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 The ones of interest for me would be 18, 2c and 32. They are all in the control / powerdown section of the register map. I think those registers control disabled functions in the ALC5624... 18 was for a digital mic, but the alc5624 does not have that input... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 5, 2012 Report Share Posted July 5, 2012 Maybe the "lockups" are just the touchscreen that stops responding... At least, that is exactly what i am seeing in the logs. Attached a revised touchscreen driver that tries to recover the touchscreen controller when it detects it is not responding. Hopefully, it will solve the touchscreen issues... Compiled the kernel so will see today at work how it behaves during the day. Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) Maybe the "lockups" are just the touchscreen that stops responding... At least, that is exactly what i am seeing in the logs. Attached a revised touchscreen driver that tries to recover the touchscreen controller when it detects it is not responding. Hopefully, it will solve the touchscreen issues... Eduardo, Touch screen has issues now (for me) when coming out of sleep. Touchscreen is not responding. Only after a few times sleep/wake up I can use the touch screen again. I do not see the i2c entries in dmesg anymore. EDIT: Seems like it takes a few seconds before the touch screen becomes active. This way you can get into a loop so that you cannot get out of the lock screen. The lock screen will time-out and the tablet will go to sleep again. Waking the tablet up again with the touch screen not active will time-out the lock screen again.... so a nice "loop" is created. If I keep the lock screen awake (say pushing the volume buttons) until the touch screen accepts input, I can get out of this loop. Here is a dmesg http://db.tt/5sO1WJJ8 Edited July 5, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) Eduardo, Touch screen has issues now (for me) when coming out of sleep. Touchscreen is not responding. Only after a few times sleep/wake up I can use the touch screen again. I do not see the i2c entries in dmesg anymore. EDIT: Seems like it takes a few seconds before the touch screen becomes active. This way you can get into a loop so that you cannot get out of the lock screen. The lock screen will time-out and the tablet will go to sleep again. Waking the tablet up again with the touch screen not active will time-out the lock screen again.... so a nice "loop" is created. If I keep the lock screen awake (say pushing the volume buttons) until the touch screen accepts input, I can get out of this loop. Here is a dmesg http://db.tt/5sO1WJJ8 Somehow, i think it is good news... It means with the modified driver, we are able to bring to life the touchscreen. Now, we should just fine-tune a bit, so no delay is perceived by the user, if possible... :) I found an small bug .. That was the cause of the touchscreen controller being reinitialized everytime, instead of just if needed .. Attached a corrected version :Dit7260.rar Edited July 5, 2012 by ejtagle Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 5, 2012 Report Share Posted July 5, 2012 Somehow, i think it is good news... It means with the modified driver, we are able to bring to life the touchscreen. Now, we should just fine-tune a bit, so no delay is perceived by the user, if possible... :) I found an small bug .. That was the cause of the touchscreen controller being reinitialized everytime, instead of just if needed .. Attached a corrected version :D Thanks... finishing up work and going home... and compile a new kernel :) Link to comment Share on other sites More sharing options...
Guest Daedric1383 Posted July 5, 2012 Report Share Posted July 5, 2012 Your dmesg is caused by a null pointer in the yaffs filesystem driver, specifically when trying to read the nand chip... Hello ejtagle! When i said "mine" , i meant the last_kmsg, not my kernel :) It's Scanno's kernel... the latest posted on his vegacream thread (4.1) Any idea what's causing this null pointer ? Link to comment Share on other sites More sharing options...
Guest brucelee666 Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) Thanks Eduardo, Have compiled and now testing new touchscreen driver now, initial thoughts look good:- From quick sleep and wake able to unlock straight away also on a slightly longer sleep so nothing like Scanno mentioned above with last ver, will need to test this further as yesterday as I said it was working fine most of the day and I had been putting in and out of sleep a number of times trying to crash it while browsing playing games etc. like people were posting on tabletroms and the only crash I was able to produce was the one above (i had no reboots or any other issues apart from this, don't think I have ever had an error like Daedric1383 posted). Will carry on testing and report any issues later today if they crop up. edit - spoke to soon managed to make it crash but last_kmsg gave no info, will investigate further Edited July 5, 2012 by brucelee666 Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) Somehow, i think it is good news... It means with the modified driver, we are able to bring to life the touchscreen. Now, we should just fine-tune a bit, so no delay is perceived by the user, if possible... :) I found an small bug .. That was the cause of the touchscreen controller being reinitialized everytime, instead of just if needed .. Attached a corrected version :D Eduardo, Looks pretty good, but still a problem.... touch screen died .... had to reboot, but managed to get a last_kmsg. A lot of messages that the communication to the driver has been lost.. See last_kmsg http://db.tt/BAKfKfb6 Edited July 5, 2012 by Scanno Link to comment Share on other sites More sharing options...
Guest ejtagle Posted July 5, 2012 Report Share Posted July 5, 2012 Eduardo, Looks pretty good, but still a problem.... touch screen died .... had to reboot, but managed to get a last_kmsg. A lot of messages that the communication to the driver has been lost.. See last_kmsg http://db.tt/BAKfKfb6 There are to alternate explanations to this: >Either the touchscreen power supply has been turned off >Or the i2c bus on tegra has somehow stopped working... Question: Did this problem start with the new board-shuttle-clocks.c ? ... Maybe we also need the i2c related clock enabling lines... Link to comment Share on other sites More sharing options...
Guest Scanno Posted July 5, 2012 Report Share Posted July 5, 2012 (edited) There are to alternate explanations to this: >Either the touchscreen power supply has been turned off >Or the i2c bus on tegra has somehow stopped working... Question: Did this problem start with the new board-shuttle-clocks.c ? ... Maybe we also need the i2c related clock enabling lines... Well that is a bit hard to detect because we did still use the previous touchscreen drivers. But i have to say that this happend during watching a video streaming over the network (CIFS share). Not at the lockscreen. But we can try a board-shuttle-clocks.c with the i2c enabling lines in them.... see how that goes... or is there some drawback to this... But i must say that the kernel is pretty stable right now... I put my pov in hostmode and attached an usb to ps/2 converter with mouse & keyboard attached... left it to go in sleep and went away for 15 minutes... still woke up.. but the tablet was warm, so it did not go all the way to sleep... EDIT: I could post a CWM update so more people can test this kernel to see how it works and see if they also have this problem.. Edited July 5, 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