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
