From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Barada Subject: Re: Suggestion regarding the ordering of GPIO MUX configurations Date: Mon, 02 Mar 2009 12:31:39 -0500 Message-ID: <1236015099.15937.79.camel@blackhole> References: <4d34a0a70903011837k2a1467b5s9c3b56e065d4b5c8@mail.gmail.com> <20090302164008.GA11864@atomide.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mail.logicpd.com ([66.162.60.3]:5772 "EHLO smtp.logicpd.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754935AbZCBRbn (ORCPT ); Mon, 2 Mar 2009 12:31:43 -0500 In-Reply-To: <20090302164008.GA11864@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Kim Kyuwon , OMAP , David Brownell On Mon, 2009-03-02 at 08:40 -0800, Tony Lindgren wrote: > * Kim Kyuwon [090301 18:37]: > > Hi All. > > > > The current order of GPIO mux configurations is not sorted. It seems > > that all new GPIO MUX configurations are being inserted to the end as > > shown in next code > > > > /* arch/arm/plat-omap/include/mach/mux.h */ > > 791 AH8_34XX_GPIO29, > > 792 J25_34XX_GPIO170, > > 793 AF26_34XX_GPIO0, > > 794 AF22_34XX_GPIO9, > > 795 L8_34XX_GPIO63, > > 796 AF6_34XX_GPIO140_UP, > > 797 AE6_34XX_GPIO141, > > 798 AF5_34XX_GPIO142, > > 799 AE5_34XX_GPIO143, > > 800 AG4_34XX_GPIO134, > > 801 U8_34XX_GPIO54, > > 802 AE4_34XX_GPIO136, > > > > > > I wonder if we can sort the order of GPIO MUX configurations and then > > insert new MUXs at right position. Can I ask your opinions? > > Yes, I was thinking about the same. I'll combine the pending mux patches > and merge them into a single patch for mainline tree. While doing that > I'll sort them by gpio number. Will post the patch here for testing > probably today. Thinking about this, I wonder if it would be better to remove the enum entirely and just pass the pin name (as a string) to omap_cfg_reg() and have it search the table for a matching entry. 1) This removes the necessary lockstep ordering in the enum and the pinmux table - hence grouping pins by use/name/gpio number is easy. 2) allows for an optional mux table for each machine as part of the initialization to override arch/arm/mach-omap2/mux.c definitions (think of using external versus internal pullup/down registers) as well as extend the mux table for that board(per-board GPIO pin mux definitions). 3) Setting up the pinmux is something that is done at startup, or rarely changed afterwards - as far as I can see, its not time-critical. Just a thought. -- Peter Barada