usbh/ehci: Increase timeout for enumeration
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
The current logic reads the port status just once after usb_hub_power_on and expects the portstatus and portchange to report the connection status immediately and correctly.
Few pen drives are not able to report both of them immediately ie. those pens report the connection change but not the connected state after the first read. This opportunity once lost is gone for ever because the u-boot, unlike linux or any other OS, works in polling mode.
This patch modifies the logic to read the port status continuously until the portstatus and portchange both report a connection change as well as a connected state or no connection change and no connection. This logic is placed in a timeout of 10 sec. At the end of it, the pen drive would have either reported a ONE or a ZERO in bit 1 of portstatus as well as portchange.
It enhances the set of pen drives which can eventually be detected by u-boot
---
Hello Marek, Igor,
I found another way to handle it. Please let me know if it is OK from the USB stack poit of view. The fact is that a few pens do not report a connected status in portstatus while they report a connection change in portchange after a usb_hub_power_on.
In this patch, I have tried to compare the connection bit from portstatus and portchange for a timeout of 10 seconds. The situation is asumed to be stable once both of them report the same. This seems to have increased the set of pens supported by u-boot without any apparent side effect
Please let me know if this is OK from your side
Regards
Vipin
common/usb_hub.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)
common/usb_hub.c +20 -5
@@ -396,14 +396,29 @@ static int usb_hub_configure(struct usb_device *dev)for (i =0 ; i < dev->maxchild; i++) { ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);unsigned short portstatus, portchange; +int ret; +ulong start =get_timer (0 ); + +do { + ret =usb_get_port_status (dev, i +1 , portsts); +if (ret <0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange &USB_PORT_STAT_C_CONNECTION ) == + (portstatus &USB_PORT_STAT_CONNECTION )) +break ; + +mdelay (100 ); + }while (get_timer (start) <CONFIG_SYS_HZ *10 ); -if (usb_get_port_status (dev, i +1 , portsts) <0 ) { -USB_HUB_PRINTF ("get_port_status failed\n" ); +if (ret <0 )continue ; - } - portstatus =le16_to_cpu (portsts->wPortStatus); - portchange =le16_to_cpu (portsts->wPortChange);USB_HUB_PRINTF ("Port %d Status %X Change %X\n" , i +1 , portstatus, portchange);
Signature · 1 line
1.8.0
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Quoted 26 lines · Vipin Kumar
The current logic reads the port status just once after
usb_hub_power_onand expects the portstatus and portchange to report the connection status immediately and correctly.Few pen drives are not able to report both of them immediately ie. those pens report the connection change but not the connected state after the first read. This opportunity once lost is gone for ever because the u-boot, unlike linux or any other OS, works in polling mode.
This patch modifies the logic to read the port status continuously until the portstatus and portchange both report a connection change as well as a connected state or no connection change and no connection. This logic is placed in a timeout of 10 sec. At the end of it, the pen drive would have either reported a ONE or a ZERO in bit 1 of portstatus as well as portchange.
It enhances the set of pen drives which can eventually be detected by u-boot
Signed-off-by Vipin Kumar <[email protected]>---
Hello Marek, Igor,I found another way to handle it. Please let me know if it is OK from the USB stack poit of view. The fact is that a few pens do not report a connected status in portstatus while they report a connection change in portchange after a
usb_hub_power_on.
Quoted 6 lines
In this patch, I have tried to compare the connection bit from portstatus and portchange for a timeout of 10 seconds. The situation is asumed to be stable once both of them report the same. This seems to have increased the set of pens supported by u-boot without any apparent side effect
Please let me know if this is OK from your side
Basically, this one looks fine, although I have two minor concerns below.
Quoted 20 lines
Regards
Vipincommon/usb_hub.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)common/usb_hub.c +5
-0@@ -396,14 +396,29 @@ static int usb_hub_configure(struct usb_device *dev)for (i =0 ; i < dev->maxchild; i++) { ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);unsigned short portstatus, portchange; +int ret; +ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev) · line 413
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret <0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange &USB_PORT_STAT_C_CONNECTION ) == + (portstatus &USB_PORT_STAT_CONNECTION ))
I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev) · line 417
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start) <CONFIG_SYS_HZ *10 );
Is there any justification for the CONFIG_SYS_HZ * 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Quoted 12 lines
common/usb_hub.c +1
-5-if (usb_get_port_status (dev, i +1 , portsts) <0 ) { -USB_HUB_PRINTF ("get_port_status failed\n" ); +if (ret <0 )continue ; - } - portstatus =le16_to_cpu (portsts->wPortStatus); - portchange =le16_to_cpu (portsts->wPortChange);USB_HUB_PRINTF ("Port %d Status %X Change %X\n" , i +1 , portstatus, portchange);
Signature · 2 lines
Regards, Igor.
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Quoted 62 lines · Igor Grinberg
Quoted 26 lines · Vipin Kumar
The current logic reads the port status just once after
usb_hub_power_onand expects the portstatus and portchange to report the connection status immediately and correctly.Few pen drives are not able to report both of them immediately ie. those pens report the connection change but not the connected state after the first read. This opportunity once lost is gone for ever because the u-boot, unlike linux or any other OS, works in polling mode.
This patch modifies the logic to read the port status continuously until the portstatus and portchange both report a connection change as well as a connected state or no connection change and no connection. This logic is placed in a timeout of 10 sec. At the end of it, the pen drive would have either reported a ONE or a ZERO in bit 1 of portstatus as well as portchange.
It enhances the set of pen drives which can eventually be detected by u-boot
Signed-off-by Vipin Kumar <[email protected]>---
Hello Marek, Igor,I found another way to handle it. Please let me know if it is OK from the USB stack poit of view. The fact is that a few pens do not report a connected status in portstatus while they report a connection change in portchange after a
usb_hub_power_on.Quoted 6 lines
In this patch, I have tried to compare the connection bit from portstatus and portchange for a timeout of 10 seconds. The situation is asumed to be stable once both of them report the same. This seems to have increased the set of pens supported by u-boot without any apparent side effect
Please let me know if this is OK from your side
Basically, this one looks fine, although I have two minor concerns below.
Quoted 26 lines
Regards
Vipincommon/usb_hub.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)common/usb_hub.c +11
-0@@ -396,14 +396,29 @@ static int usb_hub_configure(struct usb_device *dev)for (i =0 ; i < dev->maxchild; i++) { ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);unsigned short portstatus, portchange; +int ret; +ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts); + if (ret < 0) { + USB_HUB_PRINTF("get_port_status failed\n"); + break; + } + + portstatus = le16_to_cpu(portsts->wPortStatus);
Quoted 8 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev) · line 413
Quoted 4 lines
common/usb_hub.c +4
-0+ portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange &USB_PORT_STAT_C_CONNECTION ) == + (portstatus &USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
Never mind, my mistake, USB_PORT_STAT_C_CONNECTION and USB_PORT_STAT_CONNECTION are the same bit in the register.
Quoted 9 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev) · line 417
Quoted 5 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start) <CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Once you address this one, feel free to add:
Quoted 14 lines
Quoted 13 lines
common/usb_hub.c +1
-5-if (usb_get_port_status (dev, i +1 , portsts) <0 ) { -USB_HUB_PRINTF ("get_port_status failed\n" ); +if (ret <0 )continue ; - } - portstatus =le16_to_cpu (portsts->wPortStatus); - portchange =le16_to_cpu (portsts->wPortChange);USB_HUB_PRINTF ("Port %d Status %X Change %X\n" , i +1 , portstatus, portchange);
Signature · 2 lines
Regards, Igor.
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Quoted 87 lines · Igor Grinberg
Quoted 62 lines · Igor Grinberg
Quoted 26 lines · Vipin Kumar
The current logic reads the port status just once after
usb_hub_power_onand expects the portstatus and portchange to report the connection status immediately and correctly.Few pen drives are not able to report both of them immediately ie. those pens report the connection change but not the connected state after the first read. This opportunity once lost is gone for ever because the u-boot, unlike linux or any other OS, works in polling mode.
This patch modifies the logic to read the port status continuously until the portstatus and portchange both report a connection change as well as a connected state or no connection change and no connection. This logic is placed in a timeout of 10 sec. At the end of it, the pen drive would have either reported a ONE or a ZERO in bit 1 of portstatus as well as portchange.
It enhances the set of pen drives which can eventually be detected by u-boot
Signed-off-by Vipin Kumar<[email protected]>---
Hello Marek, Igor,I found another way to handle it. Please let me know if it is OK from the USB stack poit of view. The fact is that a few pens do not report a connected status in portstatus while they report a connection change in portchange after a
usb_hub_power_on.Quoted 6 lines
In this patch, I have tried to compare the connection bit from portstatus and portchange for a timeout of 10 seconds. The situation is asumed to be stable once both of them report the same. This seems to have increased the set of pens supported by u-boot without any apparent side effect
Please let me know if this is OK from your side
Basically, this one looks fine, although I have two minor concerns below.
Quoted 26 lines
Regards
Vipincommon/usb_hub.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)common/usb_hub.c +11
-0@@ -396,14 +396,29 @@ static int usb_hub_configure(struct usb_device *dev)for (i =0 ; i< dev->maxchild; i++) { ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);unsigned short portstatus, portchange; +int ret; +ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts); + if (ret< 0) { + USB_HUB_PRINTF("get_port_status failed\n"); + break; + } + + portstatus = le16_to_cpu(portsts->wPortStatus);Quoted 8 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 4 lines
common/usb_hub.c +4
-0+ portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
Never mind, my mistake,
USB_PORT_STAT_C_CONNECTIONandUSB_PORT_STAT_CONNECTIONare the same bit in the register.Quoted 9 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 5 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Quoted 3 lines
Once you address this one, feel free to add:
Acked-by Igor Grinberg<[email protected]>
Thanks Igor, let me wait for Marek's comments also
Quoted 15 lines
Quoted 14 lines
Quoted 13 lines
common/usb_hub.c +1
-5-if (usb_get_port_status (dev, i +1 , portsts)<0 ) { -USB_HUB_PRINTF ("get_port_status failed\n" ); +if (ret<0 )continue ; - } - portstatus =le16_to_cpu (portsts->wPortStatus); - portchange =le16_to_cpu (portsts->wPortChange);USB_HUB_PRINTF ("Port %d Status %X Change %X\n" , i +1 , portstatus, portchange);
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
In reply to Igor GrinbergQuoted 20 lines
Quoted 5 lines
common/usb_hub.c +4
-0+ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret<0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
Quoted 9 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Not really. Just a practical test.
Marek, can I have comments from you as well
Thanks
Vipin
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Dear Vipin Kumar,
Quoted 28 lines
Quoted 19 lines
Quoted 4 lines
common/usb_hub.c +4
-0+ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret<0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
Quoted 8 lines
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Quoted 3 lines
Not really. Just a practical test.
Marek, can I have comments from you as well
Sorry, I'm really busy these days. I went through it and I see Igor still has some comment. Just fix that one and I'm good.
Best regards,
Marek Vasut
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Quoted 30 lines · Marek Vasut
Dear Vipin Kumar,
Quoted 28 lines
Quoted 27 lines
Quoted 4 lines
common/usb_hub.c +4
-0+ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret<0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Quoted 7 lines
Quoted 3 lines
Not really. Just a practical test.
Marek, can I have comments from you as wellSorry, I'm really busy these days. I went through it and I see Igor still has some comment. Just fix that one and I'm good.
Thanks marek, I would send a v3 soon
Quoted 4 lines
Best regards,
Marek Vasut
.
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
In reply to Vipin KumarQuoted 25 lines · Vipin Kumar
Quoted 25 lines
Quoted 5 lines
common/usb_hub.c +4
-0+ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret<0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );
Quoted 6 lines
Quoted 4 lines
Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.Not really. Just a practical test.
Ok. good. can we please have a comment saying that this value is based on observations? Thanks!
You can add my ack along with the comment in v3.
Thanks for the patch!
Signature · 2 lines
Regards, Igor.
PATCH v2 1/1 usbh/ehci: Increase timeout for enumeration
Quoted 31 lines · Igor Grinberg
Quoted 30 lines · Vipin Kumar
Quoted 29 lines
Quoted 5 lines
common/usb_hub.c +4
-0+ulong start =get_timer (0 ); + + do { + ret = usb_get_port_status(dev, i + 1, portsts);common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 10 lines
common/usb_hub.c +10
-0+if (ret<0 ) { +USB_HUB_PRINTF ("get_port_status failed\n" ); +break ; + } + + portstatus =le16_to_cpu (portsts->wPortStatus); + portchange =le16_to_cpu (portsts->wPortChange); + +if ((portchange&USB_PORT_STAT_C_CONNECTION ) == + (portstatus&USB_PORT_STAT_CONNECTION ))I don't know if there is any corner case when the above check will always fail and so it will always wait a maximal delay time. Are those registers that identical, or can there be differences?
common/usb_hub.c static int usb_hub_configure(struct usb_device *dev)
Quoted 4 lines
common/usb_hub.c +4
-0+break ; + +mdelay (100 ); + }while (get_timer (start)<CONFIG_SYS_HZ *10 );Is there any justification for the
CONFIG_SYS_HZ* 10? I would be much more fine with this patch if there were any (even just test based * 2) reason for that number.
Quoted 8 lines
Quoted 1 line
Not really. Just a practical test.
Ok. good. can we please have a comment saying that this value is based on observations? Thanks!
You can add my ack along with the comment in v3.Thanks for the patch!
Thanks Igor
Marek, I am waiting for your comments now, if any
-Vipin