From: anti.sullin@artecdesign•ee (Anti Sullin)
To: linux-arm-kernel@lists•infradead.org
Subject: [patch v3 2/3] at91_udc HW glitch
Date: Thu, 25 Mar 2010 15:09:46 +0200 [thread overview]
Message-ID: <4BAB609A.9030407@artecdesign.ee> (raw)
In-Reply-To: <6681f8e11003250503k20efc864ve6d916ad5a7c67b2@mail.gmail.com>
Harro Haan wrote:
> On 23 March 2010 21:26, Andrew Victor <avictor.za@gmail•com> wrote:
>> The at91_udc driver does not seem to do that for its CSR register writes.
>> So I was wondering if we implement what the datasheet says, would we
>> still need the "fix" above.
Another read is still needed after verifying that the flag is changed.
We are writing a bit that does not have a register behind it. It just
triggers the acknowledge that the data has been read.
We could poll if the corresponding data ready flag is cleared to check
if the write has propagated. But this leads to another problem:
the reads do not seem to be re-syncronized between clock domains.
We just get what is there at the moment the read is performed. This
means that even if the "data ready" bit is cleared, we could not be sure
at that moment that the rest of the changes have been performed
that were triggered by the same write. We even get reads, where
some bits in rx data counter have changed and some bits are old.
So to be fully sure, we should wait until the bit has been cleared
and then perform another read to be sure that the rest of the bits
have been changed as well. See my 2009-03-25 17:08 e-mail for details.
next prev parent reply other threads:[~2010-03-25 13:09 UTC|newest]
Thread overview: 19+ 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-31 20:08 ` Ryan Mallon
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-25 12:03 ` Harro Haan
2010-03-25 13:09 ` Anti Sullin [this message]
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
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=4BAB609A.9030407@artecdesign.ee \
--to=anti.sullin@artecdesign$(echo .)ee \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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