usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

Tony,

since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb is 
compiled in. The kernel will stuck printing:

** 206 printk messages dropped ** [    8.926727] musb_bus_suspend 2584: 
trying to suspend as a_idle while active

The bisect (log is [1]) points to:
d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error

and reverting the d8e5f0eca1e8 makes the board to boot up fine (Linux 
4.11-rc5 and next-20170331).

any idea on how to fix this w/o reverting the commit?

[1] https://pastebin.com/Z2HJY229

- Péter
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Bin Liu]

On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> Tony,
> 
> since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> is compiled in. The kernel will stuck printing:
> 
> ** 206 printk messages dropped ** [    8.926727] musb_bus_suspend
> 2584: trying to suspend as a_idle while active

Does it sound a similar issue to
http://marc.info/?l=linux-usb&m=149036531809506&w=2

Regards,
-Bin.

> 
> The bisect (log is [1]) points to:
> d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
> 
> and reverting the d8e5f0eca1e8 makes the board to boot up fine
> (Linux 4.11-rc5 and next-20170331).
> 
> any idea on how to fix this w/o reverting the commit?
> 
> [1] https://pastebin.com/Z2HJY229
> 
> - Péter
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170404 05:30]:
> On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > Tony,
> > 
> > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > is compiled in. The kernel will stuck printing:
> > 
> > ** 206 printk messages dropped ** [    8.926727] musb_bus_suspend
> > 2584: trying to suspend as a_idle while active

OK so compiled in. Do you have something connected also when
booting?

> Does it sound a similar issue to
> http://marc.info/?l=linux-usb&m=149036531809506&w=2

Yup.

> > The bisect (log is [1]) points to:
> > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
> > 
> > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > (Linux 4.11-rc5 and next-20170331).

OK thanks for bisecting it.

> > any idea on how to fix this w/o reverting the commit?

I'll take a look.

Regards,

Tony

> > [1] https://pastebin.com/Z2HJY229
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170404 07:06]:
> * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170404 05:30]:
> > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > > Tony,
> > > 
> > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > > is compiled in. The kernel will stuck printing:
> > > 
> > > ** 206 printk messages dropped ** [    8.926727] musb_bus_suspend
> > > 2584: trying to suspend as a_idle while active
> 
> OK so compiled in. Do you have something connected also when
> booting?
> 
> > Does it sound a similar issue to
> > http://marc.info/?l=linux-usb&m=149036531809506&w=2
> 
> Yup.
> 
> > > The bisect (log is [1]) points to:
> > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
> > > 
> > > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > > (Linux 4.11-rc5 and next-20170331).
> 
> OK thanks for bisecting it.
> 
> > > any idea on how to fix this w/o reverting the commit?
> 
> I'll take a look.

OK I was able to reproduce this with loadable modules by reloading
the modules while having OTG-A cable inserted with a hub and USB
drive connected.

Peter, care to check if the following fixes the problem for you?
There should no longer be much any musb core tinkering happening
in the glue layers..

Regards,

Tony

8< -----------------------
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int is_on)
 			}
 
 			otg_set_vbus(otg, 1);
-		} else {
-			musb->is_active = 1;
-			otg->default_a = 1;
-			musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-			devctl |= MUSB_DEVCTL_SESSION;
-			MUSB_HST_MODE(musb);
 		}
 	} else {
 		musb->is_active = 0;
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

Tony,

On 2017-04-05 03:36, Tony Lindgren wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170404 07:06]:
>> * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170404 05:30]:
>>> On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
>>>> Tony,
>>>>
>>>> since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
>>>> is compiled in. The kernel will stuck printing:
>>>>
>>>> ** 206 printk messages dropped ** [    8.926727] musb_bus_suspend
>>>> 2584: trying to suspend as a_idle while active
>>
>> OK so compiled in. Do you have something connected also when
>> booting?
>>
>>> Does it sound a similar issue to
>>> http://marc.info/?l=linux-usb&m=149036531809506&w=2
>>
>> Yup.
>>
>>>> The bisect (log is [1]) points to:
>>>> d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
>>>>
>>>> and reverting the d8e5f0eca1e8 makes the board to boot up fine
>>>> (Linux 4.11-rc5 and next-20170331).
>>
>> OK thanks for bisecting it.
>>
>>>> any idea on how to fix this w/o reverting the commit?
>>
>> I'll take a look.
>
> OK I was able to reproduce this with loadable modules by reloading
> the modules while having OTG-A cable inserted with a hub and USB
> drive connected.
>
> Peter, care to check if the following fixes the problem for you?
> There should no longer be much any musb core tinkering happening
> in the glue layers..

