From patchwork Thu May 22 16:47:29 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 30648 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-oa0-f69.google.com (mail-oa0-f69.google.com [209.85.219.69]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 2C06620671 for ; Thu, 22 May 2014 16:54:24 +0000 (UTC) Received: by mail-oa0-f69.google.com with SMTP id i7sf17106747oag.8 for ; Thu, 22 May 2014 09:54:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=2in+T7OitsqoCo3735lWUZS349iNM9sTmjiAjp1rbXg=; b=U3aEB/T8JMLkoi0VBOPZGF4lLOMhcbzfAmFR0uKizD2jvqO8HjQSG78SONDfWD79Hw cXHg6kLYJSnP158PaukpD9iM3D8bpA/2ah9/nqUxeQHVrqb/melYxG93l2lUr3KvIrNM 9Xxo2h54pXmAn3/2hSRKGrRbTMFKsdf5WVoqPIFkskbkmjHcPxzEKYOxaECeM2SVA7oh lKgyOHC8vxyGxRovvPsoZNPgCdkiQv/Rv/sWFgq0YnHVr+UKZzzbWZx3mR+9CSZX2zCp qA36u+Vslo8jwn0DOaqB9+pbSCF7KQy57mUUX9oJtFlCgX74Bij3j0Xsb8l9O7vAtZ+0 zn3g== X-Gm-Message-State: ALoCoQnf3QEaqAvi5lXGZ1VAzd/aqhnkQ39xhB7mypfAFBGkMDIIIcGJtM4J+CGNSu70pPgz42A/ X-Received: by 10.182.128.166 with SMTP id np6mr26211102obb.16.1400777663739; Thu, 22 May 2014 09:54:23 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.19.83 with SMTP id 77ls1268105qgg.28.gmail; Thu, 22 May 2014 09:54:23 -0700 (PDT) X-Received: by 10.52.255.98 with SMTP id ap2mr14379238vdd.3.1400777663586; Thu, 22 May 2014 09:54:23 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx.google.com with ESMTPS id fi8si207890vdb.57.2014.05.22.09.54.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 09:54:23 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.175 as permitted sender) client-ip=209.85.128.175; Received: by mail-ve0-f175.google.com with SMTP id jw12so4732302veb.6 for ; Thu, 22 May 2014 09:54:23 -0700 (PDT) X-Received: by 10.58.169.97 with SMTP id ad1mr2219342vec.45.1400777663496; Thu, 22 May 2014 09:54:23 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp215487vcb; Thu, 22 May 2014 09:54:23 -0700 (PDT) X-Received: by 10.66.66.66 with SMTP id d2mr69615337pat.36.1400777662753; Thu, 22 May 2014 09:54:22 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oe6si387939pbb.238.2014.05.22.09.54.21 for ; Thu, 22 May 2014 09:54:21 -0700 (PDT) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753345AbaEVQyO (ORCPT + 27 others); Thu, 22 May 2014 12:54:14 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:48882 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752751AbaEVQsT (ORCPT ); Thu, 22 May 2014 12:48:19 -0400 Received: from edgewater-inn.cambridge.arm.com (edgewater-inn.cambridge.arm.com [10.1.203.25]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id s4MGlYws028182; Thu, 22 May 2014 17:47:35 +0100 (BST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 39B6D1AE3432; Thu, 22 May 2014 17:47:35 +0100 (BST) From: Will Deacon To: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Cc: arnd@arndb.de, monstr@monstr.eu, dhowells@redhat.com, broonie@linaro.org, benh@kernel.crashing.org, peterz@infradead.org, paulmck@linux.vnet.ibm.com, Will Deacon , Randy Dunlap Subject: [PATCH v2 17/18] documentation: memory-barriers: clarify relaxed io accessor semantics Date: Thu, 22 May 2014 17:47:29 +0100 Message-Id: <1400777250-17335-18-git-send-email-will.deacon@arm.com> X-Mailer: git-send-email 1.9.2 In-Reply-To: <1400777250-17335-1-git-send-email-will.deacon@arm.com> References: <1400777250-17335-1-git-send-email-will.deacon@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: will.deacon@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.175 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , This patch extends the paragraph describing the relaxed read io accessors so that the relaxed accessors are defined to be: - Ordered with respect to each other if accessing the same peripheral - Unordered with respect to normal memory accesses - Unordered with respect to LOCK/UNLOCK operations Whilst many architectures will provide stricter semantics, ARM, Alpha and PPC can achieve significant performance gains by taking advantage of some or all of the above relaxations. Cc: Randy Dunlap Cc: Benjamin Herrenschmidt Cc: Paul E. McKenney Cc: David Howells Signed-off-by: Will Deacon --- Documentation/memory-barriers.txt | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 556f951f8626..f31c88691ee9 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -2462,10 +2462,15 @@ functions: Please refer to the PCI specification for more information on interactions between PCI transactions. - (*) readX_relaxed() - - These are similar to readX(), but are not guaranteed to be ordered in any - way. Be aware that there is no I/O read barrier available. + (*) readX_relaxed(), writeX_relaxed() + + These are similar to readX() and writeX(), but provide weaker memory + ordering guarantees. Specifically, they do not guarantee ordering with + respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee + ordering with respect to LOCK or UNLOCK operations. If the latter is + required, an mmiowb() barrier can be used. Note that relaxed accesses to + the same peripheral are guaranteed to be ordered with respect to each + other. (*) ioreadX(), iowriteX()