All of lore.kernel.org
 help / color / mirror / Atom feed
From: bigeasy@linutronix.de (Sebastian Andrzej Siewior)
To: linux-arm-kernel@lists.infradead.org
Subject: Moan: usage of __iormb() and __iowmb() outside of asm/io.h
Date: Tue, 9 Jun 2015 11:54:58 +0200	[thread overview]
Message-ID: <20150609095458.GA972@linutronix.de> (raw)
In-Reply-To: <20150608184701.GA7557@n2100.arm.linux.org.uk>

* Russell King - ARM Linux | 2015-06-08 19:47:01 [+0100]:

>These are not official kernel barriers - the only reason they exist in
>asm/io.h is purely to provide a barrier implementation _for_ creating
>the accessors _in_ asm/io.h, which are macros, and therefore these
>macros need to stay around for the same scope as those accessors.

I'm sorry for that. Are those _relaxed() accessors okay? They don't show
up in Documentation/ so I ask here before I do it wrong again?

On the other hand if Tony or someone else things that this is not worth
it at all I could stick with readl/writel and drop the barries. It is
just that musb and releated code used those __raw accessors and I ended
up with them, too (I'm not looking for an excuse just saying that I do
not have any numbers to show which say that this is good in terms of
performance and worth keeping).

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -257,12 +257,12 @@ static struct cppi41_channel *desc_to_chan(struct cppi41_dd *cdd, u32 desc)
 
 static void cppi_writel(u32 val, void *__iomem *mem)
 {
-	__raw_writel(val, mem);
+	writel_relaxed(val, mem);
 }
 
 static u32 cppi_readl(void *__iomem *mem)
 {
-	return __raw_readl(mem);
+	return readl_relaxed(mem);
 }
 
 static u32 pd_trans_len(u32 val)
@@ -308,7 +308,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
 		}
 
 		if (val)
-			__iormb();
+			rmb();
 
 		while (val) {
 			u32 desc, len;
@@ -410,14 +410,7 @@ static void cppi41_dma_issue_pending(struct dma_chan *chan)
 		reg |= c->q_comp_num;
 	}
 
-	cppi_writel(reg, c->gcr_reg);
-
-	/*
-	 * We don't use writel() but __raw_writel() so we have to make sure
-	 * that the DMA descriptor in coherent memory made to the main memory
-	 * before starting the dma engine.
-	 */
-	__iowmb();
+	writel(reg, c->gcr_reg);
 	push_desc_queue(c);
 }
 
@@ -546,7 +539,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
 
 	if (!c->td_queued) {
 		cppi41_compute_td_desc(td);
-		__iowmb();
+		wmb();
 
 		reg = (sizeof(struct cppi41_desc) - 24) / 4;
 		reg |= td_desc_phys;
@@ -577,7 +570,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
 		} else if (desc_phys == td_desc_phys) {
 			u32 pd0;
 
-			__iormb();
+			rmb();
 			pd0 = td->pd0;
 			WARN_ON((pd0 >> DESC_TYPE) != DESC_TYPE_TEARD);
 			WARN_ON(!c->is_tx && !(pd0 & TD_DESC_IS_RX));

  reply	other threads:[~2015-06-09  9:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 18:47 Moan: usage of __iormb() and __iowmb() outside of asm/io.h Russell King - ARM Linux
2015-06-09  9:54 ` Sebastian Andrzej Siewior [this message]
2015-06-10 10:59 ` Murali Karicheri
2015-06-10 17:25   ` santosh shilimkar
2015-06-10 11:18 ` Will Deacon
2015-06-10 11:24   ` Russell King - ARM Linux
2015-06-10 12:30     ` Russell King - ARM Linux
2015-06-10 16:53       ` Catalin Marinas
2015-06-10 16:59         ` Will Deacon
2015-06-11 14:16           ` Russell King - ARM Linux

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=20150609095458.GA972@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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.