I had similar hunch first, but did not worked. I have tested this patch 
and did not helped.

To be precise this is what I have tried:
- boot w/o cable connected
- boot w/ board connected to PC (device mode)
- boot w/ OTG-A cable with USB keyboard
- boot w/ OTG-A cable connected to powered USB hub and the same keyboard

w/ and w/o this patch I have the same flood of prints in all cases.

Fwiw I have checked where the is_active is set - which causes the prints:
musb_core.c:musb_start()

if (musb->port_mode != MUSB_PORT_MODE_HOST &&
		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
	musb->is_active = 1;
} else {
	devctl |= MUSB_DEVCTL_SESSION;
}

this was the only place where the is_active was set to 1.


> Regards,
>
> Tony
>
> 8< -----------------------
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int is_on)
>  			}
>
>  			otg_set_vbus(otg, 1);
> -		} else {
> -			musb->is_active = 1;
> -			otg->default_a = 1;
> -			musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
> -			devctl |= MUSB_DEVCTL_SESSION;
> -			MUSB_HST_MODE(musb);
>  		}
>  	} else {
>  		musb->is_active = 0;

- Péter
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

On 2017-04-05 10:13, Peter Ujfalusi wrote:
> I had similar hunch first, but did not worked. I have tested this patch
> and did not helped.
>
> To be precise this is what I have tried:
> - boot w/o cable connected
> - boot w/ board connected to PC (device mode)
> - boot w/ OTG-A cable with USB keyboard
> - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
>
> w/ and w/o this patch I have the same flood of prints in all cases.

the config I have for linux-next:
https://pastebin.com/KixvyiRR

>
> Fwiw I have checked where the is_active is set - which causes the prints:
> musb_core.c:musb_start()
>
> if (musb->port_mode != MUSB_PORT_MODE_HOST &&
>         musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
>         (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
>     musb->is_active = 1;
> } else {
>     devctl |= MUSB_DEVCTL_SESSION;
> }
>
> this was the only place where the is_active was set to 1.
>
>
>> Regards,
>>
>> Tony
>>
>> 8< -----------------------
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb
>> *musb, int is_on)
>>              }
>>
>>              otg_set_vbus(otg, 1);
>> -        } else {
>> -            musb->is_active = 1;
>> -            otg->default_a = 1;
>> -            musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
>> -            devctl |= MUSB_DEVCTL_SESSION;
>> -            MUSB_HST_MODE(musb);
>>          }
>>      } else {
>>          musb->is_active = 0;
>
> - Péter
> --
> 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

- Péter
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170405 00:15]:
> Tony,
> 
> On 2017-04-05 03:36, Tony Lindgren wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170404 07:06]:
> > > * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170404 05:30]:
> > > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > > > > Tony,
> > > > > 
> > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > > > > is compiled in. The kernel will stuck printing:
> > > > > 
> > > > > ** 206 printk messages dropped ** [    8.926727] musb_bus_suspend
> > > > > 2584: trying to suspend as a_idle while active
> > > 
> > > OK so compiled in. Do you have something connected also when
> > > booting?
> > > 
> > > > Does it sound a similar issue to
> > > > http://marc.info/?l=linux-usb&m=149036531809506&w=2
> > > 
> > > Yup.
> > > 
> > > > > The bisect (log is [1]) points to:
> > > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
> > > > > 
> > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > > > > (Linux 4.11-rc5 and next-20170331).
> > > 
> > > OK thanks for bisecting it.
> > > 
> > > > > any idea on how to fix this w/o reverting the commit?
> > > 
> > > I'll take a look.
> > 
> > OK I was able to reproduce this with loadable modules by reloading
> > the modules while having OTG-A cable inserted with a hub and USB
> > drive connected.
> > 
> > Peter, care to check if the following fixes the problem for you?
> > There should no longer be much any musb core tinkering happening
> > in the glue layers..
> 
> I had similar hunch first, but did not worked. I have tested this patch and
> did not helped.
> 
> To be precise this is what I have tried:
> - boot w/o cable connected
> - boot w/ board connected to PC (device mode)
> - boot w/ OTG-A cable with USB keyboard
> - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> 
> w/ and w/o this patch I have the same flood of prints in all cases.

OK interesting that it also happens with nothing connected.

