> On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > > Hi, > > > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > > Hi, > > > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > > >> From: Santhapuri, Damodar <damodar.santhapuri@xxxxxx> > > >> > > >> AM335x uses NOP transceiver driver and need to enable > builtin PHY > > >> by writing into usb_ctrl register available in system control > > >> module register space. This is being added at musb glue driver > > >> layer untill a separate system control module driver is > available. > > >> > > >> Signed-off-by: Ajay Kumar Gupta <ajay.gupta@xxxxxx> > > >> Signed-off-by: Santhapuri, Damodar <damodar.santhapuri@xxxxxx> > > >> Signed-off-by: Ravi Babu <ravibabu@xxxxxx> > > > > > > Kishon, you were adding a real phy driver for OMAP's internal phy > > > logic on one of your patches and I believe this will > conflict with > > > your changes, right ? > > > > Indeed. My final patch of that series removes some of the functions > > from omap_phy_internal.c (which was taken care in the phy driver). > > > > > > How does this look to you ? Is this at least correct ? I > suppose the > > > correct way would be to actually have the system control module > > > driver which we have been waiting, right ? > > > > Correct. I think once we have the system control module driver in > > place, we'll have everything wrt control module register writes > > implemented in correct way. > > So $SUBJECT will pretty much be thrown away once we have SCM > driver, in that case it's best to wait a bit longer and apply > this series once SCM driver is available and after your > series too... you agree ? > Felipe, I am sure there are patches in this series[0/13], which are not dependent on this patch or control module, Can we pull in those patches (all dual instances support patches)? So that I can re-work and submit again? > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html