On Tue, Mar 11, 2014 at 7:22 AM, Ivan T. Ivanov <iivanov@xxxxxxxxxx> wrote: > > > On 03/11/14 14:37, Ivan T. Ivanov wrote: >> >> Hi, >> >> I am wondering... >> >> Probably we have different versions of Android meta-build >> flashed on device (boot-loaders and TZ ...), which means >> that PHY driver relay on some initialization done by aboot? >> >> Right now I am using Android 4.2.2 JDQ39 from Dec 10 2013. >> I will flash more recent version and test. > > > > Flashed latest Intrinsyc release 1.2 (02/25/2014). It is still > working on my side. Hm. Thanks very much for trying things out, sharing your command line, patches and setup, etc. Here is a random stream of thoughts.... On my board, the 3.4 kernel works, and fastboot works, so clearly the hardware is capable of operating correctly. I've tried booting the 3.14 kernel from cold boot (so avoiding USB setup by fastboot), as well as from warm reset. In all cases, the register dumps from the controller and the phy show that the state of the controller and phy are the same between 3.4 and 3.14 when the kernel starts (well, after the register area is mapped, but before the USB driver initializes). However, the state of the registers quickly diverges. In the 3.14 case (at least on my 3.14 kernel, where I have instrumentation *1), I see exactly the same transition every time. The phy hardware gets stuck in a mode where it is NOT seeing vbus valid (while the 3.4 kernel does), and worse, the ULPI_FUNC_CTRL register shows an OpMode of "disable bit-stuff and NRZI encoding" (which is 10b), where the 3.4 kernel shows an OpMode of "normal" (00b). I don't think any communication can happen on the USB bus with the PHY OpMode in this state. Also, on 3.4 the PSPD (port speed) field of the PORTSC register transitions to "High Speed", while in 3.14 the PSPD field stays forever in an unknown (11b) state. Again, I don't think there can be any valid communication on the USB bus when the PHY doesn't even have it's basic speed state correct. I tried a couple of experiments with the 3.4 kernel. USB on 3.4 doesn't work if I switch the otg-control to "phy control" rather than "pmic" control. So I've started looking at the differences in the code paths on 3.4 that are affected by this setting (unfortunately, it's a lot of code). With regard to board version, here is my information: On the daughter-board, there is a white paper sticker which says: Snapdragon 800 Series APQ8074 SOM SN: 199-0200-090813-00331 MAC: 0x00D0CAF1BD81 In white letters on the SOM itself, it has written: APQ8074 SOM DRAGONBOARD 199-0200 *1 - One of my next steps is to instrument the 3.14 code I got from you, to see if I'm getting the same register status as I do with my 3.14 code. All along I have been thinking that my code was not doing something it needed to, in order to reset the PHY (like starting a regulator, setting up a clock, or putting something correct into a register). But I have, by now, a pretty much identical sequence of regulator, clock, reset, interrupt, controller, and phy operations between 3.4 and 3.14. The next thing to look at is if there is any extra relationship between the PMIC and the controller and PHY, that 3.4 handles correctly (or that your code handles correctly on your board), that I'm missing on my board. It's quite frustrating, but thanks very much for your help. -- Tim P.S. Would you mind sending me the output from the following on your tree? 'git log -n 20 --format=format:"%h %t %s" Thanks. -- Tim Bird Senior Software Engineer, Sony Mobile Architecture Group Chair, CE Workgroup, Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