> Fwiw I have checked where the is_active is set - which causes the prints:
> musb_core.c:musb_start()
> 
> if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> 		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> 		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> 	musb->is_active = 1;
> } else {
> 	devctl |= MUSB_DEVCTL_SESSION;
> }
> 
> this was the only place where the is_active was set to 1.

That seems normal in musb_start(). Will try with your .config
here.

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

Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170405 06:53]:
> * Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170405 00:15]:
> > To be precise this is what I have tried:
> > - boot w/o cable connected
> > - boot w/ board connected to PC (device mode)
> > - boot w/ OTG-A cable with USB keyboard
> > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > 
> > w/ and w/o this patch I have the same flood of prints in all cases.
> 
> OK interesting that it also happens with nothing connected.
> 
> > Fwiw I have checked where the is_active is set - which causes the prints:
> > musb_core.c:musb_start()
> > 
> > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > 		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > 		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > 	musb->is_active = 1;
> > } else {
> > 	devctl |= MUSB_DEVCTL_SESSION;
> > }
> > 
> > this was the only place where the is_active was set to 1.
> 
> That seems normal in musb_start(). Will try with your .config
> here.

If the the port is configured as OTG, we should not need to
try to force any states during init. The change below will stop
the warnings with your .config, needs to be tested more though
to make sure things still work in all cases.

Regards,

Tony

8< --------------------------
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
 	int ret;
 	struct usb_hcd *hcd = musb->hcd;
 
-	MUSB_HST_MODE(musb);
-	musb->xceiv->otg->default_a = 1;
-	musb->xceiv->otg->state = OTG_STATE_A_IDLE;

Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

Tony,

On 04/05/2017 06:29 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170405 06:53]:
>> * Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170405 00:15]:
>>> To be precise this is what I have tried:
>>> - boot w/o cable connected
>>> - boot w/ board connected to PC (device mode)
>>> - boot w/ OTG-A cable with USB keyboard
>>> - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
>>>
>>> w/ and w/o this patch I have the same flood of prints in all cases.
>>
>> OK interesting that it also happens with nothing connected.
>>
>>> Fwiw I have checked where the is_active is set - which causes the prints:
>>> musb_core.c:musb_start()
>>>
>>> if (musb->port_mode != MUSB_PORT_MODE_HOST &&
>>> 		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
>>> 		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
>>> 	musb->is_active = 1;
>>> } else {
>>> 	devctl |= MUSB_DEVCTL_SESSION;
>>> }
>>>
>>> this was the only place where the is_active was set to 1.
>>
>> That seems normal in musb_start(). Will try with your .config
>> here.
>
> If the the port is configured as OTG, we should not need to
> try to force any states during init. The change below will stop
> the warnings with your .config, needs to be tested more though
> to make sure things still work in all cases.

With this change I can boot up without issues, thanks!
I can not get the kernel to react to anything I plug to the A/B connector. 
Keyboard (directly or via powered hub), flash drive, connecting the board to 
PC. Nothing.
Actually if I connect to a PC I got a print from twl6030 about an interrupt, 
but nothing happens in USB front.
The same thing happens with 4.8, so it is not regression. Most likely it is an 
error in my setup...

Tested-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>

>
> Regards,
>
> Tony
>
> 8< --------------------------
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
>  	int ret;
>  	struct usb_hcd *hcd = musb->hcd;
>
> -	MUSB_HST_MODE(musb);
> -	musb->xceiv->otg->default_a = 1;
> -	musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> -
> +	if (musb->port_mode == MUSB_PORT_MODE_HOST) {
> +		MUSB_HST_MODE(musb);
> +		musb->xceiv->otg->default_a = 1;
> +		musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> +	}
>  	otg_set_host(musb->xceiv->otg, &hcd->self);
>  	hcd->self.otg_port = 1;
>  	musb->xceiv->otg->host = &hcd->self;
>


-- 
Péter
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Bin Liu]

On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170405 06:53]:
> > * Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170405 00:15]:
> > > To be precise this is what I have tried:
> > > - boot w/o cable connected
> > > - boot w/ board connected to PC (device mode)
> > > - boot w/ OTG-A cable with USB keyboard
> > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > > 
> > > w/ and w/o this patch I have the same flood of prints in all cases.
> > 
> > OK interesting that it also happens with nothing connected.
> > 
> > > Fwiw I have checked where the is_active is set - which causes the prints:
> > > musb_core.c:musb_start()
> > > 
> > > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > > 		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > > 		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > > 	musb->is_active = 1;
> > > } else {
> > > 	devctl |= MUSB_DEVCTL_SESSION;
> > > }
> > > 
> > > this was the only place where the is_active was set to 1.
> > 
> > That seems normal in musb_start(). Will try with your .config
> > here.
> 
> If the the port is configured as OTG, we should not need to
> try to force any states during init. The change below will stop

