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 <swar...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
