Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state is wrong

From: Chen Yu
Date: Fri Dec 09 2016 - 05:08:06 EST




On 2016/12/9 15:32, John Stultz wrote:
> On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu <chenyu56@xxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>