True, but the code has been there for a very long time, any idea what
causes the regression?

Regards,
-Bin.

> the warnings with your .config, needs to be tested more though
> to make sure things still work in all cases.
> 
> Regards,
> 
> Tony
> 
> 8< --------------------------
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
>  	int ret;
>  	struct usb_hcd *hcd = musb->hcd;
>  
> -	MUSB_HST_MODE(musb);
> -	musb->xceiv->otg->default_a = 1;
> -	musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> -
> +	if (musb->port_mode == MUSB_PORT_MODE_HOST) {
> +		MUSB_HST_MODE(musb);
> +		musb->xceiv->otg->default_a = 1;
> +		musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> +	}
>  	otg_set_host(musb->xceiv->otg, &hcd->self);
>  	hcd->self.otg_port = 1;
>  	musb->xceiv->otg->host = &hcd->self;
> -- 
> 2.12.2
--
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: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170406 12:09]:
> On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote:
> > If the the port is configured as OTG, we should not need to
> > try to force any states during init. The change below will stop
> 
> True, but the code has been there for a very long time, any idea what
> causes the regression?

I think it's just that with commit d8e5f0eca1e8 we now have phy enabled
earlier and calling musb_host_setup() with phy enabled sends it into
a loop of trying to force the host mode with nothing connected. This
loops seems to end after few seconds if there are devices connected,
but keeps going if there's nothing connected.

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

Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170406 10:07]:
> Tony,
> 
> On 04/05/2017 06:29 PM, Tony Lindgren wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170405 06:53]:
> > > * Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org> [170405 00:15]:
> > > > To be precise this is what I have tried:
> > > > - boot w/o cable connected
> > > > - boot w/ board connected to PC (device mode)
> > > > - boot w/ OTG-A cable with USB keyboard
> > > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > > > 
> > > > w/ and w/o this patch I have the same flood of prints in all cases.
> > > 
> > > OK interesting that it also happens with nothing connected.
> > > 
> > > > Fwiw I have checked where the is_active is set - which causes the prints:
> > > > musb_core.c:musb_start()
> > > > 
> > > > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > > > 		musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > > > 		(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > > > 	musb->is_active = 1;
> > > > } else {
> > > > 	devctl |= MUSB_DEVCTL_SESSION;
> > > > }
> > > > 
> > > > this was the only place where the is_active was set to 1.
> > > 
> > > That seems normal in musb_start(). Will try with your .config
> > > here.
> > 
> > If the the port is configured as OTG, we should not need to
> > try to force any states during init. The change below will stop
> > the warnings with your .config, needs to be tested more though
> > to make sure things still work in all cases.
> 
> With this change I can boot up without issues, thanks!

OK

> I can not get the kernel to react to anything I plug to the A/B connector.

Yeah it seems that we have only peripheral mode working with panda, so
there seems to be also a long time vbus related regression.

> Keyboard (directly or via powered hub), flash drive, connecting the board to
> PC. Nothing.
> Actually if I connect to a PC I got a print from twl6030 about an interrupt,
> but nothing happens in USB front.
>
> The same thing happens with 4.8, so it is not regression. Most likely it is
> an error in my setup...

For me peripheral mode works fine. You needs at least one gadget
configured, looks like your .config has CONFIG_USB_GADGET disabled.

The VBUS should be coming from twl6030 and it seems to have some vbus
code. Would be nice to get the host mode working on panda too for the
OTG port..

> Tested-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>

OK thanks,

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

Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Bin Liu]

On Fri, Apr 07, 2017 at 06:52:53AM -0700, Tony Lindgren wrote:
> * Bin Liu <b-liu-l0cyMroinI0@public.gmane.org> [170406 12:09]:
> > On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote:
> > > If the the port is configured as OTG, we should not need to
> > > try to force any states during init. The change below will stop
> > 
> > True, but the code has been there for a very long time, any idea what
> > causes the regression?
> 
> I think it's just that with commit d8e5f0eca1e8 we now have phy enabled
> earlier and calling musb_host_setup() with phy enabled sends it into
> a loop of trying to force the host mode with nothing connected. This
> loops seems to end after few seconds if there are devices connected,
> but keeps going if there's nothing connected.

Fair enough. Thanks.
-Bin.

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