From: Clemens Ladisch <clemens@ladisch.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-kernel@vger.kernel.org, linux1394-devel@lists.sourceforge.net
Subject: Re: [PATCH + an old question] firewire: ohci: use memory barriers to order descriptor updates
Date: Wed, 28 Jul 2010 09:28:06 +0200 [thread overview]
Message-ID: <4C4FDC06.3050703@ladisch.de> (raw)
In-Reply-To: <tkrat.21d3972644f46dc9@s5r6.in-berlin.de>
Stefan Richter wrote:
> We need:
> 2. a write memory barrier between branch_address update and wake-up of
> the DMA unit by MMIO register write.
>
> Barrier 2 is implicit in writel() on most machines --- or at least I
> think it is. See this from arch/x86/include/asm/io.h:
>
> #define build_mmio_write(name, size, type, reg, barrier) \
> static inline void name(type val, volatile void __iomem *addr) \
> { asm volatile("mov" size " %0,%1": :reg (val), \
> "m" (*(volatile type __force *)addr) barrier); }
>
> build_mmio_write(writel, "l", unsigned int, "r", :"memory")
>
> Does this order the mmio write relative to previous memory writes?
This asm barrier prevents the compiler from reordering.
The main purpose of writel() and friends is to access the address space
where memory-mapped I/O ranges reside; there are architectures where the
normal memory access commands cannot be used. This does not necessarily
imply anything about reordering semantics.
However, PCI address ranges are marked by the device's config registers
as either cacheable or not, and the kernel heeds this when mapping these
ranges. Registers are, of course, marked as uncacheable.
Regards,
Clemens
next prev parent reply other threads:[~2010-07-28 7:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 11:20 [PATCH + an old question] firewire: ohci: use memory barriers to order descriptor updates Stefan Richter
2010-07-27 11:22 ` Stefan Richter
2010-07-28 7:28 ` Clemens Ladisch [this message]
2010-07-28 9:09 ` Stefan Richter
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=4C4FDC06.3050703@ladisch.de \
--to=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/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.