From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Bryan O'Sullivan" <bos@pathscale.com>
Cc: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Define wc_wmb, a write barrier for PCI write combining
Date: Tue, 28 Feb 2006 09:44:31 -0800 [thread overview]
Message-ID: <200602280944.32210.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <1140894083.9852.30.camel@localhost.localdomain>
On Saturday, February 25, 2006 11:01 am, Bryan O'Sullivan wrote:
> On Sat, 2006-02-25 at 14:28 +0100, Andi Kleen wrote:
> > Before we can add such a macro I suspect you would first
> > need to provide some spec how that "portable write combining"
> > is supposed to work and get feedback from the other architectures.
>
> It seems like we'd need a function that tries to enable or disable
> write combining on an MMIO memory range. This would be implemented by
> arches that support it, and would fail on others. Drivers could then
> try to enable write combining, and if it failed, either bail, print a
> warning message, or do something else appropriate.
>
> So on i386 and x86_64, this function would fiddle with the MTRRs. On
> powerpc, it would either configure the northbridge appropriately or
> fail. On other arches, I don't know enough to say, so the default
> would be to fail.
>
> Is this reasonable? I can code a strawman implementation up, if the
> basic idea looks sane.
Something like this would be really handy. Check out fbmem.c:fb_mmap for
a bad example of what can happen w/o it.
In fact, I think it might make sense to export WC functionality via an
mmap flag (on an advisory basis since the platform may not support it or
there may be aliasing issues that prevent it); having an arch
independent routine to request it would make that addition easy to do in
generic code. (In particular I wanted this for the sysfs PCI interface.
Userspace apps can map PCI resources there and it would be nice if they
could map them with WC semantics if requested.)
I don't think it addresses the flushing issue you seem to be concerned
about though. I don't know the exact semantics of sfence, but I think
bcrl is likely right that it won't absolutely guarantee that your writes
have hit the device before proceeding (though it may do that on some CPU
implementations).
Thanks,
Jesse
next prev parent reply other threads:[~2006-02-28 17:44 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-25 4:20 [PATCH] Define wc_wmb, a write barrier for PCI write combining Bryan O'Sullivan
2006-02-25 4:43 ` Andi Kleen
2006-02-25 7:34 ` Bryan O'Sullivan
2006-02-25 13:28 ` Andi Kleen
2006-02-25 17:20 ` Bryan O'Sullivan
2006-02-25 19:01 ` Bryan O'Sullivan
2006-02-28 17:44 ` Jesse Barnes [this message]
2006-02-28 17:50 ` Roland Dreier
2006-02-28 17:50 ` Jesse Barnes
2006-02-28 17:52 ` Bryan O'Sullivan
2006-02-28 17:59 ` Jesse Barnes
2006-02-25 14:28 ` Benjamin LaHaise
2006-02-25 17:11 ` Bryan O'Sullivan
2006-02-25 17:41 ` Benjamin LaHaise
2006-02-28 17:50 ` Bryan O'Sullivan
2006-02-28 17:58 ` Benjamin LaHaise
2006-02-28 18:20 ` Bryan O'Sullivan
2006-02-28 19:03 ` Benjamin LaHaise
2006-02-28 19:20 ` Bryan O'Sullivan
2006-02-28 19:33 ` Andi Kleen
2006-02-28 19:44 ` Bryan O'Sullivan
2006-03-01 19:20 ` Bryan O'Sullivan
2006-03-01 19:27 ` Andi Kleen
2006-03-01 19:43 ` Bryan O'Sullivan
2006-03-01 19:49 ` Andi Kleen
2006-03-01 20:05 ` Bryan O'Sullivan
2006-03-01 20:26 ` Benjamin LaHaise
2006-03-01 20:35 ` Bryan O'Sullivan
2006-02-28 19:34 ` Benjamin LaHaise
2006-02-28 18:22 ` Christopher Friesen
2006-02-28 10:01 ` Jes Sorensen
2006-02-28 15:42 ` Roland Dreier
2006-02-28 16:08 ` Jes Sorensen
2006-02-28 17:02 ` Roland Dreier
2006-02-28 17:13 ` Jesse Barnes
2006-02-28 17:20 ` Jes Sorensen
2006-03-01 8:16 ` Jeremy Higdon
2006-03-01 8:24 ` Jeremy Higdon
2006-02-28 17:11 ` Jesse Barnes
2006-02-28 17:57 ` Bryan O'Sullivan
2006-02-28 18:07 ` linux-os (Dick Johnson)
2006-02-28 18:24 ` Christopher Friesen
2006-03-01 10:45 ` Jes Sorensen
2006-03-01 17:04 ` Roland Dreier
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=200602280944.32210.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=bos@pathscale.com \
--cc=linux-kernel@vger.kernel.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).