[PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.

[sricharan <r.sricharan@ti.com>]

This series updates the core device drivers to use mux framework
for OMAP4 SDP and PANDA board. It's generated against the
linux-omap master branch. It has a dependency on the Benoit's
omap4 mux data series.
	
	http://www.spinics.net/lists/linux-omap/msg38995.html

sricharan (5):
  OMAP4: hsmmc: Initialise the mmc mux pins
  OMAP4: usb-musb: Initialise the usb mux pins.
  OMAP4: mcbsp: Initialise the mcbsp mux pins
  OMAP4: board-4430sdp: Initialise the mcspi mux pins
  OMAP4: serial: Initialise the uart mux pins

 arch/arm/mach-omap2/board-4430sdp.c |   20 ++++++++
 arch/arm/mach-omap2/devices.c       |   83 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/mcbsp.c         |   33 +++++++++++++-
 arch/arm/mach-omap2/serial.c        |   38 ++++++++++++++++
 arch/arm/mach-omap2/usb-musb.c      |   41 +++++++++++++++++
 5 files changed, 214 insertions(+), 1 deletions(-)

While doing some internal reviews, there were few debates about existing
mux framework usage. I am summarising that discussion here and would 
like to hear more on this from the community.

1. PAD configuration for all pins should be done in a central place(board file)
Pros:
	a. All pins configured in a central place. Easy to ensure coverage
	   and maintenance. Single place to look for all mux related settings
	b. Drivers, unless they have run time pad configuration requirements
	   need not worry about muxing.
Cons: 
	a. Adds a lot of duplicate data in different board files assuming
	   most of the pins will be connected the same way across different
	   boards.

2. Do PAD configuration independently for each module
Pros:
	a. Avoids repetition of similar data for different boards.
	b. Gives a knowledge of how pins are configured for a module
	   to the respective owners.
	c. Pads are not initialised unless they are really needed.
Cons:
	a. Can become difficult to maintain if lot of data tend to be 
	   different across boards.