On Tue, Apr 8, 2008 at 3:06 PM, Bryan Wu <cooloney@xxxxxxxxxx> wrote: > On Tue, Apr 8, 2008 at 12:05 AM, David Brownell <david-b@xxxxxxxxxxx> wrote: > > On Monday 07 April 2008, Felipe Balbi wrote: > > > I recall having some issues on 100mA devices. During enumeration some > > > current spikes a few mAs above 100mA were occuring and we couldn't > > > enumerate the device due to vbus_err interrupt. > > > > Yeah, I think the Mentor core is unduly sensitive to voltage > > fluctuation during enumeration. There's supposed to be about > > 100 msec before VBUS must stabilize ... but the silicon doesn't > > seem to accept routine instabilities in that period, and then > > reports inappropriate VBUS errors. > > > > For this VBUS error, Blackfin MUSB port follows other platforms idea to retry. > > But to this bug, the ZiO card reader will trigger the mode change > maybe due to the VBUS drop. > It should be different as the VBUS error in the enumeration, because > the enumeration of the ZiO > is OK. > > And for our development board EZKIT548, it can provide 500mA current > at 5V as it claimed in manual > with a external regular. So from my point of view, this bug is not > related with 100mA current limit issue. > > These days I tried hard to workaround this issue, but failed: - When VBUS_ERR happens in OTG_A_HOST state and the OTG is in peripheral mode, I try to start a new session and power on VBUS. - CONNECT IRQ fired and OTG is switch back to host mode. - In CONNECT IRQ handler, I rescan the musb->endpoint[i].in_qh or musb->endpoint[i].out_qh. Then resume the urb transfer which was stopped by the wrong VBUS_ERR mode switch IRQ. or just dequeue the urb to call off the transfer. - But the ZiO does not reply anymore. No IRQ from USB hardware. World keeps silence. I think this kind of devices maybe should be added to the blacklist of the musb otg driver. Do you guys have some idea about that? Thanks a lot -Bryan Wu -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
