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.
Let me know if you have any thoughts on this.
thanks
-john
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
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 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.
I suspect this isn't the best solution, but it seems to work
well for me.
Feedback would be greatly appreciated!
Cc: Wei Xu <[email protected]>
Cc: Guodong Xu <[email protected]>
Cc: Amit Pundir <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: John Youn <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Chen Yu <[email protected]>
Cc: Kishon Vijay Abraham I <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Signed-off-by: John Stultz <[email protected]>
---
drivers/usb/dwc2/hcd.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 143da47..6d6802a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3203,7 +3203,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work)
dev_dbg(hsotg->dev, "gotgctl=%0x\n", gotgctl);
dev_dbg(hsotg->dev, "gotgctl.b.conidsts=%d\n",
!!(gotgctl & GOTGCTL_CONID_B));
-
+again:
/* B-Device connector (Device Mode) */
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
@@ -3219,6 +3219,9 @@ static void dwc2_conn_id_status_change(struct work_struct *work)
dwc2_is_host_mode(hsotg) ? "Host" :
"Peripheral");
usleep_range(20000, 40000);
+ gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+ if (!(gotgctl & GOTGCTL_CONID_B))
+ goto again;
if (++count > 250)
break;
}
--
2.7.4
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.
>
> Let me know if you have any thoughts on this.
> thanks
> -john
>
>
> 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.
> 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.
Is the controller supposed to work in both peripheral and host modes?
>
> I suspect this isn't the best solution, but it seems to work
> well for me.
>
The workaround seems fine, but still, this indicates that something
wrong is going on somwhere.
You can add my ack:
Acked-by: John Youn <[email protected]>
Regards,
John
> Feedback would be greatly appreciated!
>
> Cc: Wei Xu <[email protected]>
> Cc: Guodong Xu <[email protected]>
> Cc: Amit Pundir <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: John Youn <[email protected]>
> Cc: Douglas Anderson <[email protected]>
> Cc: Chen Yu <[email protected]>
> Cc: Kishon Vijay Abraham I <[email protected]>
> Cc: Felipe Balbi <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: [email protected]
> Signed-off-by: John Stultz <[email protected]>
> ---
> drivers/usb/dwc2/hcd.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 143da47..6d6802a 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -3203,7 +3203,7 @@ static void dwc2_conn_id_status_change(struct work_struct *work)
> dev_dbg(hsotg->dev, "gotgctl=%0x\n", gotgctl);
> dev_dbg(hsotg->dev, "gotgctl.b.conidsts=%d\n",
> !!(gotgctl & GOTGCTL_CONID_B));
> -
> +again:
> /* B-Device connector (Device Mode) */
> if (gotgctl & GOTGCTL_CONID_B) {
> /* Wait for switch to device mode */
> @@ -3219,6 +3219,9 @@ static void dwc2_conn_id_status_change(struct work_struct *work)
> dwc2_is_host_mode(hsotg) ? "Host" :
> "Peripheral");
> usleep_range(20000, 40000);
> + gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
> + if (!(gotgctl & GOTGCTL_CONID_B))
> + goto again;
> if (++count > 250)
> break;
> }
>
On Tue, Dec 6, 2016 at 7:52 PM, John Youn <[email protected]> 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
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).
Guodong or Chen Yu understand the hardware details a bit better, and
might be able to explain more if you need more information.
> Is the controller supposed to work in both peripheral and host modes?
I certainly hope so!
>> I suspect this isn't the best solution, but it seems to work
>> well for me.
>>
>
> The workaround seems fine, but still, this indicates that something
> wrong is going on somwhere.
Yea. While I'm ok with some of these workarounds, I'd be happier to
figure out what the proper thing should be.
> You can add my ack:
>
> Acked-by: John Youn <[email protected]>
Many thanks!
-john
On 12/8/2016 2:43 PM, John Stultz wrote:
> On Tue, Dec 6, 2016 at 7:52 PM, John Youn <[email protected]> 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
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 <[email protected]> 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.
>
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:
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
3、https://github.com/96boards/documentation/tree/master/ConsumerEdition/HiKey/HardwareDocs
schematics of the Hikey board
thanks
- Chen Yu
On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu <[email protected]> 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 <[email protected]> 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:
> 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
On 2016/12/9 15:32, John Stultz wrote:
> On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu <[email protected]> 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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>