Received: by 10.213.65.68 with SMTP id h4csp410065imn; Wed, 28 Mar 2018 06:05:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/1ZI+XgNF58MTFrKAtSSxSqYEy1c/H3ZbQpToKX1JyUs2yQXckfTCbbXUxnCZNVf0wIC6E X-Received: by 2002:a17:902:3181:: with SMTP id x1-v6mr3852766plb.2.1522242300275; Wed, 28 Mar 2018 06:05:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522242300; cv=none; d=google.com; s=arc-20160816; b=j19o/6aVzpMbX05eIo9a9+zlaAUrpxMk6FC8GcQSAiag7pUHDddxUL2K9gfoNUeapu RIMsYM6Ghkp99KrZ0ddUXKVoQ0gA8cuq8QmN0rFghR41fYRGtlpCY8Es571UPlYvrGKY p33KnHrgNlaBvMOBiz6uay7LvX4QbFu5mcMuJt14X8qPc9UrBNXSgD7i7WSXVvLm+Yco RpwnJMiGw+/uVo3KS+lbPYjnbTXsclR4LFSW876jgUk/fi/E6WBirOvV6EF394NC1Hj6 HpzO0nz5xHhP3VbYpLSeqhqRIHb6jtnITtOFMBEDpts5h+ZXsSMo9kwXDSLIh4lDrt+n 2ZiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=S6E4i2jgtRYIWbQvGEElIllT3LnGt5mbSNVqIyr9EOc=; b=RlMbmoYDanO7uWd/UIt+XnhBKLgy/p9fAUkoNOsrkeBhI0u3jMWQHG8tNK287e5r7h /jYEKxVskSMmfGgvP1SYl4J1JnzTq37Kys5KRx11CGV7upu1NNIbTm2e2H150PlrK/sy 5zDJCmdHfCv1cLNm7qJ3UyWONzF8SAJ+HIliDgqpn4xdOGOMCHI+TZrr2yaBKguP/mKp KH7G/XUZJuAULnkC6VfvfS9iI5Dmee/1IxhQXTuIWywiI7PgGRFjPX4lpxw0QCKXxax1 tW7QENC+RB1Ldg2ZlfbHwxI9dpy0rYM0ZdaiOEPmTGuzEC46z36olSjpdQPyunOTUW2j jTvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=kP65tCC5; dkim=pass header.i=@codeaurora.org header.s=default header.b=JejXgi78; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1-v6si3583116pld.312.2018.03.28.06.04.45; Wed, 28 Mar 2018 06:05:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=kP65tCC5; dkim=pass header.i=@codeaurora.org header.s=default header.b=JejXgi78; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753187AbeC1NCk (ORCPT + 99 others); Wed, 28 Mar 2018 09:02:40 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:43266 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752738AbeC1NCi (ORCPT ); Wed, 28 Mar 2018 09:02:38 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 68250607E4; Wed, 28 Mar 2018 13:02:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522242157; bh=3pzBRTZfPLYCT3AuXPlIdnxbU0y87ezZS5/lpVOBMg8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kP65tCC5/Ducf/Kp294LwwdAeEuHjVlqIawCqECqhfNAiQK0mdiFE3zU+TezHySVK 1lt/lP3+Du30SGEwAUxkxprprIeksHaCV641wCkwOife8lufOsZtTLafkILJUmJYhG ZzXWzzPGsZ8eanwawpOPgptTbQG9zv7Tpyem3bt4= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [192.168.0.105] (cpe-174-109-247-98.nc.res.rr.com [174.109.247.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A9E2F60F90; Wed, 28 Mar 2018 13:02:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522242156; bh=3pzBRTZfPLYCT3AuXPlIdnxbU0y87ezZS5/lpVOBMg8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JejXgi78PJcjTkTK7qgQaIhwSmyTSzrlcAHKexdMcRfuzLTVEz8pAGIz/ut+Eq3ut 1V2vybiGLRlEng29x/z3dzkwKa6OxJq1sXT4GSj7AKui5k6XKgysr1UlLp/2UbK46I rao17ZM3MyX/obzrujoZv4k1VqJ3xjpTIMEyZULQ= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A9E2F60F90 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example To: paulmck@linux.vnet.ibm.com, Will Deacon Cc: "linux-kernel@vger.kernel.org" , linux-doc@vger.kernel.org, Benjamin Herrenschmidt , Arnd Bergmann , Jason Gunthorpe , Peter Zijlstra , Ingo Molnar , Jonathan Corbet , linux-ia64@vger.kernel.org References: <1522156287-15169-1-git-send-email-will.deacon@arm.com> <20180327150252.GN3675@linux.vnet.ibm.com> From: Sinan Kaya Message-ID: Date: Wed, 28 Mar 2018 09:02:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180327150252.GN3675@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +linux-ia64 On 3/27/2018 11:02 AM, Paul E. McKenney wrote: > On Tue, Mar 27, 2018 at 02:11:27PM +0100, Will Deacon wrote: >> The section of memory-barriers.txt that describes the dma_Xmb() barriers >> has an incorrect example claiming that a wmb() is required after writing >> to coherent memory in order for those writes to be visible to a device >> before a subsequent MMIO access using writel() can reach the device. >> >> In fact, this ordering guarantee is provided (at significant cost on some >> architectures such as arm and power) by writel, so the wmb() is not >> necessary. writel_relaxed exists for cases where this ordering is not >> required. >> >> Fix the example and update the text to make this clearer. >> >> Cc: Benjamin Herrenschmidt >> Cc: Arnd Bergmann >> Cc: Jason Gunthorpe >> Cc: "Paul E. McKenney" >> Cc: Peter Zijlstra >> Cc: Ingo Molnar >> Cc: Jonathan Corbet >> Reported-by: Sinan Kaya >> Signed-off-by: Will Deacon > > Good catch, queued on my lkmm branch, thank you! > > Thanx, Paul > Does IA64 follow this requirement? If not, is implementation planned? "no wmb() before writel()" Linus asked us to get rid of wmb() in front of writel() for UC memory. Just checking that we are not breaking anything for IA64. >> --- >> Documentation/memory-barriers.txt | 17 +++++++++-------- >> 1 file changed, 9 insertions(+), 8 deletions(-) >> >> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt >> index a863009849a3..3247547d1c36 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -1909,9 +1909,6 @@ There are some more advanced barrier functions: >> /* assign ownership */ >> desc->status = DEVICE_OWN; >> >> - /* force memory to sync before notifying device via MMIO */ >> - wmb(); >> - >> /* notify device of new descriptors */ >> writel(DESC_NOTIFY, doorbell); >> } >> @@ -1919,11 +1916,15 @@ There are some more advanced barrier functions: >> The dma_rmb() allows us guarantee the device has released ownership >> before we read the data from the descriptor, and the dma_wmb() allows >> us to guarantee the data is written to the descriptor before the device >> - can see it now has ownership. The wmb() is needed to guarantee that the >> - cache coherent memory writes have completed before attempting a write to >> - the cache incoherent MMIO region. >> - >> - See Documentation/DMA-API.txt for more information on consistent memory. >> + can see it now has ownership. Note that, when using writel(), a prior >> + wmb() is not needed to guarantee that the cache coherent memory writes >> + have completed before writing to the MMIO region. The cheaper >> + writel_relaxed() does not provide this guarantee and must not be used >> + here. >> + >> + See the subsection "Kernel I/O barrier effects" for more information on >> + relaxed I/O accessors and the Documentation/DMA-API.txt file for more >> + information on consistent memory. >> >> >> MMIO WRITE BARRIER >> -- >> 2.1.4 >> > > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.