From: "Eric DeVolder" <eric.devolder@amd.com>
To: "Hartvig Ekner" <hartvig@ekner.info>
Cc: "Pete Popov" <ppopov@mvista.com>,
"Linux MIPS mailing list" <linux-mips@linux-mips.org>
Subject: Re: Au1500 hardware cache coherency
Date: Mon, 31 Mar 2003 08:41:55 -0600 [thread overview]
Message-ID: <3E8853B3.9080902@amd.com> (raw)
In-Reply-To: 3E882FB8.BBFDACE2@ekner.info
There are data cache snoop bugs with respect to PCI on the Au1500. For the
Au1500s soldered on DbAu1500 boards to-date, PCI can not use coherent
transactions. Details in the Specification Update for the Au1500
available from:
www.amd.com/pcs
-> Technical Resources
-> AMD Alchemy Solutions Development Board Support
Login with your board and you'll be presented with various docs,
including the
spec update.
Regards,
Eric
Hartvig Ekner wrote:
>Hi Pete,
>
>I am attempting to use the HW coherency feature of the AU1500 to avoid SW flushes and increase the performance.
>In the config-shared.in file, I can see that the CONFIG_NONCOHERENT_IO define is always set for the AMD
>eval boards, which results in SW cache flushes when dma_cache_xxx functions are called. If HW coherency is
>working, this define should not be set.
>
>However, in your drivers, you only call the dma_cache functions from au1000/common/usbdev.c, but not from e.g. the ethernet
>driver or the audio driver. Is this intentional? It seems that the ethernet & audio driver already relies on HW
>coherency to function correctly (and it also sets the MAC enable bits accordingly, to force all ETH DMA
>accesses to be coherent), so why not USB also?
>
>When turning off NONCOHERENT_IO, there are some bugs (not in AU1000 code) which prevents the code from
>compiling, but I have fixed these. And the kernel boots, but during some large disk-copy tests, I get occasional
>data errors which I'm looking in to.
>
>So before spending more time on debugging this, and creating patches for using HW coherency, I wanted to hear
>your input - maybe there are known problems in the Au1500 coherency implementation?
>
>/Hartvig
>
>
>
>
>
>
next prev parent reply other threads:[~2003-03-31 14:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-31 12:08 Au1500 hardware cache coherency Hartvig Ekner
2003-03-31 14:41 ` Eric DeVolder [this message]
2003-03-31 15:14 ` Hartvig Ekner
2003-03-31 18:06 ` Eric DeVolder
2003-03-31 19:24 ` Hartvig Ekner
2003-03-31 20:33 ` Pete Popov
2003-04-01 7:51 ` Hartvig Ekner
2003-04-01 18:22 ` Pete Popov
2003-04-01 18:23 ` Pete Popov
2003-04-02 12:17 ` Maciej W. Rozycki
2003-03-31 18:35 ` Pete Popov
2003-04-01 11:47 ` Ralf Baechle
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=3E8853B3.9080902@amd.com \
--to=eric.devolder@amd.com \
--cc=hartvig@ekner.info \
--cc=linux-mips@linux-mips.org \
--cc=ppopov@mvista.com \
/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.