On Fri, Mar 08, 2013 at 05:38:53PM +0800, Peter Chen wrote:
> 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.
>
> diff --git a/drivers/usb/gadget/fsl_udc_core.c
> b/drivers/usb/gadget/fsl_udc_core.c
> index 04d5fef..a75c884 100644
> --- a/drivers/usb/gadget/fsl_udc_core.c
> +++ b/drivers/usb/gadget/fsl_udc_core.c
> @@ -1335,10 +1335,14 @@ static void udc_reset_ep_queue(struct fsl_udc *udc,
> u8 pipe)
> */
> static void ch9setaddress(struct fsl_udc *udc, u16 value, u16 index, u16
> length)
> {
> - /* Save the new address to device struct */
> udc->device_address = (u8) value;
> + /* Set the new address */
> + fsl_writel(((u32)value << USB_DEVICE_ADDRESS_BIT_POS)|
> + (1 << USB_DEVICE_ADDRESS_BIT_POS),
do you mean:
(u32) ((value << USB_DEVICE_ADDRESS_BIT_POS) |
(1 << USB_DEVICE_ADDRESS_BIT_POS))
??
Also, why do you need the extra (1 << USB_DEVICE_ADDRESS_BIT_POS) ?
You'd be making all addresses odd, no ?
--
balbi
signature.asc
Description: Digital signature
