Re: [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux