Hello Peter, On 16-04-27 13:41:35, Peter Chen wrote: > On Wed, Apr 27, 2016 at 10:20:53AM +0530, maitysanchayan@xxxxxxxxx wrote: > > > > > > Do you know the connect/disconnect by using USB Cable (not ID cable), I > > > just want to know if the software can know connection, > > > > I did not understand this? Can you elaborate? > > When the board connects to PC, does the software know connection event? > Eg, there is 5v on vbus or there is a gpio toggle event. > > > > > > if not, please > > > try below patch on the top of this patch set, my patch set can't cover > > > this case for dual-role switch. > > > > Can you give me some pointers in the right direction to look and work on > > so I can also try to upstream our use case? > > > > It depends on my above comments. > > First, could you see the correct ID event? Check ci_handle_id_switch to > see if the ID event is correct, and the switch between host and device mode > are correct. After looking into this some more, I noticed a few things. Regarding this patchset and existing code 1. With this DP_ALWAYS_PULLUP patch, if the USB client cable is connected on boot and then disconnected I always see the stack trace I reported earlier. It seems the disconnection generates an IRQ but none of the interrupt bits are set when I try to print "intr" in udc_irq resulting in return of IRQ_NONE and the corresponding stack trace that no one cared about this IRQ and it has been disabled. Not sure why this happens but shouldn't one of the INTR bits be set if IRQ was generated? 2. The notifiers get called which in turn call ci_irq manually. Now if ci_otg_queue_work is not called nothing is gonna work further. We call ci_read_otgsc where we mimick or fake the OTG register reads, but, IDIE and BSVIE are never set in that function so I don't see how the correspoding if checks in ci_irq will ever succeed? Also I don't see fake_otgsc being used /set anywhere? My own doubts 3. Atleast for Vybrid wouldn't use of DUAL_ROLE_NOT_OTG be more appropriate? I do not completely understand the DP_ALWAYS_PULLUP case. Wouldn't it be required to have vbus connect and disconnect called as per the connection? 4. Even without point 3 above, in ci_handle_id_switch we call ci_otg_role which should not be applicable since here we do not want to touch any OTG register. hw_wait_reg also reads the OTG registers in ci_handle_id_switch. 5. Though the use of extcon specifies different gpio for ID and VBUS in our case, we need both notifiers to act for this to work, vbus connect/ disconnect and role change. My understanding as of now would be to have the same phandle for both.? Thanks. Regards, Sanchayan. > > Second, if your platform doesn't know connect and disconnect event, > if nothing is connected, make sure you are at device mode and dp > is pulled up (usbcmd.rs =1). > > Peter > > > > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c > > > index 6986a50..d9a0119 100644 > > > --- a/drivers/usb/chipidea/udc.c > > > +++ b/drivers/usb/chipidea/udc.c > > > @@ -1960,6 +1960,9 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci) > > > ci_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE, > > > OTGSC_BSVIS | OTGSC_BSVIE); > > > > > > + if (ci->dp_always_pullup) > > > + usb_gadget_vbus_connect(&ci->gadget); > > > + > > > return 0; > > > } > > > > > > > Tried the above none the less, but no change in previous observations. > > > > > > -- > > Best Regards, > Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
