On Fri, Jul 05, 2013 at 09:35:05AM -0500, Ruchika Kharwar wrote: > > On 07/04/2013 01:26 AM, Ruchika Kharwar wrote: > >DRA7XX has several USB OTG subsystems. USB_OTG_SS1 includes a USB1 and USB2 > >phy. USB_OTG_SS2 includes only a USB2 phy. > >This patch allows the dwc3 probe to continue if a usb3_phy is not found. > The need for this will go away as soon as "of_get_maximum_speed" is > introduced. The speed can then be used to determine if a USB3 phy is > required or not for dra7xx as well. there is one problem with this approach (even my approach which I had cooked before). I was testing OMAP5 today (finally got most pieces in mainline, so I could test something with little out of tree), and as it turns out, the USB3PHY DPLL is used to generate the PIPE3 clock and that clock is used to power some important part of the IP. From what I could grasp out of OMAP5 ES2.0 TRM and Synopsys databook, I believe OMAP5 decided to tie ram_clk to pipe3_clk (the PIP3 bus clock) and if we let USB3 PHY be optional on OMAP5, we might end up with broken DTS files which cause device not to work. That aside, what caught my attention is how the problem exposes itself: We end up in a situation where DWC3_DEPCMD_SETEPCONFIG never completes although the previous DWC3_DEPCMD_DEPSTARTCFG completes just fine. This happens early on, when we're trying to enable physical endpoint 0, then the driver bails out. I'm assuming that DWC3_DEPCMD_DEPSTARTCFG is very easy to process, maybe it just puts the internal FSM into a post-idle state which simply waits for the endpoint configuration to come through the registers while, in turn, DWC3_DEPCMD_DEPSTARTCFG is far more complex to process and needs other parts of the IP to be fully powered and clocked in order to complete. If my speculation is correct thus far, it also means that those blocks are somehow powered by pipe3_clk (or a derivation of it). It would be nice if SNPS could shed some light here, but I'll continue digging the docs, for now the feature of optional USB3PHY will be pending in a separate branch while I try to get all information related to this problem. The decision came after figuring out that if we don't usb_phy_init(dwc->usb3_phy), OMAP5 would never, ever work because the USB3 PHY DPLL is locked in ->init() callback of that driver in ordre to conserve power. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
