On Mon, 2009-03-02 at 08:40 -0800, Tony Lindgren wrote: > * Kim Kyuwon <chammoru@xxxxxxxxx> [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 <peterb@xxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
