From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
Date: Tue, 01 Jul 2014 15:31:48 -0600 [thread overview]
Message-ID: <53B328C4.60300@wwwdotorg.org> (raw)
In-Reply-To: <53B32756.6020407@posteo.de>
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.
next prev parent reply other threads:[~2014-07-01 21:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 17:41 [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 1/6] usb: ci_udc: fix ci_flush_{qh, qtd} calls in ci_udc_probe() Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 2/6] usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 3/6] usb: ci_udc: lift ilist size calculations to global scope Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 4/6] usb: ci_udc: fix items array size/stride calculation Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 5/6] usb: ci_udc: remove controller.items array Stephen Warren
2014-07-01 17:41 ` [U-Boot] [PATCH 6/6] usb: ci_udc: don't memalign() struct ci_req allocations Stephen Warren
2014-07-01 21:25 ` [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups Jörg Krause
2014-07-01 21:31 ` Stephen Warren [this message]
2014-07-01 21:36 ` Stephen Warren
2014-07-01 22:42 ` Jörg Krause
2014-07-01 22:51 ` Marek Vasut
2014-07-01 22:52 ` Stephen Warren
2014-07-01 21:57 ` Jörg Krause
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B328C4.60300@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox