linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Blythe <blythe@routefree.com>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Workaround for USB DMA bugs
Date: Wed, 03 Apr 2002 12:43:01 -0800	[thread overview]
Message-ID: <3CAB6955.6000103@routefree.com> (raw)
In-Reply-To: 3CAB40C1.8000909@embeddededge.com


What he said!  We ended up making all of the changes to move buffers,
align them, etc for both USB and skbuffs, as well as fixing the overly
aggressive prefetches in memcpy that overlapped previously
cache-invalidated memory, etc.  The end result is an ugly set of
changes, but at least the board works reliably now.  We also found one
nasty problem with an Epson USB printer where after request buffers were
bloated to cache line aligned length and the bloated length passed to
the device, that the device doesn't like the bloated length.  So we
hacked up the control path a little to get at the original length  too.
  This sort of stuff is a real pain to fix correctly to deal nicely with
non-coherent systems.

	david

Dan Malek wrote:
>
> Armin wrote:
>
>
>
>> Ah yes,  We have done something simular (internally) and had the same
>> reservations. This will help me with the ocp usb drivers i am working
>> on.   I would like to see some way of reminding us that this was done.
>> let say a config option for 4xx_usb_dma_workarround.
>
>
> It isn't unique to 4xx.  This was originally done for the 8xx USB
> (actually,
> probably for StrongARM and I just copied it over).  These functions are
> only used for incoherent processors, so there isn't any need to further
> define this with another config option.  Just leave a comment here, change
> the #ifdef CONFIG_USB to #if 1 (it should be done all of the time).
>
> Just remember this is not a solution, and simply makes the problem less
> likely to appear.  If you happen to perform this operation, and then the
> processor happens to touch the cache line before the DMA is complete,
> your DMA buffer will still be corrputed.  So far, we have just been lucky
> the DMA completes before anything else in the cache line is touched by
> the processor.  This only guarantees the processor will never get incorrect
> information when it shares a cache line with a DMA.
>
>
>     -- Dan
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-04-03 20:43 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-03  2:43 Workaround for USB DMA bugs David Gibson
2002-04-03  8:17 ` Armin
2002-04-03 17:39   ` Frank Rowand
2002-04-03 17:49   ` Dan Malek
2002-04-03 20:43     ` David Blythe [this message]
2002-04-03 23:34       ` David Gibson
2002-04-03  9:45 ` "David Müller (ELSOFT AG)"
2002-04-03 23:35   ` David Gibson
2002-04-03 17:42 ` Dan Malek
2002-04-03 23:40   ` David Gibson
2002-04-04  2:54     ` Dan Malek
2002-04-04  3:48       ` David Gibson
2002-04-04  4:09         ` Dan Malek
2002-04-04  5:23           ` David Gibson
2002-04-04  6:08             ` Dan Malek
2002-04-04  6:30               ` David Gibson
2002-04-04 20:21                 ` David Blythe
2002-04-04 12:35       ` Brad Parker
2002-04-04 14:12         ` Dan Malek
  -- strict thread matches above, loose matches on Subject: below --
2002-04-04  4:19 Jeremy Rosen
2002-04-04  6:16 ` Dan Malek
2002-04-04  6:32   ` David Gibson
2002-04-04  6:40 Rosen Jeremy
2002-04-04  6:52 ` David Gibson

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=3CAB6955.6000103@routefree.com \
    --to=blythe@routefree.com \
    --cc=linuxppc-embedded@lists.linuxppc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).