| Message ID | 1362876568-7082-1-git-send-email-notasas@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Grazvydas Ignotas <notasas@gmail.com> [130309 16:53]: > VBUS_ERROR is a serious error that the driver often doesn't recover from > in my tests, so we should at least inform the user about it. Patch makes sens to me, just a related question.. Do you get this when trying to enable the host mode, right? Or have you seen this in other situations too? If the error happens when enabling the host mode, my experience is that the VBUS_ERROR is caused by the musb trying to be too smart and doing the timeouts automatically. If the VBUS on the hardware does not raise fast enough to the right range for whatever reason, musb can produce this error. Regards, Tony > Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> > --- > drivers/usb/musb/musb_core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index f95404e..df6a54e 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb, > break; > } > > - dev_dbg(musb->controller, "VBUS_ERROR in %s (%02x, %s), retry #%d, port1 %08x\n", > + dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb->controller, > + "VBUS_ERROR in %s (%02x, %s), retry #%d, port1 %08x\n", > otg_state_string(musb->xceiv->state), > devctl, > ({ char *s; > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren <tony@atomide.com> wrote: > * Grazvydas Ignotas <notasas@gmail.com> [130309 16:53]: >> VBUS_ERROR is a serious error that the driver often doesn't recover from >> in my tests, so we should at least inform the user about it. > > Patch makes sens to me, just a related question.. > > Do you get this when trying to enable the host mode, right? Or have you seen > this in other situations too? I sometimes see it when booting with cable connected to PC or connecting cable to PC after using a host adapter. In those cases OTG port dies completely until a powercycle :( > If the error happens when enabling the host mode, my experience is that > the VBUS_ERROR is caused by the musb trying to be too smart and doing the > timeouts automatically. If the VBUS on the hardware does not raise fast > enough to the right range for whatever reason, musb can produce this > error. Yeah the driver seems to expect that and has a "ignore" variable, I use KERN_DEBUG level in case it's set. > > Regards, > > Tony >
* Grazvydas Ignotas <notasas@gmail.com> [130311 10:12]: > On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren <tony@atomide.com> wrote: > > * Grazvydas Ignotas <notasas@gmail.com> [130309 16:53]: > >> VBUS_ERROR is a serious error that the driver often doesn't recover from > >> in my tests, so we should at least inform the user about it. > > > > Patch makes sens to me, just a related question.. > > > > Do you get this when trying to enable the host mode, right? Or have you seen > > this in other situations too? > > I sometimes see it when booting with cable connected to PC or > connecting cable to PC after using a host adapter. In those cases OTG > port dies completely until a powercycle :( Hmm OK. I suspect there's some kernel bug currently with the OTG id pin detection where it's initial state during the boot is ignored. But replugging the cable should fix that, and in your case it sounds like that's not the case. > > If the error happens when enabling the host mode, my experience is that > > the VBUS_ERROR is caused by the musb trying to be too smart and doing the > > timeouts automatically. If the VBUS on the hardware does not raise fast > > enough to the right range for whatever reason, musb can produce this > > error. > > Yeah the driver seems to expect that and has a "ignore" variable, I > use KERN_DEBUG level in case it's set. Yes in the host case I think we then just retry enabling the session bit and don't have anything in place to check that the VBUS regulator is ready or not. Have not looked at that code for a while though. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index f95404e..df6a54e 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb, break; } - dev_dbg(musb->controller, "VBUS_ERROR in %s (%02x, %s), retry #%d, port1 %08x\n", + dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb->controller, + "VBUS_ERROR in %s (%02x, %s), retry #%d, port1 %08x\n", otg_state_string(musb->xceiv->state), devctl, ({ char *s;
VBUS_ERROR is a serious error that the driver often doesn't recover from in my tests, so we should at least inform the user about it. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> --- drivers/usb/musb/musb_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)