lkml.org 
[lkml]   [2016]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
On Thu, Oct 20, 2016 at 01:36:30PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-20 03:10:18)
> > On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-10-19 01:02:11)
> > > > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > > > answer is no. The branch on linaro.org git server from the cover-letter
> > > > > is the branch I've used to test this with. This patch is specifically to
> > > > > fix issues with that design on the db410c board that has only one pin
> > > > > for ID and vbus detection. It's the schematic that we've discussed in
> > > > > another thread.
> > > > >
> > > > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > > > events.
> > > > >
> > > >
> > > > Hmm, in fact, your ID event is the same with vbus event, you take
> > > > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > > > it can work due to it sends EXTCON_USB_HOST event first.
> > > >
> > > > Where you change the USB_SW_SEL_PM pin?
> > >
> > > Currently that is done with the mux driver I sent based on the extcon
> > > event. We don't know if that's before or after the controller handles
> > > the extcon event though, so the pin should probably be changed from the
> > > chipidea driver instead to be more explicit. Why do you ask though?
> >
> > I was just curious how you handle it, now I am clear. From my point,
> > the suitable way may be: mux driver + user app (echo role through
> > debugfs). The extcon-usb-gpio is not necessary, since you have already
> > known role at mux driver.
> >
> > The current kernel has no framework to handle dual-role switch at kernel
> > space.
>
> Ok. I'm planning that as future work after this set of patches is
> merged.
>
> > > > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > > > /* Clear and enable BSV irq */
> > > > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > > > OTGSC_BSVIS | OTGSC_BSVIE);
> > > > + /* vbus change may has already been occurred */
> > >
> > > "vbus change may have already occurred"?
> >
> > Yes, will change.
> >
>
> Great. Should I wait to incorporate your change into my series, or will
> you apply the usb patches and Kishon can apply the phy patches? This
> patch #11 should be dropped, but otherwise I don't think there's
> anything left to do for this series.

I tested my patch, it works well at my side, if it is ok for you, please
ack it, I will apply it as well as your chipidea series after your
gpu fix patch at greg's usb-next tree.

Is it ok for you?

--

Best Regards,
Peter Chen

\
 
 \ /
  Last update: 2016-10-21 04:16    [W:0.095 / U:3.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site