adding Julius here, On Tue, Sep 9, 2014 at 8:12 PM, Felipe Balbi <balbi@xxxxxx> wrote: > On Tue, Sep 09, 2014 at 07:19:50AM +0530, Vivek Gautam wrote: >> Hi, >> >> >> On Mon, Sep 8, 2014 at 7:14 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > Hi, >> > >> > On Mon, Sep 08, 2014 at 09:53:09AM +0530, Vivek Gautam wrote: >> >> On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> >> > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> >> >> > Don't we have phy_power_on() >> >> >> > for that ? It looks like you could just as well do this from >> >> >> > phy_power_on() ? >> >> >> >> >> >> No, unfortunately keeping these calibration settings in phy_power_on() >> >> >> doesn't help, since we need to do this after XHCI reset has happened. >> >> > >> >> > teach xHCI about PHYs ? >> >> >> >> sorry i couldn't understand you here. >> >> Aren't we trying to do the same with Heikki's patch about dwc3 : >> >> [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci >> >> >> >> and the 2nd patch in this series : >> >> [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds >> >> >> >> Is there something else that is expected ? >> > >> > right, use that to call phy_init() at the right time, then you need to >> > add a new ->calibrate() method which, likely, will only be used by you >> > ;-) >> >> so you mean, the xhci should itself call phy_init() at a time suitable, >> so that ->calibrate() is not required at all ? >> >> i think you meant there - "then you __do not__ need to > > right :-) alright, i will prepare a patch for the suggested change. But AFAI remember we had discussion for this patch in earlier version, and Julius suggested to use a generic approach for such change wherein other users in future may be able to use the facility. Julius any thoughts about the change suggested by Felipe. [snip] -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |