Peter Chen <peter.chen@xxxxxxxxxxxxx> writes: > On Thu, Mar 07, 2013 at 09:58:52AM +0100, Peter Bestler wrote: >> Hi, >> >> We try to get our device (based on p2020rdb) usb 2.0 compliant. We ran the usb30cv test suite (version 1.0.1.2, chapter 9 tests for usb 2.0 devices) on win7 with g_zero and g_serial. We access the device via an usb 3.0 hcd from intel. Our device runs the 3.2.35-rt52 kernel. I spotted the following problem with ch9setaddress in fsl_udc_core.c. >> >> All tests passed on single execution. At running it in batch mode the first test after switching from default to adressed state failed. The subsequent tests passed. It doesn't depend on the selected tests, only on the switch over from default to adressed. It fails with our custom gadgetfs driver too. Another device with Intel PXA25x and the same setup passes all tests. >> >> With the total phase usbsniffer i spotted the following behavior: >> The test issues a setAddress and receives an ACK, 125 us afterwards the host issues a getDescriptor (setuptx) request, which fails at setuptx. The USB sniffer reports invalid PID sequence. >> >> For debugging purpose I delayed the dma_map_single in ep0_prime_status (which does the ACK, right?) by 2 milliseconds. And all tests are passing in batch mode. It's quite the same sequence on the bus, but between setAdress and its ACK is a delay of 3 ms. >> >> I think delaying the ACK in set request isn't the way to go. I think we set the address too early; we have to wait until the status phase of the set address has finished. My understanding is that the device has to respond to address 0 until the complete status phase of setAddress is passed (is this correct). >> >> Has anybody ran the usb30cv on fsl_udc recently? >> >> After applying the patch f79a60b8785 none of the tests run anymore. Did I miss anything here? How can we fix this issue? >> >> Best regards >> >> Peter >> >> --- Patch for debugging --- >> diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c >> index 55abfb6..fdbfd25 100644 >> --- a/drivers/usb/gadget/fsl_udc_core.c >> +++ b/drivers/usb/gadget/fsl_udc_core.c >> @@ -1285,6 +1285,7 @@ static int ep0_prime_status(struct fsl_udc *udc, int direction) >> req->req.complete = NULL; >> req->dtd_count = 0; >> >> + udelay(2000); >> req->req.dma = dma_map_single(ep->udc->gadget.dev.parent, >> req->req.buf, req->req.length, >> ep_is_in(ep) ? DMA_TO_DEVICE : DMA_FROM_DEVICE); >> >> >> >> > > Please check your datasheet if your controller has USBADRA bit > at DEVICEADDR, if it exists, it means your controller supports > advance store device address function. Please have a try for > below change, if it fixes your problem, please give a tested-by, > then, I can make change for chipidea and fsl-core driver. Ah, now I see where the confusion comes from. No, chipidea driver already gets it right, no changes needed. Even better, we do it without the USBADRA crutch, since not all chipidea cores support it. Maybe this is our reminder that it's about time we started moving all chipidea users to use the chipidea driver. Regards, -- Alex -- 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
