Re: USB CDP (charging downstream port) charging over Chipidea HDRC in host mode
On Tue, May 9, 2017 at 3:39 PM, Jayan John <jayanjoh...@gmail.com> wrote: > On Tue, May 9, 2017 at 1:10 PM, Peter Chen <hzpeterc...@gmail.com> wrote: >> On Tue, May 09, 2017 at 12:51:53PM +0530, Jayan John wrote: >>> On Tue, May 9, 2017 at 6:24 AM, Peter Chen <hzpeterc...@gmail.com> wrote: >>> > On Fri, May 05, 2017 at 10:40:01AM +0530, Jayan John wrote: >>> >> I would like to add CDP (charging downstream port) capability over my >>> >> OTG port in host mode. I am using an iMX6q platform with Chipidea HDRC >>> >> (highspeed dual role controller) with 4.1 kernel. >>> >> >>> >> Looked at a bunch of documents like USB Battery Charging Specification >>> >> and USB Power Delivery specification, it is clear that there is a >>> >> handshake over D+ and D- before enumeration to identify whether a host >>> >> supports CDP or not. It occurs in two steps. A primary handshake to >>> >> detect SDP vs CDP/ DCP where host will respond with D- voltage greater >>> >> than 0.3 V and less than 0.8 V. A secondary handshake to detect CDP vs >>> >> DCP where DCP will be indicated witha response of D+ voltage greater >>> >> than 0.3 V and less than 0.8 V. >>> >> >>> >> I believe the handshake can only be supported by using a CDP emulator >>> >> or a USB charging port controller. But I would like to investigate the >>> >> possibility of achieving this handshake with only driver changes in >>> >> PHY or controller i.e. without any additional hardware chips or >>> >> circuitry. >>> >> >>> >> Does anyone have any viewpoints on whether CDP charging can be >>> >> achieved without any additional hardware changes over Chipidea HDRC in >>> >> host mode? >>> >> >>> > >>> > The imx6 series USB PHY supports USB charger detection, and the internal >>> > tree implements it at: drivers/usb/chipidea/usbmisc_imx.c if you are >>> > using v4.1 release. Due to there is no USB charger framework at >>> > mainline, this part of code has still not upstream. >>> > >>> > -- >>> > >>> > Best Regards, >>> > Peter Chen >>> >>> Thank you Peter. >>> >>> I think you may have misunderstood my question. The imx6 USB charger >>> detection block I believe is used by a upstream facing device to >>> detect what type of down-stream facing charger it is connected to. >>> >>> My requirement is kind of the opposite.. here the imx6 will be used as >>> the down-stream facing charger i.e. attempt to support cdp charging >>> (instead of sdp) after role reveral with imx6 otg in host mode. >>> >>> I know this is feasible with additional hardware such as a CDP >>> emulator or a USB charging port controller. I was hoping you might >>> have an insight on whether this is possible without any additional >>> hardware i.e. only with changes in USB PHY / controller. >>> >> >> No, the PHY doesn't support host charger function. >> > Thank you for confirming that Peter. I needed that information. > > I will keep this topic open for another day or two just in case there > are any other related comments from the others. > I am closing this discussion with the conclusion that it is not possible to support CDP charging in host mode OTG (Chipidea HDRC) on imx6 WITHOUT additional circuitry/ chips like a USB charging port controller. Best regards, Jayan John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB CDP (charging downstream port) charging over Chipidea HDRC in host mode
On Tue, May 9, 2017 at 1:10 PM, Peter Chen <hzpeterc...@gmail.com> wrote: > On Tue, May 09, 2017 at 12:51:53PM +0530, Jayan John wrote: >> On Tue, May 9, 2017 at 6:24 AM, Peter Chen <hzpeterc...@gmail.com> wrote: >> > On Fri, May 05, 2017 at 10:40:01AM +0530, Jayan John wrote: >> >> I would like to add CDP (charging downstream port) capability over my >> >> OTG port in host mode. I am using an iMX6q platform with Chipidea HDRC >> >> (highspeed dual role controller) with 4.1 kernel. >> >> >> >> Looked at a bunch of documents like USB Battery Charging Specification >> >> and USB Power Delivery specification, it is clear that there is a >> >> handshake over D+ and D- before enumeration to identify whether a host >> >> supports CDP or not. It occurs in two steps. A primary handshake to >> >> detect SDP vs CDP/ DCP where host will respond with D- voltage greater >> >> than 0.3 V and less than 0.8 V. A secondary handshake to detect CDP vs >> >> DCP where DCP will be indicated witha response of D+ voltage greater >> >> than 0.3 V and less than 0.8 V. >> >> >> >> I believe the handshake can only be supported by using a CDP emulator >> >> or a USB charging port controller. But I would like to investigate the >> >> possibility of achieving this handshake with only driver changes in >> >> PHY or controller i.e. without any additional hardware chips or >> >> circuitry. >> >> >> >> Does anyone have any viewpoints on whether CDP charging can be >> >> achieved without any additional hardware changes over Chipidea HDRC in >> >> host mode? >> >> >> > >> > The imx6 series USB PHY supports USB charger detection, and the internal >> > tree implements it at: drivers/usb/chipidea/usbmisc_imx.c if you are >> > using v4.1 release. Due to there is no USB charger framework at >> > mainline, this part of code has still not upstream. >> > >> > -- >> > >> > Best Regards, >> > Peter Chen >> >> Thank you Peter. >> >> I think you may have misunderstood my question. The imx6 USB charger >> detection block I believe is used by a upstream facing device to >> detect what type of down-stream facing charger it is connected to. >> >> My requirement is kind of the opposite.. here the imx6 will be used as >> the down-stream facing charger i.e. attempt to support cdp charging >> (instead of sdp) after role reveral with imx6 otg in host mode. >> >> I know this is feasible with additional hardware such as a CDP >> emulator or a USB charging port controller. I was hoping you might >> have an insight on whether this is possible without any additional >> hardware i.e. only with changes in USB PHY / controller. >> > > No, the PHY doesn't support host charger function. > Thank you for confirming that Peter. I needed that information. I will keep this topic open for another day or two just in case there are any other related comments from the others. Best regards, Jayan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB CDP (charging downstream port) charging over Chipidea HDRC in host mode
On Tue, May 9, 2017 at 6:24 AM, Peter Chen <hzpeterc...@gmail.com> wrote: > On Fri, May 05, 2017 at 10:40:01AM +0530, Jayan John wrote: >> I would like to add CDP (charging downstream port) capability over my >> OTG port in host mode. I am using an iMX6q platform with Chipidea HDRC >> (highspeed dual role controller) with 4.1 kernel. >> >> Looked at a bunch of documents like USB Battery Charging Specification >> and USB Power Delivery specification, it is clear that there is a >> handshake over D+ and D- before enumeration to identify whether a host >> supports CDP or not. It occurs in two steps. A primary handshake to >> detect SDP vs CDP/ DCP where host will respond with D- voltage greater >> than 0.3 V and less than 0.8 V. A secondary handshake to detect CDP vs >> DCP where DCP will be indicated witha response of D+ voltage greater >> than 0.3 V and less than 0.8 V. >> >> I believe the handshake can only be supported by using a CDP emulator >> or a USB charging port controller. But I would like to investigate the >> possibility of achieving this handshake with only driver changes in >> PHY or controller i.e. without any additional hardware chips or >> circuitry. >> >> Does anyone have any viewpoints on whether CDP charging can be >> achieved without any additional hardware changes over Chipidea HDRC in >> host mode? >> > > The imx6 series USB PHY supports USB charger detection, and the internal > tree implements it at: drivers/usb/chipidea/usbmisc_imx.c if you are > using v4.1 release. Due to there is no USB charger framework at > mainline, this part of code has still not upstream. > > -- > > Best Regards, > Peter Chen Thank you Peter. I think you may have misunderstood my question. The imx6 USB charger detection block I believe is used by a upstream facing device to detect what type of down-stream facing charger it is connected to. My requirement is kind of the opposite.. here the imx6 will be used as the down-stream facing charger i.e. attempt to support cdp charging (instead of sdp) after role reveral with imx6 otg in host mode. I know this is feasible with additional hardware such as a CDP emulator or a USB charging port controller. I was hoping you might have an insight on whether this is possible without any additional hardware i.e. only with changes in USB PHY / controller. Thanks, Jayan John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB CDP (charging downstream port) charging over Chipidea HDRC in host mode
I would like to add CDP (charging downstream port) capability over my OTG port in host mode. I am using an iMX6q platform with Chipidea HDRC (highspeed dual role controller) with 4.1 kernel. Looked at a bunch of documents like USB Battery Charging Specification and USB Power Delivery specification, it is clear that there is a handshake over D+ and D- before enumeration to identify whether a host supports CDP or not. It occurs in two steps. A primary handshake to detect SDP vs CDP/ DCP where host will respond with D- voltage greater than 0.3 V and less than 0.8 V. A secondary handshake to detect CDP vs DCP where DCP will be indicated witha response of D+ voltage greater than 0.3 V and less than 0.8 V. I believe the handshake can only be supported by using a CDP emulator or a USB charging port controller. But I would like to investigate the possibility of achieving this handshake with only driver changes in PHY or controller i.e. without any additional hardware chips or circuitry. Does anyone have any viewpoints on whether CDP charging can be achieved without any additional hardware changes over Chipidea HDRC in host mode? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iperf UDP packet loss with Chipidea HDRC
On Thu, Oct 8, 2015 at 1:37 PM, Peter Chen <peter.c...@freescale.com> wrote: > On Mon, Oct 05, 2015 at 07:27:23PM +0530, Jayan John wrote: >> We are developing a custom USB device on a iMX6q platform with a Chipidea >> HDRC. The device uses a single NCM interface for communication with another >> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance >> after role reversal with iperf server running on gadget. >> >> Kernel: 3.10.17 using Wandboard config >> >> Test sequence: >> 1. Connect both boards (board A and board B) using OTG cable >> 2. Board A is assigned as A device and board B is assigned as B device >> 3. B device initiates role reversal >> echo -n host > /sys/kernel/debug/ci_hdrc.0/role >> 4. A device switches to gadget mode >> echo -n gadget > /sys/kernel/debug/ci_hdrc.0/role >> 5. Assign IPV6 address on board A (now gadget).. ifconfig usb0 2012::1/64 up >> 6. Assign IPV6 address on board B (now host).. ifconfig usb0 2012::2/64 up >> 7. Run iperf server on board A.. iperf -V -s -u >> 8. Run iperf client on board B.. iperf -u -t 10 -V -c 2012::1 -b 150M >> >> iperf server logs: >> [ 4] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with >> fe80::54e0:86ff:fea6:8987 port 35629 >> [ 4] 0.0-10.0 sec 63.7 MBytes 53.4 Mbits/sec 0.171 ms 61701/107109 (58%) >> [ 4] 0.0-10.0 sec 1 datagrams received out-of-order >> [ 3] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with >> fe80::54e0:86ff:fea6:8987 port 33609 >> [ 3] 0.0-10.0 sec 62.1 MBytes 52.1 Mbits/sec 0.215 ms 62551/106825 (59%) >> [ 3] 0.0-10.0 sec 1 datagrams received out-of-order >> >> Query: >> 1. The UDP packet loss is seen only in the case of iperf server on gadget >> after role reversal. I see there are patches (12) from Peter for performance >> improvements on the newer kernels. Will they help? > > If you only see this problem after role switch, compare the controller > registers may help it. > >> 2. The issue is not seen if UDP socket buffer size/ datagram size on iperf is >> increased i.e. iperf -u -t 10 -l 32k -V -c 2012::1 -b 150M. Is this only >> hiding an issue with Chipidea driver e.g. TXFIFO or burst size? >> 3. Should ncm be tweaked to have different buffer size or NTB handling? > > NCM stack may be updated from v3.10, I just tried (without role switch), it > can get 110Mbps, and about 3% loss rate using your command at v4.3-rc1. > > -- > > Best Regards, > Peter Chen Thanks Peter, I will try that. I saw the packet loss only after role switch. I will close this thread for now, as I intend to make a kernel upgrade before I continue investigation on this issue. I will update the community/ push a patch when I root cause/ fix this. BR, Jayan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iperf UDP packet loss with Chipidea HDRC
On Tue, Oct 6, 2015 at 1:31 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, Oct 06, 2015 at 06:07:50AM +0530, Jayan John wrote: >> On Tue, Oct 6, 2015 at 3:38 AM, Fabio Estevam <feste...@gmail.com> wrote: >> > On Mon, Oct 5, 2015 at 10:57 AM, Jayan John <jayanjoh...@gmail.com> wrote: >> >> We are developing a custom USB device on a iMX6q platform with a Chipidea >> >> HDRC. The device uses a single NCM interface for communication with >> >> another >> >> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance >> >> after role reversal with iperf server running on gadget. >> >> >> >> Kernel: 3.10.17 using Wandboard config >> > >> > Could you test this using kernel 4.2.3 or 4.3-rc4? >> Thanks. Moving to 4.2.3 or 4.3 would be a rather large exercise as a number >> of >> drivers would need changes and significant testing efforts as well. > > > Why is this? Your drivers should all be upstream by now, right? What > else needs to be changed to update to a new kernel version? > > Remember just how old and obsolete 3.10 is, you are on your own if you > use this, you will have to get support from the company that forces you > to use this kernel version, sorry. > > good luck! > > greg k-h Greg, I completely agree with you on moving to a newer kernel. Unfortunately, this is not an option I can pick at this time. I was hoping I might get pointers on the issue as there have been fixes related to performance on chipidea hdrc. I will keep this thread open for a day or two. thanks, jayan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iperf UDP packet loss with Chipidea HDRC
On Tue, Oct 6, 2015 at 3:38 AM, Fabio Estevam <feste...@gmail.com> wrote: > On Mon, Oct 5, 2015 at 10:57 AM, Jayan John <jayanjoh...@gmail.com> wrote: >> We are developing a custom USB device on a iMX6q platform with a Chipidea >> HDRC. The device uses a single NCM interface for communication with another >> OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance >> after role reversal with iperf server running on gadget. >> >> Kernel: 3.10.17 using Wandboard config > > Could you test this using kernel 4.2.3 or 4.3-rc4? Thanks. Moving to 4.2.3 or 4.3 would be a rather large exercise as a number of drivers would need changes and significant testing efforts as well.This maybe planned at a later point if there is a real need identified. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
iperf UDP packet loss with Chipidea HDRC
We are developing a custom USB device on a iMX6q platform with a Chipidea HDRC. The device uses a single NCM interface for communication with another OTG device i.e. Chipidea HDRC again. I see very poor iperf UDP performance after role reversal with iperf server running on gadget. Kernel: 3.10.17 using Wandboard config Test sequence: 1. Connect both boards (board A and board B) using OTG cable 2. Board A is assigned as A device and board B is assigned as B device 3. B device initiates role reversal echo -n host > /sys/kernel/debug/ci_hdrc.0/role 4. A device switches to gadget mode echo -n gadget > /sys/kernel/debug/ci_hdrc.0/role 5. Assign IPV6 address on board A (now gadget).. ifconfig usb0 2012::1/64 up 6. Assign IPV6 address on board B (now host).. ifconfig usb0 2012::2/64 up 7. Run iperf server on board A.. iperf -V -s -u 8. Run iperf client on board B.. iperf -u -t 10 -V -c 2012::1 -b 150M iperf server logs: [ 4] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with fe80::54e0:86ff:fea6:8987 port 35629 [ 4] 0.0-10.0 sec 63.7 MBytes 53.4 Mbits/sec 0.171 ms 61701/107109 (58%) [ 4] 0.0-10.0 sec 1 datagrams received out-of-order [ 3] local fe80::6cc9:b6ff:fec5:be28 port 5001 connected with fe80::54e0:86ff:fea6:8987 port 33609 [ 3] 0.0-10.0 sec 62.1 MBytes 52.1 Mbits/sec 0.215 ms 62551/106825 (59%) [ 3] 0.0-10.0 sec 1 datagrams received out-of-order Query: 1. The UDP packet loss is seen only in the case of iperf server on gadget after role reversal. I see there are patches (12) from Peter for performance improvements on the newer kernels. Will they help? 2. The issue is not seen if UDP socket buffer size/ datagram size on iperf is increased i.e. iperf -u -t 10 -l 32k -V -c 2012::1 -b 150M. Is this only hiding an issue with Chipidea driver e.g. TXFIFO or burst size? 3. Should ncm be tweaked to have different buffer size or NTB handling? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Tue, Jun 30, 2015 at 8:23 AM, Jayan John jayanjoh...@gmail.com wrote: On Tue, Jun 30, 2015 at 6:50 AM, Peter Chen peter.c...@freescale.com wrote: On Tue, Jun 30, 2015 at 12:33 AM, Steve Calfee stevecal...@gmail.com wrote: On Mon, Jun 29, 2015 at 7:16 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Jun 2015, Peter Chen wrote: Just like Steve pointed, it should be a ZLT problem, do you have below patch in your tree, and the host may not send zlt, but you may queue an zero-length request, the f_hid does not set req-zero flag either. commit 953c66469735aed8d2ada639a72b150f01dae605 Author: Abbas Raza abbas_r...@mentor.com Date: Thu Jul 17 19:34:31 2014 +0800 usb: chipidea: udc: Disable auto ZLP generation on ep0 If it still has problem, send me apps if possible (with needed kernel patches). Note that a UDC should _never_ queue an extra zero-length packet for an OUT transfer, no matter how req-zero is set. In other words, req-zero is supposed to affect only IN transfers. Yes UDC gadgets receive packets sent by the host on OUT transfers. If ZLT transfers are needed for the protocol, a short transfer is needed to end an OUT sequence and it must be sent by the sender, in this case the host. The UDC should detect receiving a zero length EP0 OUT and that signals the end of the 64 byte transfer from host to gadget. Regards, Steve Thanks Alan, Peter and Steve for your help and quick response. In fact, today I tested with a similar patch i.e. have QH_IOS and QH_ZLT set for control endpoint in udc.c. The 64 byte transfer appears to work fine. I am not sure whether this is the ideal solution, Testing some more to ensure that there are no regressions. I will send out an update in about a day. The most probably is the QH_ZLT bit, your tree may not the patch I mentioned above. The QH_IOS only affects a setup being received. Peter Sure, I will test this and update closure on this issue. Cheers, Jayan The issue is resolved with the patch: commit 953c66469735aed8d2ada639a72b150f01dae605 Author: Abbas Raza abbas_r...@mentor.com Thanks for all your support. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Tue, Jun 30, 2015 at 6:50 AM, Peter Chen peter.c...@freescale.com wrote: On Tue, Jun 30, 2015 at 12:33 AM, Steve Calfee stevecal...@gmail.com wrote: On Mon, Jun 29, 2015 at 7:16 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Jun 2015, Peter Chen wrote: Just like Steve pointed, it should be a ZLT problem, do you have below patch in your tree, and the host may not send zlt, but you may queue an zero-length request, the f_hid does not set req-zero flag either. commit 953c66469735aed8d2ada639a72b150f01dae605 Author: Abbas Raza abbas_r...@mentor.com Date: Thu Jul 17 19:34:31 2014 +0800 usb: chipidea: udc: Disable auto ZLP generation on ep0 If it still has problem, send me apps if possible (with needed kernel patches). Note that a UDC should _never_ queue an extra zero-length packet for an OUT transfer, no matter how req-zero is set. In other words, req-zero is supposed to affect only IN transfers. Yes UDC gadgets receive packets sent by the host on OUT transfers. If ZLT transfers are needed for the protocol, a short transfer is needed to end an OUT sequence and it must be sent by the sender, in this case the host. The UDC should detect receiving a zero length EP0 OUT and that signals the end of the 64 byte transfer from host to gadget. Regards, Steve Thanks Alan, Peter and Steve for your help and quick response. In fact, today I tested with a similar patch i.e. have QH_IOS and QH_ZLT set for control endpoint in udc.c. The 64 byte transfer appears to work fine. I am not sure whether this is the ideal solution, Testing some more to ensure that there are no regressions. I will send out an update in about a day. The most probably is the QH_ZLT bit, your tree may not the patch I mentioned above. The QH_IOS only affects a setup being received. Peter Sure, I will test this and update closure on this issue. Cheers, Jayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Tue, Jun 30, 2015 at 12:33 AM, Steve Calfee stevecal...@gmail.com wrote: On Mon, Jun 29, 2015 at 7:16 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Jun 2015, Peter Chen wrote: Just like Steve pointed, it should be a ZLT problem, do you have below patch in your tree, and the host may not send zlt, but you may queue an zero-length request, the f_hid does not set req-zero flag either. commit 953c66469735aed8d2ada639a72b150f01dae605 Author: Abbas Raza abbas_r...@mentor.com Date: Thu Jul 17 19:34:31 2014 +0800 usb: chipidea: udc: Disable auto ZLP generation on ep0 If it still has problem, send me apps if possible (with needed kernel patches). Note that a UDC should _never_ queue an extra zero-length packet for an OUT transfer, no matter how req-zero is set. In other words, req-zero is supposed to affect only IN transfers. Yes UDC gadgets receive packets sent by the host on OUT transfers. If ZLT transfers are needed for the protocol, a short transfer is needed to end an OUT sequence and it must be sent by the sender, in this case the host. The UDC should detect receiving a zero length EP0 OUT and that signals the end of the 64 byte transfer from host to gadget. Regards, Steve Thanks Alan, Peter and Steve for your help and quick response. In fact, today I tested with a similar patch i.e. have QH_IOS and QH_ZLT set for control endpoint in udc.c. The 64 byte transfer appears to work fine. I am not sure whether this is the ideal solution, Testing some more to ensure that there are no regressions. I will send out an update in about a day. Regards, Jayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Sun, Jun 28, 2015 at 5:34 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 27 Jun 2015, Jayan John wrote: Thanks. Yes, the wLength value in the Setup packet is equal to 64. Aligned was the wrong term, multiple of 64 would be more appropriate :). The hid gadget driver queues a request for the transfer. Please see below logs.. ... HID: drivers/usb/gadget/f_hid_meu.c:366 - hidg_setup() HID: hid_setup crtl_request : bRequestType:0x21 bRequest:0x9 Value:0x200 What driver is this? I don't see drivers/usb/gadget/f_hid_meu.c in 4.1. I do see drivers/usb/gadget/function/f_hid.c, but in that driver the hidg_setup() routine does this: case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) 8 | HID_REQ_SET_REPORT): VDBG(cdev, set_report | wLength=%d\n, ctrl-wLength); goto stall; break; Thus, it doesn't handle Set Report at all. This is a modified f_hid.c i.e. uses a single Interrupt IN endpoint and control ep0 for in and out transfers. The source is the same as f_hid.c before the integration of the Interrupt OUT patch usb: gadget: hidg: register OUT INT endpoint for SET_REPORT. See https://github.com/torvalds/linux/commit/99c515005857ff7d6cd5c2ba272ccab5dc0ea648 HID: drivers/usb/chipidea/udc.c:1337 - ep_queue() HID: drivers/usb/chipidea/udc.c:794 - _ep_queue() HID: drivers/usb/chipidea/udc.c:467 - _hardware_enqueue() HID: drivers/usb/chipidea/udc.c:395 - add_td_to_list() HID: drivers/usb/chipidea/udc.c:61 - hw_ep_bit() HID: drivers/usb/chipidea/udc.c:209 - hw_ep_prime() .. In the 64 bytes case, the following logs are missing (indicating transfer complete interrupt): ... HID: drivers/usb/chipidea/core.c:368 - ci_irq() HID: drivers/usb/chipidea/udc.c:1786 - udc_irq() HID: drivers/usb/chipidea/udc.c:282 - hw_read_intr_status() HID: drivers/usb/chipidea/udc.c:271 - hw_read_intr_enable() HID: drivers/usb/chipidea/udc.c:309 - hw_test_and_clear_intr_active() HID: drivers/usb/chipidea/udc.c:992 - isr_tr_complete_handler() HID: drivers/usb/chipidea/udc.c:295 - hw_test_and_clear_complete() HID: drivers/usb/chipidea/udc.c:68 - ep_to_bit() HID: drivers/usb/chipidea/udc.c:957 - isr_tr_complete_low() HID: drivers/usb/chipidea/udc.c:583 - _hardware_dequeue() HID: drivers/usb/gadget/f_hid_meu.c:322 - hidg_set_report_complete() ... Assuming the ep_queue() was for a 64-byte transfer, this indicates there is a bug in the chipidea UDC driver or hardware. Alan Stern If this is a bug in the chipidea UDC driver or hardware, how can I address this i.e. register an errata? I am hoping this is something Peter might be able to help with. Best regards, Jayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Fri, Jun 26, 2015 at 8:44 PM, David Laight david.lai...@aculab.com wrote: From: Steve Calfee Sent: 26 June 2015 15:59 On the host (Wandboard iMX6q) the test app opens /dev/hidraw0 and write 64 bytes with report ID (1). The HID device has no Interrupt OUT ep, therefore uses control endpoint ep0 for the 64 bytes transfer to gadget (Wandboard iMX6q) using set_report. The setup phase is OK and the 64 bytes is written to gadget. However the chipidea interrupt (ci_irq()) and resulting udc interrupt (udc_irq()) is invoked. This indicates that the 64 bytes transaction is not completed over ep0 from host to gadget. **this issue is reproducible for all data transfers that aligns on 64 bytes** ~jayan Hi Jayan, This sounds like a Zero Length Transfer issue. This applies to any endpoint including EP0. A ZLT is needed to end any transfer IFF the length is not already known by the protocol. So if the hid URB requests say 1024 bytes and the gadget only has 64, it must first send the 64 byte maxpacket and then send a zero length packet. This way the host knows the transfer is complete. Is this using the xhci driver? The ZLP sending code used to be broken. A couple of patches have been submitted but I don't remember one being applied. David Thanks for the pointers. This is not using the xhci driver. - This is a ep0 OUT transfer. Does the host need to add a ZLP for 64 byte aligned data transfer? - Is it not expected for the completion interrupt be raised on receiving the 64 bytes of data, irrespective of whether or not a ZLP has been sent. ~Jayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
On Sat, Jun 27, 2015 at 2:21 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 27 Jun 2015, Jayan John wrote: On Fri, Jun 26, 2015 at 8:44 PM, David Laight david.lai...@aculab.com wrote: From: Steve Calfee Sent: 26 June 2015 15:59 On the host (Wandboard iMX6q) the test app opens /dev/hidraw0 and write 64 bytes with report ID (1). The HID device has no Interrupt OUT ep, therefore uses control endpoint ep0 for the 64 bytes transfer to gadget (Wandboard iMX6q) using set_report. The setup phase is OK and the 64 bytes is written to gadget. However the chipidea interrupt (ci_irq()) and resulting udc interrupt (udc_irq()) is invoked. This indicates that the 64 bytes transaction is not completed over ep0 from host to gadget. **this issue is reproducible for all data transfers that aligns on 64 bytes** ~jayan Hi Jayan, This sounds like a Zero Length Transfer issue. This applies to any endpoint including EP0. A ZLT is needed to end any transfer IFF the length is not already known by the protocol. So if the hid URB requests say 1024 bytes and the gadget only has 64, it must first send the 64 byte maxpacket and then send a zero length packet. This way the host knows the transfer is complete. Is this using the xhci driver? The ZLP sending code used to be broken. A couple of patches have been submitted but I don't remember one being applied. David Thanks for the pointers. This is not using the xhci driver. - This is a ep0 OUT transfer. Does the host need to add a ZLP for 64 byte aligned data transfer? I'm not sure what you mean here by aligned, but in general the answer is No. - Is it not expected for the completion interrupt be raised on receiving the 64 bytes of data, irrespective of whether or not a ZLP has been sent. It is expected. Did you check the wLength value in the Setup packet? Is it equal to 64? Does the hid gadget driver then queue a request for a 64-byte OUT transfer on ep0? If it does then there's a bug in the UDC driver or hardware. Alan Stern Thanks. Yes, the wLength value in the Setup packet is equal to 64. Aligned was the wrong term, multiple of 64 would be more appropriate :). The hid gadget driver queues a request for the transfer. Please see below logs.. ... HID: drivers/usb/gadget/f_hid_meu.c:366 - hidg_setup() HID: hid_setup crtl_request : bRequestType:0x21 bRequest:0x9 Value:0x200 HID: drivers/usb/chipidea/udc.c:1337 - ep_queue() HID: drivers/usb/chipidea/udc.c:794 - _ep_queue() HID: drivers/usb/chipidea/udc.c:467 - _hardware_enqueue() HID: drivers/usb/chipidea/udc.c:395 - add_td_to_list() HID: drivers/usb/chipidea/udc.c:61 - hw_ep_bit() HID: drivers/usb/chipidea/udc.c:209 - hw_ep_prime() .. In the 64 bytes case, the following logs are missing (indicating transfer complete interrupt): ... HID: drivers/usb/chipidea/core.c:368 - ci_irq() HID: drivers/usb/chipidea/udc.c:1786 - udc_irq() HID: drivers/usb/chipidea/udc.c:282 - hw_read_intr_status() HID: drivers/usb/chipidea/udc.c:271 - hw_read_intr_enable() HID: drivers/usb/chipidea/udc.c:309 - hw_test_and_clear_intr_active() HID: drivers/usb/chipidea/udc.c:992 - isr_tr_complete_handler() HID: drivers/usb/chipidea/udc.c:295 - hw_test_and_clear_complete() HID: drivers/usb/chipidea/udc.c:68 - ep_to_bit() HID: drivers/usb/chipidea/udc.c:957 - isr_tr_complete_low() HID: drivers/usb/chipidea/udc.c:583 - _hardware_dequeue() HID: drivers/usb/gadget/f_hid_meu.c:322 - hidg_set_report_complete() ... ~Jayan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
Thanks Alex. I appreciate you introducing me to Peter. Any help is appreciated. On the host (Wandboard iMX6q) the test app opens /dev/hidraw0 and write 64 bytes with report ID (1). The HID device has no Interrupt OUT ep, therefore uses control endpoint ep0 for the 64 bytes transfer to gadget (Wandboard iMX6q) using set_report. The setup phase is OK and the 64 bytes is written to gadget. However the chipidea interrupt (ci_irq()) and resulting udc interrupt (udc_irq()) is invoked. This indicates that the 64 bytes transaction is not completed over ep0 from host to gadget. **this issue is reproducible for all data transfers that aligns on 64 bytes** ~jayan On Fri, Jun 26, 2015 at 5:10 PM, Alexander Shishkin alexander.shish...@linux.intel.com wrote: Jayan John jayanjoh...@gmail.com writes: I am developing a custom USB device on a iMX6q platform (Wandboard) Chipidea HDRC (highspeed dual role controller). The HID interface consists of a single Interrupt IN ep and ep0. It is required to send HID reports from Host to Gadget over ep0 (with set_report cmd on hidraw interface) in OUT direction. The size of each HID report is 64 bytes. The Chipidea HDRC is unable to receive/ process the 64 bytes of data over ep0 (OUT). The setup stage is fine. No UDC interrupt is raised by controller to indicate completion of transaction. The same data transfer works fine for 64 bytes (63, 63 etc) and 64 bytes (65, 66 etc) where the transfers are split as 64+n. Analyzer logs attached. 1. Is there an issue with Chipidea HDRC receiving wMaxPacketSize (i.e. 64 byte) aligned data transfers on ep0 in OUT direction? 2. Anything that needs to be configured/ added in descriptor or source to have completion interrupt hit on 64 bytes data transfer on ep0 OUT? Let's add Peter to CC as he's the maintainer for Chipidea now. How do you generate this traffic? Are you using the zero gadget or some other kind of test? Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
I am developing a custom USB device on a iMX6q platform (Wandboard) Chipidea HDRC (highspeed dual role controller). The HID interface consists of a single Interrupt IN ep and ep0. It is required to send HID reports from Host to Gadget over ep0 (with set_report cmd on hidraw interface) in OUT direction. The size of each HID report is 64 bytes. The Chipidea HDRC is unable to receive/ process the 64 bytes of data over ep0 (OUT). The setup stage is fine. No UDC interrupt is raised by controller to indicate completion of transaction. The same data transfer works fine for 64 bytes (63, 63 etc) and 64 bytes (65, 66 etc) where the transfers are split as 64+n. Analyzer logs attached. 1. Is there an issue with Chipidea HDRC receiving wMaxPacketSize (i.e. 64 byte) aligned data transfers on ep0 in OUT direction? 2. Anything that needs to be configured/ added in descriptor or source to have completion interrupt hit on 64 bytes data transfer on ep0 OUT? THank you!! File C:\Program Files (x86)\Lecroy\USBTracer\data.usb. From Packet #33198 to Packet #38355. Packet# ___|___ Packet(33198) Dir(--) H(S) SETUP(0xB4) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(8) ___| Time Stamp(1.3535 6645) ___|___ Packet(33199) Dir(--) H(S) DATA0(0xC3) Data(8 bytes) CRC16(0xB504) Pkt Len(16) ___| Time Stamp(1.3535 6669) ___|___ Packet(33200) Dir(--) H(S) ACK(0x4B) Pkt Len(6) Time Stamp(1.3535 6705) ___|___ Packet(38351) Dir(--) H(S) PING(0x2D) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(10) ___| Time Stamp(1.3663 3101) ___|___ Packet(38352) Dir(--) H(S) ACK(0x4B) Pkt Len(8) Time Stamp(1.3663 3129) ___|___ Packet(38353) Dir(--) H(S) OUT(0x87) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(10) ___| Time Stamp(1.3663 3275) ___|___ Packet(38354) Dir(--) H(S) DATA1(0xD2) Data(64 bytes) CRC16(0x9A52) Pkt Len(74) ___| Time Stamp(1.3663 3299) ___|___ Packet(38355) Dir(--) H(S) NYET(0x69) Pkt Len(8) Time Stamp(1.3663 3391) ___|___ File C:\Program Files (x86)\Lecroy\USBTracer\data.usb. From Packet #29969 to Packet #87486. Packet# ___|___ Packet(29969) Dir(--) H(S) SETUP(0xB4) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(8) ___| Time Stamp(1.0957 5739) ___|___ Packet(29970) Dir(--) H(S) DATA0(0xC3) Data(8 bytes) CRC16(0x3101) Pkt Len(16) ___| Time Stamp(1.0957 5763) ___|___ Packet(29971) Dir(--) H(S) ACK(0x4B) Pkt Len(8) Time Stamp(1.0957 5797) ___|___ Packet(35124) Dir(--) H(S) PING(0x2D) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(8) ___| Time Stamp(1.1085 2569) ___|___ Packet(35125) Dir(--) H(S) ACK(0x4B) Pkt Len(6) Time Stamp(1.1085 2597) ___|___ Packet(35126) Dir(--) H(S) OUT(0x87) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(8) ___| Time Stamp(1.1085 2729) ___|___ Packet(35127) Dir(--) H(S) DATA1(0xD2) Data(62 bytes) CRC16(0xADB3) Pkt Len(70) ___| Time Stamp(1.1085 2753) ___|___ Packet(35128) Dir(--) H(S) NYET(0x69) Pkt Len(6) Time Stamp(1.1085 2843) ___|___ Packet(87484) Dir(--) H(S) IN(0x96) ADDR(2) ENDP(0) CRC5(0x15) Pkt Len(10) ___| Time Stamp(1.2386 3931) ___|___ Packet(87485) Dir(--) H(S) DATA1(0xD2) Data(0 bytes) CRC16(0x) Pkt Len(10) ___| Time Stamp(1.2386 3959) ___|___ Packet(87486) Dir(--) H(S) ACK(0x4B) Pkt Len(8) Time Stamp(1.2386 3987) ___|___ File C:\Program Files (x86)\Lecroy\USBTracer\data.usb. From Packet #37091 to Packet #87527. Packet# ___|___ Packet(37091)
Re: 64 byte EP0 OUT data transfer issue on Chipidea highspeed dual role controller
cc Alexander Thanks On Thu, Jun 25, 2015 at 7:41 PM, Jayan John jayanjoh...@gmail.com wrote: I am developing a custom USB device on a iMX6q platform (Wandboard) Chipidea HDRC (highspeed dual role controller). The HID interface consists of a single Interrupt IN ep and ep0. It is required to send HID reports from Host to Gadget over ep0 (with set_report cmd on hidraw interface) in OUT direction. The size of each HID report is 64 bytes. The Chipidea HDRC is unable to receive/ process the 64 bytes of data over ep0 (OUT). The setup stage is fine. No UDC interrupt is raised by controller to indicate completion of transaction. The same data transfer works fine for 64 bytes (63, 63 etc) and 64 bytes (65, 66 etc) where the transfers are split as 64+n. Analyzer logs attached. 1. Is there an issue with Chipidea HDRC receiving wMaxPacketSize (i.e. 64 byte) aligned data transfers on ep0 in OUT direction? 2. Anything that needs to be configured/ added in descriptor or source to have completion interrupt hit on 64 bytes data transfer on ep0 OUT? THank you!! -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
