Subject: Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state
 is wrong
To: John Stultz <john.stultz@linaro.org>,
        John Youn <John.Youn@synopsys.com>
References: <1481075278-17600-1-git-send-email-john.stultz@linaro.org>
 <30669194-dc9c-503b-b84d-a7cfd23bbfa6@synopsys.com>
 <CALAqxLWy3-9-xJpakV-E9fn51s-+CfGLy9V+rUw-jSyX6Q8-FA@mail.gmail.com>
From: John Youn <John.Youn@synopsys.com>
CC: lkml <linux-kernel@vger.kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
        Guodong Xu <guodong.xu@linaro.org>,
        Amit Pundir <amit.pundir@linaro.org>,
        "Rob Herring" <robh+dt@kernel.org>,
        Douglas Anderson <dianders@chromium.org>,
        "Chen Yu" <chenyu56@huawei.com>,
        Kishon Vijay Abraham I <kishon@ti.com>,
        "Felipe Balbi" <felipe.balbi@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Message-ID: <88c3d4f7-5a52-b5ad-12b6-c368ddc32ce5@synopsys.com>
Date: Thu, 8 Dec 2016 15:29:09 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CALAqxLWy3-9-xJpakV-E9fn51s-+CfGLy9V+rUw-jSyX6Q8-FA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5171
Lines: 133

On 12/8/2016 2:43 PM, John Stultz wrote:
> On Tue, Dec 6, 2016 at 7:52 PM, John Youn <John.Youn@synopsys.com> wrote:
>> On 12/6/2016 5:48 PM, John Stultz wrote:
>>> Hey John,
>>>   Just wanted to send this by you, as it seems something is
>>> slightly off with the GOTGCTL state when removing a otg adapter
>>> cable. The following seems to work around the issue I'm seeing.
>>>
>>>
>>> When removing a USB-A to USB-otg adapter cable, we get a change
>>> status irq, and then in dwc2_conn_id_status_change, we
>>> erroniously see the GOTGCTL_CONID_B flag set. This causes us to
>>
>> This is the correct behavior for an OTG controller. When you unplug a
>> cable or plug in the B end of a cable, the ID pin floats, indicating
>> it is a B-Device.
>>
>> When you plug in an A-cable, which is what your adapter is, it will
>> ground the pin, meaning A-device.
> 
> Hrm... So normally, when I plug in the gadget cable into the OTG port,
> I see the change_status irq comes in and the function sees:
> 
> dwc2 f72c0000.usb: gotgctl=4010000
> dwc2 f72c0000.usb: gotgctl.b.conidsts=1
> dwc2 f72c0000.usb: Do port resume before switching to device mode
> dwc2 f72c0000.usb: dwc2_hsotg_enqueue_setup: failed queue (-11)
> dwc2 f72c0000.usb: new device is high-speed
> dwc2 f72c0000.usb: new device is high-speed
> dwc2 f72c0000.usb: new device is high-speed
> dwc2 f72c0000.usb: new address 37
> configfs-gadget gadget: high-speed config #1: b
> 
> Then when I unplug the cable:
> 
> dwc2 f72c0000.usb: gotgctl=2200000
> dwc2 f72c0000.usb: gotgctl.b.conidsts=0
> usb 1-1: reset high-speed USB device number 13 using dwc2
> 
> 
> 
> When I plug in the OTG to USB-A adapter cable w/ a mouse plugged in
> (note I see no change interrupt):
> 
> usb 1-1: USB disconnect, device number 13
> usb 1-1: new low-speed USB device number 14 using dwc2
> input: Logitech USB Optical Mouse as
> /devices/platform/soc/f72c0000.usb/usb1/1-1/1-1:1.0/0003:046D:C058.0003/input/input3
> hid-generic 0003:046D:C058.0003: input,hidraw0: USB HID v1.11 Mouse
> [Logitech USB Optical Mouse] on usb-f72c0000.usb-1/input0
> 
> 
> Then unplugging the OTG to USB-A adapter cable w/ mouse:
> 
> dwc2 f72c0000.usb: gotgctl=4010000
> dwc2 f72c0000.usb: gotgctl.b.conidsts=1
> dwc2 f72c0000.usb: Do port resume before switching to device mode
> dwc2 f72c0000.usb: Waiting for Peripheral Mode, Mode=Host
> 
> <here we get stuck in the loop until it finishes, unless using the
> patch from this thread>
> 
> usb 1-1: USB disconnect, device number 14
> dwc2 f72c0000.usb: gotgctl=2200000
> dwc2 f72c0000.usb: gotgctl.b.conidsts=0
> usb 1-1: new high-speed USB device number 15 using dwc2
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 3 ports detected
> 
> 
> So I only get the change irq when:
> * I plug in a micro-usb-B cable for gadget mode
> * I remove the micro-usb-B cable being used for gadget mode
> * I remove a OTG to USB-A adapter
> 

That's very strange. It's opposite of how it's supposed to work.

> One slight quirk, is that I don't always see the change irq when
> removing the OTG to USB, as if I plug in a highspeed mass-storage
> device, instead of the low-speed mouse, I don't see the change
> interrupt and the device shows up and disappears the same as when I
> plug into the normal USB-A host ports on the board.
> 
> 
>>> get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
>>> spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
>>> until it fails out many seconds later.
>>
>> This is weird. Once the ID pin goes to B, the core should become a
>> peripheral and this should be reflected in the status registers.
>>
>>>
>>> This patch works around the issue by re-reading the GOTGCTL
>>> state to check if the GOTGCTL_CONID_B is still set and if not
>>> restarting the change status logic.
>>
>> This also seems weird. The connector id status shouldn't go back to A,
>> assuming you've left the cable unplugged.
> 
> So I suspect this has something to do with the way the USB-A host
> ports on the board are wired up. As removing the usb-b plug seems to
> switch the device back into A mode.
> 
> One quirk with this board is that the USB-A ports on the board do not
> function if anything is in the OTG/B plug (which is frustrating to use
> at times).
> 

Do you mean there are multiple A-ports on the board hooked up to the
same controller?

If so, that would go a long way towards explaining things. Because the
hsotg is a single-port OTG controller. If there are multiple A-ports,
that means a hub has to be hard-wired internally to the port. But if
that's the case the OTG function won't work because OTG doesn't work
through a hub. It must go directly to the otg port. So there must be
some external logic kicking-in to switch routing to the OTG port or to
the HUB.

This would explain this behavior with the ID pin status. Since hooking
up the HUB would make the controller an A-device whereas normally it
would be a B-device.

> Guodong or Chen Yu understand the hardware details a bit better, and
> might be able to explain more if you need more information.
> 

Yeah it would be good to get some insight into this from a hardware
point of view.

Regards,
John