linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Nick Piggin <npiggin@suse.de>
Cc: Robert Hancock <hancockrwd@gmail.com>, Tejun Heo <tj@kernel.org>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
	Colin Tuckley <colin.tuckley@arm.com>,
	Jeff Garzik <jeff@garzik.org>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v2] sata_sil24: Use memory barriers before issuing commands
Date: Fri, 11 Jun 2010 10:41:46 +0100	[thread overview]
Message-ID: <1276249306.12258.38.camel@e102109-lin.cambridge.arm.com> (raw)
In-Reply-To: <20100611013829.GB16436@laptop>

On Fri, 2010-06-11 at 02:38 +0100, Nick Piggin wrote:
> On Thu, Jun 10, 2010 at 06:43:03PM -0600, Robert Hancock wrote:
> > IMHO, it would be better for the platform code to ensure that MMIO
> > access was strongly ordered with respect to each other and to RAM
> > access. Drivers are just too likely to get this wrong, especially
> > when x86, the most tested platform, doesn't have such issues.
> 
> The plan is to make all platforms do this. writes should be
> strongly ordered with memory. That serves to keep them inside
> critical sections as well.

Are there any public references to this discussion? Maybe a
Documentation/ file (or update the memory-barriers.txt one would be
useful).

I guess correctness takes precedence here but on ARM, the only way to
ensure relative ordering between non-cacheable writes and I/O writes is
by flushing the write buffer (and an L2 write buffer if external cache
is present). Hence the expensive mb().

The only reference of DMA buffers vs I/O I found in the DMA-API.txt
file:

        Consistent memory is memory for which a write by either the
        device or the processor can immediately be read by the processor
        or device without having to worry about caching effects. (You
        may however need to make sure to flush the processor's write
        buffers before telling devices to read that memory.)

But there is no API for "flushing the processor's write buffers". Does
it mean that this should be taken care of in writel()? We would make the
I/O accessors pretty expensive on some architectures.

Thanks.

-- 
Catalin

  parent reply	other threads:[~2010-06-11  9:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100610160212.18091.29856.stgit@e102109-lin.cambridge.arm.com>
     [not found] ` <4C110EDD.2010409@kernel.org>
2010-06-10 16:23   ` [PATCH v2] sata_sil24: Use memory barriers before issuing commands Catalin Marinas
2010-06-10 16:42     ` Catalin Marinas
2010-06-11  0:43     ` Robert Hancock
2010-06-11  0:43       ` Robert Hancock
2010-06-11  1:38       ` Nick Piggin
2010-06-11  9:16         ` FUJITA Tomonori
2010-06-11  9:41         ` Catalin Marinas [this message]
2010-06-11 10:11           ` Nick Piggin
2010-06-11 10:11             ` Nick Piggin
2010-06-11 11:04             ` Catalin Marinas
2010-06-12  1:30               ` Robert Hancock
2010-06-15 11:10                 ` Catalin Marinas
2010-06-15 11:10                   ` Catalin Marinas
2010-06-15 11:31                   ` Nick Piggin
2010-06-15 11:31                     ` Nick Piggin
2010-06-19 22:32                     ` Catalin Marinas
2010-06-19 22:32                       ` Catalin Marinas
2010-06-14  0:35           ` FUJITA Tomonori
2010-06-23 13:00       ` Mark Lord

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=1276249306.12258.38.camel@e102109-lin.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=colin.tuckley@arm.com \
    --cc=hancockrwd@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=tj@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).