[PATCH] usb: musb: log VBUS error

[PATCH] usb: musb: log VBUS error

[Grazvydas Ignotas]

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(-)

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

Re: [PATCH] usb: musb: log VBUS error

[Tony Lindgren]

* Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: log VBUS error

[Grazvydas Ignotas]

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
>

-- 
Gražvydas
--
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

Re: [PATCH] usb: musb: log VBUS error

[Tony Lindgren]

* Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [130311 10:12]:
> On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > * Grazvydas Ignotas <notasas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html