linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "\"David Müller (ELSOFT AG)\"" <d.mueller@elsoft.ch>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Workaround for USB DMA bugs
Date: Wed, 03 Apr 2002 11:45:41 +0200	[thread overview]
Message-ID: <3CAACF45.8090003@elsoft.ch> (raw)
In-Reply-To: 20020403024321.GN1026@zax


Hello

David Gibson wrote:
> Well, I'm not sure I'd want to pollute the tree with this sort of
> hack, but on the other hand it makes things work that wouldn't
> otherwise.
>
> Does anyone think it's a good idea to commit the following patch:
>
> diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/mm/cachemap.c linux-grinch/arch/ppc/mm/cachemap.c
> --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/mm/cachemap.c	Thu Mar 14 13:49:01 2002
> +++ linux-grinch/arch/ppc/mm/cachemap.c	Wed Apr  3 11:51:30 2002
> @@ -137,7 +137,18 @@
>  	case PCI_DMA_NONE:
>  		BUG();
>  	case PCI_DMA_FROMDEVICE:	/* invalidate only */
> +#ifdef CONFIG_USB
> +		/* The USB stack is broken in that it uses DMA buffers
> +                   on the stack which are on the stack and not
> +                   cacheline aligned.  That means cache invalidates
> +                   before DMA transfers corrupt the stack on machines
> +                   without DMA-consistent cache.  This is a nasty
> +                   workaround until the USB layer is fixed (apparently
> +                   done in 2.5). */
> +		flush_dcache_range(start, end);
> +#else
>  		invalidate_dcache_range(start, end);
> +#endif
>  		break;
>  	case PCI_DMA_TODEVICE:		/* writeback only */
>  		clean_dcache_range(start, end);
>
>


Cool. This hack fixes a problem i see with the USB stack on our boards
since quite some time.


What about replacing "#ifdef CONFIG_USB" by
"#if defined(CONFIG_USB) || defined(CONFIG_USB_MODULE)" so this
workaround works also if the USB stack is compiled with module support
enabled.

BTW
Do you know from which version of the 2.5 kernel on this buffer
alignment problem is fixed?


Dave


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

  parent reply	other threads:[~2002-04-03  9:45 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
2002-04-03 23:34       ` David Gibson
2002-04-03  9:45 ` "David Müller (ELSOFT AG)" [this message]
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=3CAACF45.8090003@elsoft.ch \
    --to=d.mueller@elsoft.ch \
    --cc=david@gibson.dropbear.id.au \
    --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).