RE: [PATCH 0/7][v4] Add OTG support for FSL socs

[Ramneek Mehresh]

> -----Original Message-----
> From: Jun Li [mailto:jun.li@xxxxxxx]
> Sent: Wednesday, December 23, 2015 10:02 PM
> To: Mehresh Ramneek-B31383 <ramneek.mehresh@xxxxxxxxxxxxx>; Felipe
> Balbi <balbi@xxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> Cc: stern@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-
> usb@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> 
> 
> 
> > -----Original Message-----
> > From: Ramneek Mehresh [mailto:ramneek.mehresh@xxxxxxxxxxxxx]
> > Sent: Wednesday, December 23, 2015 8:20 PM
> > To: Jun Li <jun.li@xxxxxxx>; Felipe Balbi <balbi@xxxxxx>; linux-
> > kernel@xxxxxxxxxxxxxxx
> > Cc: stern@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-
> > usb@xxxxxxxxxxxxxxx
> > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> >
> >
> >
> > > -----Original Message-----
> > > From: Jun Li [mailto:jun.li@xxxxxxx]
> > > Sent: Wednesday, December 23, 2015 10:36 AM
> > > To: Felipe Balbi <balbi@xxxxxx>; Mehresh Ramneek-B31383
> > > <ramneek.mehresh@xxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> > > Cc: stern@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-
> > > usb@xxxxxxxxxxxxxxx
> > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> > >
> > > Hi
> > >
> > > > -----Original Message-----
> > > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-
> > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Balbi
> > > > Sent: Wednesday, December 23, 2015 2:21 AM
> > > > To: Ramneek Mehresh <ramneek.mehresh@xxxxxxxxxxxxx>; linux-
> > > > kernel@xxxxxxxxxxxxxxx
> > > > Cc: stern@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-
> > > > usb@xxxxxxxxxxxxxxx
> > > > Subject: RE: [PATCH 0/7][v4] Add OTG support for FSL socs
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Ramneek Mehresh <ramneek.mehresh@xxxxxxxxxxxxx> writes:
> > > > >> -----Original Message-----
> > > > >> From: Felipe Balbi [mailto:balbi@xxxxxx]
> > > > >> Sent: Saturday, October 10, 2015 3:04 AM
> > > > >> To: Mehresh Ramneek-B31383
> <ramneek.mehresh@xxxxxxxxxxxxx>;
> > > linux-
> > > > >> kernel@xxxxxxxxxxxxxxx
> > > > >> Cc: stern@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx;
> > > > >> linux- usb@xxxxxxxxxxxxxxx; Mehresh Ramneek-B31383
> > > > >> <ramneek.mehresh@xxxxxxxxxxxxx>
> > > > >> Subject: Re: [PATCH 0/7][v4] Add OTG support for FSL socs
> > > > >>
> > > > >> Felipe Balbi <balbi@xxxxxx> writes:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > Ramneek Mehresh <ramneek.mehresh@xxxxxxxxxxxxx> writes:
> > > > >> >> Add support for otg for all freescale socs having internal
> > > > >> >> usb
> > phy.
> > > > >> >>
> > > > >> >> Ramneek Mehresh (7):
> > > > >> >>   usb:fsl:otg: Make fsl otg driver as tristate
> > > > >> >>   usb:fsl:otg: Add controller version based ULPI and UTMI phy
> > > > >> >>   usb:fsl:otg: Add support to add/remove usb host driver
> > > > >> >>   usb:fsl:otg: Signal host drv when host is otg
> > > > >> >>   usb:fsl:otg: Modify otg_event to start host drv
> > > > >> >>   usb:fsl:otg: Combine host/gadget start/resume for ID change
> > > > >> >>   usb:fsl:otg: Add host-gadget drv sync delay
> > > > >> >
> > > > >> > Unless Alan's okay with the host side changes, I can't accept
> > > > >> > any of these. However, I must say some of the flags you add
> > > > >> > here already exist in some way, shape or form. For example,
> > > > >> > look at
> > > > is_b_host flag.
> > > > >>
> > > > >
> > > > > Could you please be more specific...which flag you think that I
> > > > >should remove/I'm re-defining. The flags I'm defining are:
> > > > >
> > > > > have_hcd : defined in fsl specific structure for fsl specific
> > > > > use-case
> > > > >
> > > > > had_hcd: defined in fsl specific structure for fsl specific
> > > > > use-case
> > > > >
> > > > > is_otg : defined in include/linux/usb.h
> > > > >
> > > > > Are you suggesting using otg_port or is_b_host instead of is_otg?
> > > > >
> > > > > As I understand, is_b_host is specifically to check if an otg B
> > > > > device is in host mode...correct?  I just need a flag to check
> > > > > if a controller is capable of otg operations? That's why defined
> > "is_otg"
> > > > > flag. Please suggest.
> > > >
> > > > no, I don't know why I made that comment. You could use otg_port,
> > > > but that wouldn't look very clean. Can you resend with Alan's ack,
> > > > then I'll move this series into testing/next.
> > > >
> > > > --
> > > > balbi
> > >
> > > Can you directly put the change_hcd_work in its phy driver(phy-fsl-
> > usb.c)?
> > > Then add/remove hcd will not through ehci_fsl_drv_suspend/resume,
> > > With this, you can make it work without a new flag "is_otg".
> > >
> > change_hcd_work() changes host controller mode, and hence, should be
> > in host controller driver.
> 
> Reasonable, but most of OTG stuff not belong to phy actully, I see phy-msm-
> usb.c directly do hcd add/remove for OTG.
> 
Thanks for your input...but I still strongly believe that controller specific data structure and flags
should remain inside the controller drv...to make things more maintainable. I'm adding and removing
host controller driver on the basis of the id change value for fsl controller drv...
> > To move this to phy driver (just to avoid usage of a single flag)
> > won't be a good idea.
> 
> I just saw you simply still use the suspend/resume method, but the
> change_hcd_work actually has nothing to do with it now, 
change_hcd_work() is a work that is scheduled via suspend/resume to
remove/add host controller drv...
then add a flag to
> return for it, also the flag in your usage is not to indicate if the host
> capable/enabled otg, but something like
> is_host_role_to_be_changed_for_otg(test and then clear).
> 
Actually...you're right in usage of is_host_role_to_be_changed_for_otg(test and then clear)...
this could be a better way to do this...however I also use have_hcd flag to remove host drv for 
the first time. On fsl platforms, gadget is the default mode, and hence, I need to remove host drv 
as soon as it is loaded. In addition, I was thinking that it might be a good idea to have information
inside ehci_fsl struct to know if host drv is loaded currently....may be used for some 
future implementation... 
> Meanwhile you add another 2 flags in ehci_fsl(have_hcd, add_hcd) also for
> OTG host add/remove, so I am thinking if all those can be simplified.
> 
thanks for your input ...have_hcd helps in determining if the host controller drv is already up...so I need to 
remove it in order to load gadget driver, and add_hcd simply tells me if I need to bring-up
host driver again, and remove gadget driver....these are essential mechanisms for adding/removing
host controller drv...again moving them to phy layer is not very convincing.... 
> > In this case, I'll also have to move some host controller specific
> > flags to phy drv which won't be correct.
> 
> >
> > > Li Jun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/