From: anti.sullin@artecdesign.ee (Anti Sullin)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch v2 1/2] at91_udc.c read_fifo timing issue
Date: Mon, 01 Feb 2010 00:34:44 +0200 [thread overview]
Message-ID: <4B660584.7020302@artecdesign.ee> (raw)
In-Reply-To: <20100129162155.709756286@gmail.com>>
Harro Haan wrote:
> This solves the read_fifo timing issue for example seen with CDC
Ethernet.
[...]
Still this bug not fixed?
I sent almost the same fix and a lot of debug info with description of
the issue and the critical path of the timing to linux-arm-kernel on
2009-03-25 (
http://lists.arm.linux.org.uk/lurker/message/20090325.150843.f515c02f.en.html
) and we had an off-list discussion with David Brownell about another
udc patch on 2009-06-19 that later turned out to be the same issue.
This fix has solved the problems on our devices and we've been using it
for almost a year now.
About Harro's patch:
* why are the marker1 and marker2 comments necessary to be included?
* maybe you should just link to the mailing list and/or move the long
comment to patch description instead adding a page-long comment to code;
just leave a small comment to explain why the work-around is needed so
that nobody would optimize it away?
* Is the error check and warning message necessary after we've got rid
of the problem? Won't it add problems - as I found out, the first csr
read (that comes too early) may return bogus data, you should not use
its result at all.
--
Anti Sullin
Embedded Software Engineer
Artec Design LLC
Teaduspargi 6/2, 12618, Tallinn, Estonia
http://www.artecdesign.ee
WARNING: multiple messages have this Message-ID (diff)
From: Anti Sullin <anti.sullin@artecdesign.ee>
To: Harro Haan <hrhaan@gmail.com>
Cc: Ryan Mallon <ryan@bluewatersys.com>,
Remy Bohmer <linux@bohmer.net>,
Andrew Victor <avictor.za@gmail.com>,
David Brownell <dbrownell@users.sourceforge.net>,
H Hartley Sweeten <hartleys@visionengravers.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [patch v2 1/2] at91_udc.c read_fifo timing issue
Date: Mon, 01 Feb 2010 00:34:44 +0200 [thread overview]
Message-ID: <4B660584.7020302@artecdesign.ee> (raw)
In-Reply-To: <20100129162155.709756286@gmail.com>>
Harro Haan wrote:
> This solves the read_fifo timing issue for example seen with CDC
Ethernet.
[...]
Still this bug not fixed?
I sent almost the same fix and a lot of debug info with description of
the issue and the critical path of the timing to linux-arm-kernel on
2009-03-25 (
http://lists.arm.linux.org.uk/lurker/message/20090325.150843.f515c02f.en.html
) and we had an off-list discussion with David Brownell about another
udc patch on 2009-06-19 that later turned out to be the same issue.
This fix has solved the problems on our devices and we've been using it
for almost a year now.
About Harro's patch:
* why are the marker1 and marker2 comments necessary to be included?
* maybe you should just link to the mailing list and/or move the long
comment to patch description instead adding a page-long comment to code;
just leave a small comment to explain why the work-around is needed so
that nobody would optimize it away?
* Is the error check and warning message necessary after we've got rid
of the problem? Won't it add problems - as I found out, the first csr
read (that comes too early) may return bogus data, you should not use
its result at all.
--
Anti Sullin
Embedded Software Engineer
Artec Design LLC
Teaduspargi 6/2, 12618, Tallinn, Estonia
http://www.artecdesign.ee
next prev parent reply other threads:[~2010-01-31 22:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 16:30 [patch 0/2] at91_udc driver: read_fifo timing issue + use spinlocks Harro Haan
2010-01-27 16:30 ` [patch 1/2] at91_udc.c read_fifo timing issue Harro Haan
2010-01-27 16:30 ` [patch 2/2] at91_udc.c use spinlocks instead of local_irq_xxx Harro Haan
2010-01-27 17:37 ` H Hartley Sweeten
2010-01-28 12:52 ` Harro Haan
2010-01-29 16:20 ` [patch v2 0/2] at91_udc driver: read_fifo timing issue + use spinlocks Harro Haan
2010-01-29 16:20 ` [patch v2 1/2] at91_udc.c read_fifo timing issue Harro Haan
2010-01-29 17:04 ` Remy Bohmer
2010-01-29 17:04 ` Remy Bohmer
2010-01-31 20:08 ` Ryan Mallon
2010-01-31 20:08 ` Ryan Mallon
2010-01-31 22:34 ` Anti Sullin [this message]
2010-01-31 22:34 ` Anti Sullin
2010-02-03 14:37 ` [patch v3 0/3] at91_udc: fix soft lockup, HW glitch and use spinlocks Harro Haan
2010-02-03 14:37 ` [patch v3 1/3] Fix soft lockup in at91 udc driver Harro Haan
2010-02-03 14:37 ` [patch v3 2/3] at91_udc HW glitch Harro Haan
2010-03-23 20:26 ` Andrew Victor
2010-03-23 20:26 ` Andrew Victor
2010-03-25 12:03 ` Harro Haan
2010-03-25 12:03 ` Harro Haan
2010-03-25 13:09 ` Anti Sullin
2010-03-25 13:09 ` Anti Sullin
2010-02-03 14:37 ` [patch v3 3/3] at91_udc.c use spinlocks instead of local_irq_xxx Harro Haan
2010-01-29 16:20 ` [patch v2 2/2] " Harro Haan
2010-01-29 17:27 ` H Hartley Sweeten
2010-01-29 17:27 ` H Hartley Sweeten
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=4B660584.7020302@artecdesign.ee \
--to=anti.sullin@artecdesign.ee \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.