[U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/01/2014 03:31 PM, Stephen Warren wrote:
> On 07/01/2014 03:25 PM, J?rg Krause wrote:
>>
>> On 07/01/2014 07:41 PM, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> This is a series of small fixes and cleanups either required by those
>>> fixes, or enabled now that the fixes are made.
>>>
>>> I hope that either patch 1 or 4 might fix the issues J?rg is seeing, but
>>> I'm not sure that will happen. The other patches shouldn't change any
>>> behaviour.
>>>
>>> Stephen Warren (6):
>>>    usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
>>>    usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
>>>    usb: ci_udc: lift ilist size calculations to global scope
>>>    usb: ci_udc: fix items array size/stride calculation
>>>    usb: ci_udc: remove controller.items array
>>>    usb: ci_udc: don't memalign() struct ci_req allocations
>>>
>>>   drivers/usb/gadget/ci_udc.c | 62
>>> ++++++++++++++++++++++-----------------------
>>>   drivers/usb/gadget/ci_udc.h |  1 -
>>>   2 files changed, 30 insertions(+), 33 deletions(-)
>>>
>>
>> Good news! The last patch usb: ci_udc: don't memalign() struct ci_req
>> allocations removes the timeout error after starting the fourth run of
>> tftp in a row.
>>
>> This is how I tested. Checked out u-boot-usb/master branch. Applied the
>> necessary patches to support our board. Applied the patches step after
>> step. After applying a patch reset the board and run tftp from console
>> until an error occured, which is always the fourth run.
> 
> How many times did you boot the board for each patch? I'm more
> interested in how often the first TFTP after a reset/power-on passes or
> fails, so it would be nice to boot the board many times to see what
> happens to the first TFTP invocation too. This is especially true since
> you'd indicated before that the problem was (at least sometimes) visible
> on the first TFTP invocation, and this "it fails the fourth time"
> symptom is something completely new.
> 
>> This is the case
>> until applying patch usb: ci_udc: don't memalign() struct ci_req
>> allocations, which throws no timeout error within running tftp about 60
>> times in a row.
> 
> That's quite odd. That patch definitely should not affect behaviour (and
> indeed I only sent it as an after-thought). If it does, then the only
> explanation I can think of is that the malloc heap's alignment changed,
> which just happens to hide the bug you're seeing. No doubt, there is
> still some lingering cache-flushing bug or similar...
> 
> BTW, did you fix the U-Boot header files in your board support patches,
> so that everything correctly knows that the cache line size is 32? I
> think it's mandatory to fix that issue before testing the USB code.

Can you please try one more thing:

Go back to u-boot-usb/master plus just your board support patches. Apply
the following and test that:

> diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
> index a6433e8d2d8d..13be1b73d3d1 100644
> --- a/drivers/usb/gadget/ci_udc.c
> +++ b/drivers/usb/gadget/ci_udc.c
> @@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags)
>         ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req));
>         if (!ci_req)
>                 return NULL;
> +       memset(ci_req, 0, sizeof(*ci_req));
>  
>         INIT_LIST_HEAD(&ci_req->queue);
> -       ci_req->b_buf = 0;
>  
>         if (num == 0)
>                 controller.ep0_req = ci_req;

Thanks.