Here's some more progress. I can successfully get the dragonboard to establish a USB connection to the host (have the host enumerate it) with this code, but only if I first boot the machine to fastboot, then boot the kernel from ramboot. When I boot the kernel from RAM, the device comes right up, after the g_zero module is loaded. Ivan, Can you tell me if you are booting from RAM or from flash? If you are booting from RAM (doing something like 'fastboot boot boot.img' to start the kernel), then could you try instead writing the kernel to flash and booting directly to it, without first going into fastboot, and let me know what happens. In my situation, clearly there's some element of hardware setup that fastboot does that my kernel can rely upon for working, that my kernel alone does not perform. Thanks for any info you can provide. -- Tim On Wed, Mar 12, 2014 at 8:13 AM, Tim Bird <tbird20d@xxxxxxxxx> wrote: > 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 -- -- 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
