From: David Daney <ddaney@avtrex.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com>,
linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: Patch: ATI Xilleon port 2/11 net/e100 Memory barriers and write flushing
Date: Fri, 21 Oct 2005 09:01:41 -0700 [thread overview]
Message-ID: <435910E5.2080706@avtrex.com> (raw)
In-Reply-To: <20051021083653.GB17881@linux-mips.org>
Ralf Baechle wrote:
> On Thu, Oct 20, 2005 at 12:01:01PM -0700, Jesse Brandeburg wrote:
>
>
>>>@@ -584,6 +584,7 @@ static inline void e100_write_flush(stru
>>> {
>>> /* Flush previous PCI writes through intermediate bridges
>>> * by doing a benign read */
>>>+ wmb();
>>> (void)readb(&nic->csr->scb.status);
>>> }
>>
>>I find it odd that this is needed, the readb is meant to flush all
>>posted writes on the pci bus, if your bus is conforming to pci
>>specifications, this must succeed. wmb is for host side (processor
>>memory) writes to complete, and since we're usually only try to force
>>a writeX command to execute immediately with the readb (otherwise lazy
>>writes work okay) we shouldn't need a wmb *here*. not to say it might
>>not be missing somewhere else.
>
>
> wmb is defined as a sync instruction which will only complete once the
> write has actually left the CPU, that is citing the spec "has become
> globally visible". Uncached stores such as writeX() may be held in a
> writeback buffers potencially infinitely, until this buffer is needed
> by another write operation. The real surprise is to see such behaviour
> in a modern piece of silicon; the only that I knew of were the R3000-class
> processors and that era has ended over a decade ago, so ATI seems to have
> done something funny here.
In light of all the comments, and:
1) the fact that the drivers for the e100 in the 2.4.30 kernel
distribution work well.
2) other pci drivers work well with this port (usb/ohci, net/8139too).
3) the properties of the write back buffer are not well documented.
I am going to take a more detailed look at trying to fix this problem in
a less intrusive manner.
David Daney.
prev parent reply other threads:[~2005-10-21 16:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-20 5:54 Patch: ATI Xilleon port 2/11 net/e100 Memory barriers and write flushing David Daney
2005-10-20 7:47 ` Arjan van de Ven
2005-10-20 19:01 ` Jesse Brandeburg
2005-10-21 8:36 ` Ralf Baechle
2005-10-21 16:01 ` David Daney [this message]
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=435910E5.2080706@avtrex.com \
--to=ddaney@avtrex.com \
--cc=jesse.brandeburg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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.