Re: Suggestion regarding the ordering of GPIO MUX configurations

[Peter Barada <peterb@logicpd.com>]

On Mon, 2009-03-02 at 08:40 -0800, Tony Lindgren wrote:
> * Kim Kyuwon <chammoru@gmail.com> [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@logicpd.com>