Re: [PATCH 0/4] musb fixes for v4.9-rc cycle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bin,

On Friday 11 Nov 2016 17:06:02 Bin Liu wrote:
> On Sat, Nov 12, 2016 at 12:11:04AM +0200, Laurent Pinchart wrote:
> > On Friday 11 Nov 2016 08:53:22 Tony Lindgren wrote:
> >> * Bin Liu <b-liu@xxxxxx> [161111 08:25]:
> >>> On Fri, Nov 11, 2016 at 01:39:28AM +0200, Laurent Pinchart wrote:
> >>>> On Friday 11 Nov 2016 00:27:52 Laurent Pinchart wrote:
> >>>>> On Thursday 10 Nov 2016 13:42:34 Tony Lindgren wrote:
> >>>>>> * Laurent Pinchart [161110 13:29]:
> >>>>>>> I had to disable CONFIG_USB_GADGET is compiling it as a module
> >>>>>>> prevents selecting CONFIG_NOP_USB_XCEIV=y, which is a dependency
> >>>>>>> for CONFIG_USB_EHCI_HCD_OMAP=m.
> >>>>>>> 
> >>>>>>> The new configuration resulted in a few changes, among which the
> >>>>>>> most notable is
> >>>>>>> 
> >>>>>>> -# CONFIG_USB_MUSB_HOST is not set
> >>>>>>> -# CONFIG_USB_MUSB_GADGET is not set
> >>>>>>> -CONFIG_USB_MUSB_DUAL_ROLE=y
> >>>>>>> +CONFIG_USB_MUSB_HOST=y
> >>>>>>> 
> >>>>>>> I then get the same error as originally reported.
> >>>>>> 
> >>>>>> Yeah OK, that's the problem.. We still have musb hardware
> >>>>>> trying to do things on it's own and phy trying to detect
> >>>>>> the state.
> >>>>>> 
> >>>>>> Any ideas why we have a dependency like that in Kconfig?
> >>>>> 
> >>>>> Well, with CONFIG_USB_GADGET disabled, I don't expect
> >>>>> CONFIG_USB_MUSB_GADGET to be enabled. MUSB can only operate in host
> >>>>> mode in that case, so musb-> xceiv->otg->state = OTG_STATE_A_IDLE
> >>>>> makes sense.
> >>>> 
> >>>> I've tried to investigate this but I'm not familiar enough with the
> >>>> MUSB driver to reach any conclusion. Felipe, if you have time could
> >>>> you give me a hand ?
> >>>> 
> >>>> To summarize the issue, on a pandaboard-es where the MUSB is wired to
> >>>> an OTG connector with mode rightfully set to MUSB_PORT_MODE_DUAL_ROLE
> >>>> in DT, a kernel configured with CONFIG_USB_MUSB_HOST=y (for instance
> >>>> because CONFIG_USB_GADGET is disabled) will print an endless stream
> >>>> of the following meessage.
> >>>> 
> >>>> [    2.766174] musb_bus_suspend 2586: trying to suspend as a_idle
> >>>> while active
> >>> 
> >>> I don't have a omap3/4 platform to test on this, but I don't see this
> >>> problem on am335x board.
> > 
> > Which board is that ? For the problem to occur the board has to have an
> > OTG connector.
> 
> It is the TI am335x GP EVM, which usb0 port has an otg receptacle, and a
> power switch controlled by usb0 drvvbus pin.
> 
> >>>> musb_init_controller() performs the following actions
> >>>> 
> >>>>         case MUSB_PORT_MODE_DUAL_ROLE:
> >>>>                 status = musb_host_setup(musb, plat->power);
> >>>>                 if (status < 0)
> >>>>                         goto fail3;
> >>>>                 status = musb_gadget_setup(musb);
> >>>>                 if (status) {
> >>>>                         musb_host_cleanup(musb);
> >>>>                         goto fail3;
> >>>>                 }
> >>>>                 status = musb_platform_set_mode(musb, MUSB_OTG);
> >>>>                 break;
> >>>> 
> >>>> and as gadget support is disabled musb_gadget_setup() compiles to a
> >>>> no-op inline function. The system is thus configured in host mode by
> >>>> musb_host_setup() with musb->xceiv->otg->state = OTG_STATE_A_IDLE. A
> >>>> later call to musb_start() verifies the condition
> >>>> 
> >>>>         if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> >>>>             musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> >>>>             (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> >>> 
> >>> To get there, devctl[MUSB_DEVCTL_VBUS] bits have to be set, where does
> >>> the vbus voltage come from? Session is not on yet.
> > 
> > MUSB_DEVCTL is first set to 0 by musb_generic_disable() called from
> > musb_init_controller(). The register is then left untouched (as far as I
> > can tell, I've intercepted all musb_writeb() and musb_readb() calls)
> > until musb_start() to reads the register. The read value has BDEVICE and
> > VBUS=3 set.
>
> The DEVCTL_VBUS bits are set by the controller, when it sense VBUS
> voltage > VBUS_VALID.
> 
> >>>> and sets musb->is_active to 1. Later, musb_bus_suspend() complains
> >>>> because is_active is not 0.
> >>>> 
> >>>> What is wrong in that sequence ?
> >> 
> >> I think the issue is pandaboard connected to a PC with mini-B
> >> cable while musb is being forced to host mode?
> > 
> > The issue also occurs when the cable isn't connected.
> 
> If the otg port is not connected to a host but you still get VBUS=3, the
> vbus voltage must be provided from the board itself. We have to check
> the schematics to see how it is possible. This is pandaboard es, right?
> Assume I will be able to find its schematics on internet...

http://pandaboard.org/sites/default/files/board_reference/ES/750-2170-002-sch_revb.pdf

It would seem that the voltage is provided by the TWL6030. I'm not sure what's 
turning it on as the MUSB driver doesn't seem to perform any set_vbus call in 
the faulty configuration (I've traced musb_platform_set_vbus(), 
omap2430_musb_set_vbus(), otg_set_vbus(), omap_usb_set_vbus() and 
twl6030_set_vbus() and none of them get called).

An interesting point to note is that the TWL6030 gets probed after MUSB when 
MUSB is configured in host mode only, and that happens after the call to 
musb_start().

-- 
Regards,

Laurent Pinchart

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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux