From: Chen Yu <chenyu56@huawei.com>
To: John Stultz <john.stultz@linaro.org>
Cc: <wangbinghui@hisilicon.com>, John Youn <John.Youn@synopsys.com>,
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>,
"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>
Subject: Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state is wrong
Date: Fri, 9 Dec 2016 18:07:04 +0800 [thread overview]
Message-ID: <eb1e045b-1ea4-caaa-79fe-6e4e01514490@huawei.com> (raw)
In-Reply-To: <CALAqxLWnPDhwH+6kYBv47nNFVK_bR7tsz18No015m8zedMQSyQ@mail.gmail.com>
On 2016/12/9 15:32, John Stultz wrote:
> On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu <chenyu56@huawei.com> wrote:
>> On 2016/12/9 7:29, John Youn wrote:
>>> 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:
>>>>>> 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.
>>>
>>
>> Actually, I'm not very clear about the hardware details.
>>
>> In simple terms, there are two Type A USB 2.0 host ports and one microUSB OTG port on the front edge of the board.
>> The two Type A USB 2.0 host ports connect to a high-speed hub and the hub connect to a USB Switch to which the microUSB OTG port
>> also connect.
>> If the Vbus of the microUSB OTG port was high or the ID of the microUSB OTG port was low, the Switch will switch the DP and DM of the SOC
>> to microUSB OTG port. If no cable was inserted to microUSB OTG port, the Switch will switch the DP and DM of the SOC to the high-speed hub.
>> There is another import point, the ID pin of soc will be pulled high in both cases:
Sorry, I made a mistake here, the ID pin of soc will be pulled low in both cases:
>> 1.no cable is inserted to microUSB OTG port
>> 2.cable is inserted to microUSB OTG port and ID of microUSB OTG port is low.
>>
>> If my explanation confuse you, maybe these documents can be helpful.
>>
>> 1、https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/HardwareDocs/HardwareNotes.md
>>
>> USB Ports
>>
>> There are multiple USB ports on the HiKey board:
>>
>> One microUSB OTG port on the front edge of the board
>> Two Type A USB 2.0 host ports on the front edge of the board
>> One USB 2.0 host port on the high-speed expansion bus
>>
>> 2、https://github.com/96boards/documentation/tree/master/ConsumerEdition/HiKey/AdditionalDocs
>> Hardware User Guide
>
> Yea, Page 12 in this pdf seems to explain it:
> https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/AdditionalDocs/HiKey_Hardware_User_Manual_Rev0.2.pdf
>
> There is a usb switch which enables the micro-usb-b port if a cable is
> present, or switches to using the hub(which has its own limitations
> wrt multi-speed support) for the usb-a ports.
>
> thanks
> -john
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
prev parent reply other threads:[~2016-12-09 10:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 1:47 John Stultz
2016-12-07 3:52 ` John Youn
2016-12-08 22:42 ` John Stultz
2016-12-08 23:29 ` John Youn
2016-12-09 7:09 ` Chen Yu
2016-12-09 7:32 ` John Stultz
2016-12-09 10:07 ` Chen Yu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb1e045b-1ea4-caaa-79fe-6e4e01514490@huawei.com \
--to=chenyu56@huawei.com \
--cc=John.Youn@synopsys.com \
--cc=amit.pundir@linaro.org \
--cc=dianders@chromium.org \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=guodong.xu@linaro.org \
--cc=john.stultz@linaro.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=wangbinghui@hisilicon.com \
--cc=xuwei5@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®