On Sat, Jun 27, 2015 at 2:21 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 27 Jun 2015, Jayan John wrote: > >> On Fri, Jun 26, 2015 at 8:44 PM, David Laight <David.Laight@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
