On Tue, Nov 12, 2013 at 03:39:30PM +0100, Michael Grzeschik wrote: > On Tue, Nov 12, 2013 at 08:12:04PM +0800, Peter Chen wrote: > > On Tue, Nov 12, 2013 at 7:50 PM, Michael Grzeschik > > <m.grzeschik@xxxxxxxxxxxxxx> wrote: > > > Don't start hw_device_state on udc_start. The gadget framework has > > > the prepared pullup callback for this. This is necessary if we use gadgets > > > which need to be enabled after an userspace application got prepared, or > > > other delayed conditiions have passed. > > > > > > Signed-off-by: Michael Grzeschik <m.grzeschik@xxxxxxxxxxxxxx> > > > --- > > > > > > Hi Peter, > > > > > > I checked ci_udc_start again and realized that one problem is > > > that we ignore the pullup call and start the device on udc_start. > > > > > > What do you think of the following patch? Any objections? > > > > > > drivers/usb/chipidea/udc.c | 5 ----- > > > 1 file changed, 5 deletions(-) > > > > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c > > > index b34c819..e673263 100644 > > > --- a/drivers/usb/chipidea/udc.c > > > +++ b/drivers/usb/chipidea/udc.c > > > @@ -1647,11 +1647,6 @@ static int ci_udc_start(struct usb_gadget *gadget, > > > return retval; > > > } > > > > > > - retval = hw_device_state(ci, ci->ep0out->qh.dma); > > > - spin_unlock_irqrestore(&ci->lock, flags); > > > - if (retval) > > > - pm_runtime_put_sync(&ci->gadget.dev); > > > - > > > return retval; > > > } > > > > > Hi Michael, > > > > Your code base seems out of date. > > I used linux/master. Please use usb-next if possible > > > The reason why we need start controller(call hw_device_state) at ci_udc_start: > > > > - For vbus is already there before modprobe gadget, in that case, there > > is no vbus interrupt due to vbus has not changed during the initialization. > > Don't we have another possibility to ask the hardware if the vbus is > connected. We could limit the enabled Interrupts in udc_start to > USBi_PCI. Will it than trigger an interrupt while having the cable > _already_ plugged? If the usbcm.rs is 0, there is no any USB interrupts except USB OTG interrupt, like vbus and ID and USB wakeup interrupt. > > > - For the platforms which have no vbus interrupt, it needs to start controller > > before connection otherwise the enumeration can't be started due to > > usbcmd.rs is 0. > > Then we need to force to start the controller conditionally for those platforms. > IMHO this should not be the case for all platforms. > Of cos, it is not for all platforms. In a word, in order to support uvc use case, there are two places need to be changed like I said at previous email. -- 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
