RE: [PATCH] usb: gadget: fsl: check vbus presence on probe

[suresh.gupta@xxxxxxxxxxxxx]

> -----Original Message-----
> From: Paul Fertser [mailto:fercerpav@xxxxxxxxx]
> Sent: Friday, May 09, 2014 1:44 AM
> To: Gupta Suresh-B42813
> Cc: balbi@xxxxxx; Li Yang-Leo-R58472; linux-usb@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] usb: gadget: fsl: check vbus presence on probe
> 
> On Thu, May 08, 2014 at 06:42:53PM +0000, suresh.gupta@xxxxxxxxxxxxx
> wrote:
> > > > And Host might be attach after system bootup or after driver
> > > > initialization. So putting this check in probe will not help much.
> > >
> > > If the host is attached after the driver was initialised, the
> > > interrupt will trigger and the driver will get notified that VBUS
> > > appeared and everything will go smooth, at least that's how it
> > > should work (I do not have any board handy to real-life check that,
> > > but AFAICT that's the intent of the current code).
> >
> > If is go through the code flow starting from usb_composite_probe the
> > sequence is
> > usb_composite_probe->usb_gadget_probe_driver->udc_bind_to_driver->
> > udc_bind_to_driver->usb_gadget_udc_start->fsl_udc_start->usbcmd=RUN
> > udc_bind_to_driver->usb_gadget_connect->fsl_pullup
> >
> > The function fsl_pullup make usbcmd=STOP if my fix is not there and if
> > controller is stopped we do not get any interrupt.
> 
> Are you really sure we can't get async VBUS state change notifications
> until controller has USB_CMD_RUN_STOP bit set (and the same bit actually
> controls internal 1.5k dataline pullup)? If yes, I guess it means we need
> to check VBUS state _every_ time we set that bit to sync the vbus_active
> variable with the actual hardware state (unless an external OTG PHY is
> used and VBUS pad state is irrelevant)?

There will be no interrupts if USB_CMD_RUN_STOP is not set but status get change.
I doubt, my previous patch (252455c40316009cc791f00338ee2e367d2d2739) make any difference in your device working.
Can you please remove my patch and check either your device work or not.

We are using two different configs(yours OTG and mine gadget only) that why I did not face the issue.
I remember Balbi suggest me to check hardware to initialize vbus_active. But I am not sure, the proper place to set vbus_active that why I did not implement it.

Balbi can help us to decide which is the proper place to set vbus_active :).

Thanks
      
> 
> > > I actually do not have any iMX demoboards at all, I've only got some
> > > custom-designed i.MX25 boards where I can't control VBUS, it's
> > > permanently pulled up.
> > >
> > > But I was fixing the problem that was clearly, 100% reproducibly
> > > happening when VBUS was applied before the interrupt was configured.
> > > So
> >
> > Wait a minute, are you using OTG. If your VBUS is permanently pulled
> > up, that means you are only Gadget(I might miss something) then why you
> use OTG mode.
> 
> I'm using FSL_USB2_DR_DEVICE mode (FSL_USB2_PHY_UTMI phy_mode), so the
> OTG controller should always work in the device mode only.
> 
> > > what exactly do you mean here? Do you mean this check I've added
> > > doesn't fix the bug? Or do you mean this bug should be fixed somehow
> > > else? Or do
> >
> > What expertly my concern is, probe is not proper place to check VBUS
> valid.
> > I think we should wait to hear what Balbi has to say.
> 
> Yes, I hope he can understand both of us :)
> 
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercerpav@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/