From patchwork Thu Jul 7 06:40:37 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: saeed bishara X-Patchwork-Id: 952192 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p676eqbs020001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Jul 2011 06:41:13 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QeiGS-0006gv-SP; Thu, 07 Jul 2011 06:40:45 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QeiGS-0005hk-Gl; Thu, 07 Jul 2011 06:40:44 +0000 Received: from mail-iw0-f177.google.com ([209.85.214.177]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QeiGO-0005hR-5g for linux-arm-kernel@lists.infradead.org; Thu, 07 Jul 2011 06:40:42 +0000 Received: by iwn35 with SMTP id 35so685721iwn.36 for ; Wed, 06 Jul 2011 23:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ncm5+rP1R6v5hXyuw9wq+5OhPIyR4mvGETSK2IB/GnE=; b=wNve5MOCWC503bVDK6zHW1c6ltsRoWuzYODxL4KVn7018b2UMe0q5azWojRVy39LKY kOKfYNgg50IypKGdRPg2Ud9dfcwFrAQjsVqfcgqA/KeFii80F1H7T2worDlFST0v18h7 2q9++HOqFb87rFdX/Lgcrz3IX8l+Xv817XyZQ= MIME-Version: 1.0 Received: by 10.231.14.13 with SMTP id e13mr400585iba.186.1310020837961; Wed, 06 Jul 2011 23:40:37 -0700 (PDT) Received: by 10.231.19.196 with HTTP; Wed, 6 Jul 2011 23:40:37 -0700 (PDT) In-Reply-To: <4E14AE51.5070003@drewtech.com> References: <4E0E1CA8.7090200@drewtech.com> <20110702122344.GJ31228@kw.sim.vm.gnt> <4E132FD5.1090409@drewtech.com> <20110706161823.GB22857@kw.sim.vm.gnt> <4E14AE51.5070003@drewtech.com> Date: Thu, 7 Jul 2011 09:40:37 +0300 Message-ID: Subject: Re: plat-orion multi purpose pins problem for mv78200 From: saeed bishara To: Joey Oravec X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110707_024040_475473_4DFF1586 X-CRM114-Status: GOOD ( 16.49 ) X-Spam-Score: -0.8 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (saeed.bishara[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.214.177 listed in list.dnswl.org] -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: nico@fluxnic.net, Simon Guinot , saeed@marvell.com, linux-arm-kernel@lists.infradead.org, kernel@wantstofly.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Thu, 07 Jul 2011 06:41:13 +0000 (UTC) On Wed, Jul 6, 2011 at 9:49 PM, Joey Oravec wrote: > On 7/6/2011 12:18 PM, Simon Guinot wrote: >>> >>> Note that orion_gpio_set_valid() and orion_gpio_is_valid() would >>> both need rework. The functions need to handle that a GPIO can be >>> mux'ed onto any MPP pin. I described this problem in another email >>> on the thread. >> >> I don't understand what's wrong with the GPIO array. > > I tried to describe the case in my reply: > http://lists.arm.linux.org.uk/lurker/message/20110701.215657.7efe0a42.en.html > > Assume that we've solved the mpp_to_gpio mapping. Then imagine you pass a > large array to mv78xx0_mpp_conf() that includes: > > MPP16_GPIO (this mpp corresponds to GPIO16) > MPP47_UNUSED (this mpp corresponds to GPIO16) > > The code today processes the array in-order. When it processes MPP16_GPIO it > will mark the GPIO16 valid. When it processes MPP47_UNUSED it would > currently mark GPIO16 invalid. This is a problem because it still assumes a > 1:1 relationship. I agree, this is why we need some method to make the orion_mpp_conf() know which mpps are gpios, when that done, then the gpio of MPP47 in your case will not be set as invalid. one option to do that is to assume that mpp with _in == out_ == 0 is not a gpio. so the orion_mpp_conf() will look like this: if (num > mpp_max) { @@ -64,9 +65,8 @@ void __init orion_mpp_conf(unsigned int *mpp_list, unsigned int variant_mask, gpio_mode |= GPIO_INPUT_OK; if (*mpp_list & MPP_OUTPUT_MASK) gpio_mode |= GPIO_OUTPUT_OK; - if (sel != 0) - gpio_mode = 0; - orion_gpio_set_valid(num, gpio_mode); + if (gpio_mode != 0) + orion_gpio_set_valid(gpio_num, gpio_mode); } and of course this will require that any non gpio mpp will have to have the _in and _out set to 0. saeed --- a/arch/arm/plat-orion/mpp.c +++ b/arch/arm/plat-orion/mpp.c @@ -41,6 +41,7 @@ void __init orion_mpp_conf(unsigned int *mpp_list, unsigned int variant_mask, for ( ; *mpp_list; mpp_list++) { unsigned int num = MPP_NUM(*mpp_list); unsigned int sel = MPP_SEL(*mpp_list); + unsigned int gpio_num = MPP_GPIO(*mpp_list); int shift, gpio_mode;