From patchwork Mon Sep 10 15:23:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 1432591 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 11D6B4025E for ; Mon, 10 Sep 2012 15:29:00 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TB5qP-0006QX-Oj; Mon, 10 Sep 2012 15:24:13 +0000 Received: from mail-wi0-f177.google.com ([209.85.212.177]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TB5q5-0006KW-MX for linux-arm-kernel@lists.infradead.org; Mon, 10 Sep 2012 15:23:54 +0000 Received: by wibhn17 with SMTP id hn17so1626431wib.0 for ; Mon, 10 Sep 2012 08:23:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=UgFyb9LC9QpXvr+DheY3k0zTgn9uvx32/22xTEDo02Y=; b=JcIVTBJKGZlQdSg8Xe/sInlu0c144XWG89cRlpjAH8sPF5ImHWln+S/RXrEeu0p4n7 tSPA9FPKEOWiHjEMNpCFsAmTjfwxGf20JdHm/M94MkzxHRDGj9ZwKzNyW0IwrAltEXYU G+kUvbklUB9XxESdXP1Lmd/spid9kuW633cM6kTbSjRmFnq/lCEXkgQlMbZ9qsQ19aLq JqCZU1kPr1Zn1y6IljSz0u9XrLhcmHYOXkdC1/JK1YmY1j/EKZ4kpELDpzmZgmRtqUL8 xTM3ZU8sbUKf88xt6pW1N+H1ZLaG0LfSXeQilHwSc/2keErwaB3g+J6X9YQHIjmlQ/YL ls5A== MIME-Version: 1.0 Received: by 10.216.207.167 with SMTP id n39mr8839369weo.23.1347290631897; Mon, 10 Sep 2012 08:23:51 -0700 (PDT) Received: by 10.223.199.72 with HTTP; Mon, 10 Sep 2012 08:23:51 -0700 (PDT) In-Reply-To: <20120908234435.GA13519@glitch> References: <1346487390-11399-1-git-send-email-anilkumar@ti.com> <331ABD5ECB02734CA317220B2BBEABC13EA29819@DBDE01.ent.ti.com> <20120907110251.GA7968@glitch> <331ABD5ECB02734CA317220B2BBEABC13EA29BF3@DBDE01.ent.ti.com> <20120907160025.GB14330@glitch> <20120908234435.GA13519@glitch> Date: Mon, 10 Sep 2012 08:23:51 -0700 Message-ID: Subject: Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support From: Linus Walleij To: Linus Walleij , "AnilKumar, Chimata" , "bryan.wu@canonical.com" , "rpurdie@rpsys.net" , "tony@atomide.com" , "devicetree-discuss@lists.ozlabs.org" , "linux-leds@vger.kernel.org" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linus Walleij , Grant Likely , Stephen Warren X-Gm-Message-State: ALoCoQlOm/EoJ6A4Wd5a2Qm3nHyrmV/U4lpBhiRUjsDGAtYlZ+dlXLA1cMYV1ZaGjlD9IeJNrhxY X-Spam-Note: CRM114 invocation failed X-Spam-Score: -2.6 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.6 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.212.177 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Sun, Sep 9, 2012 at 1:44 AM, Domenico Andreoli wrote: > On Fri, Sep 07, 2012 at 11:57:59PM +0200, Linus Walleij wrote: >> >> If all you need to to is to multiplex the pins into GPIO mode, >> then the gpio_get() call on this driver *can* call through to >> pinctrl_request_gpio() which will in turn fall through to the >> above pinmux driver calls (.gpio_request_enable, etc). > > So if the GPIO driver doesn't coordinate with the pinctrl driver, it's > all left to the GPIO user to configure the pin before using it, right? Yes, more or less, or should I say that certain aspects of pinctrl are orthogonal to GPIO and the two mostly do not know of each other due to a separation of concerns. So the driver may need to tie things up and request its pinctrl and GPIOs independently. > I can understand the concerns of Tony, whether a pin must be requested > or not before the gpio then depends on the GPIO driver implementation, > which may or may not call through the pinctrl layer, isn't it?. Yes that is a sematic limitation, indeed. I think the best way of trying to eliminate that is to bring the two subsystems closer (which is some long-term project) but in the meantime we could propose a documentation fixup to make the semantics clear, what about this: From a92d754367861cf564c09e0b15746e02f0a96f3f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 10 Sep 2012 17:22:00 +0200 Subject: [PATCH] pinctrl: document semantics vs GPIO The semantics of the interactions between GPIO and pinctrl may be unclear, e.g. which one do you request first? This amends the documentation to make this clear. Reported-by: Domenico Andreoli Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 1479aca..941e783 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -289,6 +289,29 @@ Interaction with the GPIO subsystem The GPIO drivers may want to perform operations of various types on the same physical pins that are also registered as pin controller pins. +First and foremost, the two subsystems can be used as completely orthogonal, +so say that your driver is fetching its resources like this: + +#include +#include + +struct pinctrl *pinctrl; +int gpio; + +pinctrl = devm_pinctrl_get_select_default(&dev); +gpio = devm_gpio_request(&dev, 14, "foo"); + +Here we first request a certain pin state and then request GPIO 14 to be +used. If you're using the subsystems orthogonally like this, always get +your pinctrl handle and select the desired pinctrl state BEFORE requesting +the GPIO. This is a semantic convention to avoid situations that can be +electrically unpleasant, you may certainly want to mux in and bias pins +a certain way before the GPIO subsystems starts to deal with them. + +But there are also situations where it makes sense for the GPIO subsystem +to communicate with with the pinctrl subsystem, using the latter as a +back-end. + Since the pin controller subsystem have its pinspace local to the pin controller we need a mapping so that the pin control subsystem can figure out which pin controller handles control of a certain GPIO pin. Since a single @@ -359,6 +382,7 @@ will get an pin number into its handled number range. Further it is also passed the range ID value, so that the pin controller knows which range it should deal with. + PINMUX interfaces =================