* Peter Barada <peterb@xxxxxxxxxxx> [090302 09:31]: > 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. Well for omap3 and later, we should probably just switch to defining the pin registers, then pass the desired value to the function. The current mux code is unnecessary complicated for current hardware. It works for omap1 where the mux registers need to be changed at several locations. Regards, Tony -- 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
