From patchwork Wed Apr 10 08:12:29 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Lad, Prabhakar" X-Patchwork-Id: 2419751 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork1.kernel.org (Postfix) with ESMTP id F10483FD8C for ; Wed, 10 Apr 2013 08:12:59 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UPq9K-0001Dw-53; Wed, 10 Apr 2013 08:12:58 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UPq9H-0006tK-On; Wed, 10 Apr 2013 08:12:55 +0000 Received: from mail-wg0-f53.google.com ([74.125.82.53]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UPq9E-0006sy-FN for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2013 08:12:53 +0000 Received: by mail-wg0-f53.google.com with SMTP id c11so182866wgh.32 for ; Wed, 10 Apr 2013 01:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1PilaI9W03BaPs1ONC83QFXuHmeoSVqo9YVm7ZIev5Y=; b=B3kOruce0u9dRrqkF/canxjt43tVLZocQyhW25WJwMBd/M2zCf3Ea1D+C4Pg+FdcmH rlEiY3mfGo2B8iKOYQFY7mSeYioLOrB045izXJiq1ODJRR28P2iQU/d0qliKlnB92I1l 3wOM4a+fXRW9tWbkBfwRR4jAYGL+tDiqMY2asXoyG6QK5WdYzlRhpijtl50yImTiw2pC aSHDFiqTWVNEQ60wxubTR6y3YrXELwoGQ2k+IQk7c3fNoZsiqsy/S7OakSR7lUueTNda MlF06EBNkd143/gpUarp7zwq2TkJiL5oiCzDFIkv+KDZiFfxwT/lDyuUuxPobnOOoopW TX1Q== X-Received: by 10.180.92.97 with SMTP id cl1mr24782167wib.19.1365581569412; Wed, 10 Apr 2013 01:12:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.143.20 with HTTP; Wed, 10 Apr 2013 01:12:29 -0700 (PDT) In-Reply-To: <5162FD4A.1030909@wwwdotorg.org> References: <515C5C76.3080009@wwwdotorg.org> <5162FD4A.1030909@wwwdotorg.org> From: Prabhakar Lad Date: Wed, 10 Apr 2013 13:42:29 +0530 Message-ID: Subject: Re: Query on pinctrl usage for DT nodes To: Stephen Warren , Peter Ujfalusi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130410_041252_758140_F62448E2 X-CRM114-Status: GOOD ( 22.04 ) X-Spam-Score: -2.7 (--) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-2.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (prabhakar.csengg[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.53 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Tony Lindgren , linus.walleij@linaro.org, Stephen Warren , device-tree , LAK X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org Hi Stephen,Peter, On Mon, Apr 8, 2013 at 10:54 PM, Stephen Warren wrote: > On 04/08/2013 07:12 AM, Prabhakar Lad wrote: >> On Wed, Apr 3, 2013 at 10:14 PM, Stephen Warren wrote: >>> On 04/03/2013 03:16 AM, Prabhakar Lad wrote: >>>> Hi Linus/Stephen, >>>> >>>> I am working adding DT nodes for DA850. > ... >>>> But while booting I see the following boot log:- >>>> ... >>>> cpuidle: using governor menu >>>> TCP: cubic registered >>>> NET: Registered protocol family 17 >>>> pinctrl-single 1c14120.pinmux: pin 1c14130 already requested by >>>> davinci_mdio.0; cannot claim for i2c_davinci.1 >>>> pinctrl-single 1c14120.pinmux: pin-4 (i2c_davinci.1) status -22 >>>> pinctrl-single 1c14120.pinmux: could not request pin 4 on device pinctrl-single >>>> console [netcon0] enabled >>>> .... >>>> >>>> This is because the mdio and i2c are using same pin 0x10, >>> >>> How can two devices use the same pin? I mean physically, in hardware? >>> >>> Is this because pinctrl-single uses the register address as the pin >>> number, whereas you have registers which configure multiple pins at >> >> Yes you are correct, we have registers which configure multiple pins at once. >> For example for above Pin Multiplexing Control 4 Register (Pinmux4) >> [1] page(250) : - >> >> PINMUX4_31_28 --> SP1_SCS[2]/UART1_TXD/SATA_CP_POD/GP1[0] Control >> PINMUX4_27_24 --> SPI1_SCS[3]/UART1_RXD/SATA_LED/GP1[1] Control >> PINMUX4_23_20 --> SPI1_SCS[4]/UART2_TXD/I2C1_SDA/GP1[2] Control >> PINMUX4_19_16 --> SPI1_SCS[5]/UART2_RXD/I2C1_SCL/GP1[3] Control >> PINMUX4_15_12 --> SPI1_SCS[6]/I2C0_SDA/TM64P3_OUT12/GP1[4] Control >> PINMUX4_11_8 --> SPI1_SCS[7]/I2C0_SCL/TM64P2_OUT12/GP1[5] Control >> PINMUX4_7_4 --> SPI0_SCS[0]/TM64P1_OUT12/GP1[6]/MDIO_D/TM64P1_IN12 Control >> PINMUX4_3_0 --> SPI0_SCS[1]/TM64P0_OUT12/GP1[7]/MDIO_CLK/TM64P0_IN12 Control >> >>> once? If so, your hardware isn't something that can be represented by >>> pinctrl-single. >> >> What is the alternative for such case ? any pointer would be helpful. >> >> [1] http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spruh77a&fileType=pdf > > Tony previously replied: > > Tony wrote: >> Tony wrote: >>> ??? wrote: >>>> Prabhakar wrote: >>>>> Is there any >>>>> alternative way to handle if the two node's are using same pins any >>>>> pointers could be very much helpful ? >>> >>> It could also that the mux register(s) follow the one-mux-per-bit >>> mapping. >>> >>> In that case pinctrl-single,bits option as documented in the >>> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt. >> >> Oh it's already using pinctrl-single,bits option. Maybe there's a >> bug, adding Peter to cc. > > So I guess you need to debug the code to see why that option isn't > working for you. > Following is the proposed fix/hack let me know if its OK. Regards, --Prabhakar ->>>>>>>>>>>>>>>>>>> cannot claim for %s\n", desc->name, desc->mux_owner, owner); @@ -118,7 +118,7 @@ static int pin_request(struct pinctrl_dev *pctldev, } desc->mux_usecount++; - if (desc->mux_usecount > 1) + if (desc->mux_usecount > 1 && !pctldev->bits_per_mux) return 0; desc->mux_owner = owner; diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h index ee72f1f..78fb42d 100644 --- a/drivers/pinctrl/core.h +++ b/drivers/pinctrl/core.h @@ -46,6 +46,7 @@ struct pinctrl_dev { struct pinctrl *p; struct pinctrl_state *hog_default; struct pinctrl_state *hog_sleep; + bool bits_per_mux; #ifdef CONFIG_DEBUG_FS struct dentry *device_root; #endif diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index 5c32e88..d2a91ec 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -974,6 +974,7 @@ static int pcs_probe(struct platform_device *pdev) ret = -EINVAL; goto free; } + pcs->pctl->bits_per_mux = pcs->bits_per_mux; dev_info(pcs->dev, "%i pins at pa %p size %u\n", pcs->desc.npins, pcs->base, pcs->size); diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c index 1a00658..4989f01 100644 --- a/drivers/pinctrl/pinmux.c +++ b/drivers/pinctrl/pinmux.c @@ -110,7 +110,7 @@ static int pin_request(struct pinctrl_dev *pctldev, desc->gpio_owner = owner; } else { - if (desc->mux_usecount && strcmp(desc->mux_owner, owner)) { + if (!pctldev->bits_per_mux && desc->mux_usecount && strcmp(desc->mux_owner, owner)) { dev_err(pctldev->dev, "pin %s already requested by %s;