From patchwork Thu Mar 17 17:23:40 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 102549 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp597943lbc; Thu, 17 Mar 2016 10:24:07 -0700 (PDT) X-Received: by 10.66.248.198 with SMTP id yo6mr16447397pac.54.1458235447244; Thu, 17 Mar 2016 10:24:07 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id qd3si13591960pab.208.2016.03.17.10.24.07; Thu, 17 Mar 2016 10:24:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967325AbcCQRYF (ORCPT + 7 others); Thu, 17 Mar 2016 13:24:05 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:63297 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756424AbcCQRYE (ORCPT ); Thu, 17 Mar 2016 13:24:04 -0400 Received: from wuerfel.lan. ([78.42.132.4]) by mrelayeu.kundenserver.de (mreue003) with ESMTPA (Nemesis) id 0MdZN2-1aSFfG14t2-00PNLh; Thu, 17 Mar 2016 18:23:50 +0100 From: Arnd Bergmann To: Mark Brown Cc: Xiubo Li , Arnd Bergmann , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] regmap: fix documentation to match code Date: Thu, 17 Mar 2016 18:23:40 +0100 Message-Id: <1458235427-3856540-1-git-send-email-arnd@arndb.de> X-Mailer: git-send-email 2.7.0 X-Provags-ID: V03:K0:Er7SeTf27FUsFRFadIP+TVVasQFw9EPLr+1edv7mHI54PP1nNl1 tUEZgn6ERT6j89sUjwfVtmFWNittCGB84xtxPMfLK+3M7zNEJkOlc/9btsViWxRywBFqOVz fgeSXMHbYpVdLfi6nAnwwcDoUydMcM3knEN1oYAsWZ/JwydTrXkFpU3UxVHx+HLbQLXZ9/p 8GiYgl2QABmiQOdrsqGng== X-UI-Out-Filterresults: notjunk:1; V01:K0:rnB2LeQBhBU=:8CSVGCQiKxHXPKgnyKV5Wg r/U5EIkz0SQ5Xi+/Y3pfWy1QmaWoaS1cpsl9GmY9XSKbKe/QVacgcGps2T22efLkQfaRzHsAR zKK3P0q9gODXFn8GGqVNf81/eofFdQm3w8S2XzArX9V8xECP70Q/NSRt9gNSQ/mjcPiDAPBj9 7qNYwzNpgGsK3FmX2qaZ/2TSQxl+cYmOs7LKrWe9TkfX2bI6zrE96r5ugEvr7jMab8sqACSHy j9uKZhAbLwcjPEnuJip1Y9hBn9zWjB44ITI2BR9df3pxUVBRuLV2DF1v6WBfQtB7XFb4cKhvj SoNczXI5IX+Ye5/SlWjNSup/vhSe8SkKejt1PuHTBtcK29M8neIG6IbqcJizlmDrMiJOeXHgt +Gk6bKIFndVoJSr3qwDGTfTwkcDW6dpEakI+K0Bd+/j3chobIp7z1kfrmUxlwsgenc9JF45XX 0zo5I5pLNdGUE8NbqV+bT+a5Ihiv9ft8oEg42PAkopgVokQGk2W2wsSWb5BvZrLzRAygpx22Y x7YJXfM7C9eoA24DlJzL4nR18Ik0lFx/Vvgdl1/6Xuxrp+c5KfciZTVvaC9Zv4eoFdmO0DOou sBuqOFvCKWqS3fZomixusNV/OvgSGfrVWt/Y6+CjS5P+8EYrEKcvHsYFkEYwRm1K4Oi4xt4N1 W5Pb8DrSIlIN1WAxwmQ4EXNxwbZ67OnZDrjqCxzd9ryu4SXbErWF8GIBz3EMUHhqawCE= Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The regmap binding talks about one thing, which is register endianess, and it gets almost every aspect of it wrong. This replaces the current text of the file with a version that makes more sense and that matches what we implement now. Signed-off-by: Arnd Bergmann Fixes: a06c488da0b0 ("regmap: Add explict native endian flag to DT bindings") Fixes: 275876e208e2 ("regmap: Add the DT binding documentation for endianness") --- Hi Mark, I think this got lost when you fixed the code for 4.6, and the current documentation still has the initial text you wrote back in January that doesn't actually explain what happens. .../devicetree/bindings/regmap/regmap.txt | 59 +++++++--------------- 1 file changed, 19 insertions(+), 40 deletions(-) -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/regmap/regmap.txt b/Documentation/devicetree/bindings/regmap/regmap.txt index e98a9652ccc8..0127be360fe8 100644 --- a/Documentation/devicetree/bindings/regmap/regmap.txt +++ b/Documentation/devicetree/bindings/regmap/regmap.txt @@ -1,50 +1,29 @@ -Device-Tree binding for regmap - -The endianness mode of CPU & Device scenarios: -Index Device Endianness properties ---------------------------------------------------- -1 BE 'big-endian' -2 LE 'little-endian' -3 Native 'native-endian' - -For one device driver, which will run in different scenarios above -on different SoCs using the devicetree, we need one way to simplify -this. +Devicetree binding for regmap Optional properties: -- {big,little,native}-endian: these are boolean properties, if absent - then the implementation will choose a default based on the device - being controlled. These properties are for register values and all - the buffers only. Native endian means that the CPU and device have - the same endianness. -Examples: -Scenario 1 : CPU in LE mode & device in LE mode. -dev: dev@40031000 { - compatible = "name"; - reg = <0x40031000 0x1000>; - ... -}; + little-endian, + big-endian, + native-endian: See common-properties.txt for a definition -Scenario 2 : CPU in LE mode & device in BE mode. -dev: dev@40031000 { - compatible = "name"; - reg = <0x40031000 0x1000>; - ... - big-endian; -}; +Note: +Regmap defaults to little-endian register access on MMIO based +devices, this is by far the most common setting. On CPU +architectures that typically run big-endian operating systems +(e.g. PowerPC), registers can be defined as big-endian and must +be marked that way in the devicetree. -Scenario 3 : CPU in BE mode & device in BE mode. -dev: dev@40031000 { - compatible = "name"; - reg = <0x40031000 0x1000>; - ... -}; +On SoCs that can be operated in both big-endian and little-endian +modes, with a single hardware switch controlling both the endianess +of the CPU and a byteswap for MMIO registers (e.g. many Broadcom MIPS +chips), "native-endian" is used to allow using the same device tree +blob in both cases. -Scenario 4 : CPU in BE mode & device in LE mode. +Examples: +Scenario 1 : a register set in big-endian mode. dev: dev@40031000 { - compatible = "name"; + compatible = "syscon"; reg = <0x40031000 0x1000>; + big-endian; ... - little-endian; };