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

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

[sricharan]

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.

[PATCH 1/5] OMAP4: hsmmc: Initialise the mmc mux pins

[sricharan]

Use the mux framework to initialise the mmc mux pins.

Signed-off-by: sricharan <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/devices.c |   83 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 83 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..56b1ac9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -784,6 +784,89 @@ static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
 		 * For MMC3 the pins need to be muxed in the board-*.c files
 		 */
 	}
+
+	if (cpu_is_omap44xx()) {
+		switch (controller_nr) {
+		case 0:
+			/* MMC 1 */
+			omap_mux_init_signal("sdmmc1_clk.sdmmc1_clk",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("sdmmc1_cmd.sdmmc1_cmd",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("sdmmc1_dat0.sdmmc1_dat0",
+						OMAP_PIN_INPUT_PULLUP);
+			if (mmc_controller->slots[0].caps &
+				(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+				omap_mux_init_signal("sdmmc1_dat1.sdmmc1_dat1",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc1_dat2.sdmmc1_dat2",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc1_dat3.sdmmc1_dat3",
+						OMAP_PIN_INPUT_PULLUP);
+			}
+			if (mmc_controller->slots[0].caps &
+						MMC_CAP_8_BIT_DATA) {
+				omap_mux_init_signal("sdmmc1_dat4.sdmmc1_dat4",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc1_dat5.sdmmc1_dat5",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc1_dat6.sdmmc1_dat6",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc1_dat7.sdmmc1_dat7",
+						OMAP_PIN_INPUT_PULLUP);
+			}
+			break;
+		case 1:
+			/* MMC2 */
+			omap_mux_init_signal("gpmc_noe.sdmmc2_clk",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("gpmc_nwe.sdmmc2_cmd",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("gpmc_ad0.sdmmc2_dat0",
+						OMAP_PIN_INPUT_PULLUP);
+			if (mmc_controller->slots[0].caps &
+				(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+				omap_mux_init_signal("gpmc_ad1.sdmmc2_dat1",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("gpmc_ad2.sdmmc2_dat2",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("gpmc_ad3.sdmmc2_dat3",
+						OMAP_PIN_INPUT_PULLUP);
+			}
+			if (mmc_controller->slots[0].caps &
+							MMC_CAP_8_BIT_DATA) {
+				omap_mux_init_signal("gpmc_ad4.sdmmc2_dat4",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("gpmc_ad5.sdmmc2_dat5",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("gpmc_ad6.sdmmc2_dat6",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("gpmc_ad7.sdmmc2_dat7",
+						OMAP_PIN_INPUT_PULLUP);
+			}
+			break;
+		case 4:
+			/* MMC5 only for omap4 */
+			omap_mux_init_signal("sdmmc5_clk.sdmmc5_clk",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("sdmmc5_cmd.sdmmc5_cmd",
+						OMAP_PIN_INPUT_PULLUP);
+			omap_mux_init_signal("sdmmc5_dat0.sdmmc5_dat0",
+						OMAP_PIN_INPUT_PULLUP);
+			if (mmc_controller->slots[0].caps &
+				MMC_CAP_4_BIT_DATA) {
+				omap_mux_init_signal("sdmmc5_dat1.sdmmc5_dat1",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc5_dat2.sdmmc5_dat2",
+						OMAP_PIN_INPUT_PULLUP);
+				omap_mux_init_signal("sdmmc5_dat3.sdmmc5_dat3",
+						OMAP_PIN_INPUT_PULLUP);
+			}
+			break;
+		default:
+			break;
+		}
+	}
 }
 
 void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
-- 
1.7.0.4

Re: [PATCH 1/5] OMAP4: hsmmc: Initialise the mmc mux pins

[Tony Lindgren]

* sricharan <r.sricharan@ti.com> [101114 23:26]:
> Use the mux framework to initialise the mmc mux pins.
> 
> Signed-off-by: sricharan <r.sricharan@ti.com>
> ---
>  arch/arm/mach-omap2/devices.c |   83 +++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 83 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index eaf3799..56b1ac9 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -784,6 +784,89 @@ static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
>  		 * For MMC3 the pins need to be muxed in the board-*.c files
>  		 */
>  	}
> +
> +	if (cpu_is_omap44xx()) {
> +		switch (controller_nr) {
> +		case 0:
> +			/* MMC 1 */
> +			omap_mux_init_signal("sdmmc1_clk.sdmmc1_clk",
> +						OMAP_PIN_INPUT_PULLUP);
> +			omap_mux_init_signal("sdmmc1_cmd.sdmmc1_cmd",
> +						OMAP_PIN_INPUT_PULLUP);
> +			omap_mux_init_signal("sdmmc1_dat0.sdmmc1_dat0",
> +						OMAP_PIN_INPUT_PULLUP);
> +			if (mmc_controller->slots[0].caps &
> +				(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
> +				omap_mux_init_signal("sdmmc1_dat1.sdmmc1_dat1",
> +						OMAP_PIN_INPUT_PULLUP);
> +				omap_mux_init_signal("sdmmc1_dat2.sdmmc1_dat2",
> +						OMAP_PIN_INPUT_PULLUP);
> +				omap_mux_init_signal("sdmmc1_dat3.sdmmc1_dat3",
> +						OMAP_PIN_INPUT_PULLUP);
> +			}

This does not solve the selected pins issue. For example, you don't know
if it's sdmmc1_dat1.sdmmc1_dat1 or gpmc_ad9.sdmmc_dat1. That selection
is board specific.

So you either have to pass the selected pins from the board-*.c file,
or do the muxing in board-*.c file. It depends on the the case.

How about take a look at specifying the pin names in board-*.c in
struct omap_mmc_platform_data?

Regards,

Tony

[PATCH 2/5] OMAP4: usb-musb: Initialise the usb mux pins.

[sricharan]

Use the mux framework to initialise the musb mux pins.

Signed-off-by: sricharan <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |   41 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 33a5cde..27cb348 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -29,6 +29,7 @@
 #include <mach/hardware.h>
 #include <mach/irqs.h>
 #include <plat/usb.h>
+#include "mux.h"
 
 #ifdef CONFIG_USB_MUSB_SOC
 
@@ -85,6 +86,44 @@ static struct platform_device musb_device = {
 	.resource	= musb_resources,
 };
 
+static void __init usb_musb_mux_init(struct omap_musb_board_data *board_data)
+{
+	if (board_data->interface_type == MUSB_INTERFACE_UTMI) {
+		/* MUSB - UTMI PIN MUX configurations */
+		omap_mux_init_signal("usba0_otg_ce.usba0_otg_ce",
+						OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("usba0_otg_dp.usba0_otg_dp",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usba0_otg_dm.usba0_otg_dm",
+						OMAP_PIN_INPUT);
+	} else {
+		/* MUSB - ULPI PIN MUX configurations */
+		omap_mux_init_signal("usbb1_ulpitll_clk.usbb1_ulpiphy_clk",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_stp.usbb1_ulpiphy_stp",
+						OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dir.usbb1_ulpiphy_dir",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6",
+						OMAP_PIN_INPUT);
+		omap_mux_init_signal("usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7",
+						OMAP_PIN_INPUT);
+	}
+}
 void __init usb_musb_init(struct omap_musb_board_data *board_data)
 {
 	if (cpu_is_omap243x()) {
@@ -95,6 +134,8 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data)
 		musb_resources[0].start = OMAP44XX_HSUSB_OTG_BASE;
 		musb_resources[1].start = OMAP44XX_IRQ_HS_USB_MC_N;
 		musb_resources[2].start = OMAP44XX_IRQ_HS_USB_DMA_N;
+
+		usb_musb_mux_init(board_data);
 	}
 	musb_resources[0].end = musb_resources[0].start + SZ_4K - 1;
 
-- 
1.7.0.4

[PATCH 3/5] OMAP4: mcbsp: Initialise the mcbsp mux pins

[sricharan]

Use the mux framework to initialise the mcbsp mux pins

Signed-off-by: sricharan <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/mcbsp.c |   33 ++++++++++++++++++++++++++++++++-
 1 files changed, 32 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index f9c9df5..491e3f6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -25,6 +25,7 @@
 
 #include "control.h"
 
+#include "mux.h"
 
 /* McBSP internal signal muxing functions */
 
@@ -287,9 +288,39 @@ static int __init omap2_mcbsp_init(void)
 	if (cpu_is_omap34xx())
 		omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
 						OMAP34XX_MCBSP_PDATA_SZ);
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		omap_mcbsp_register_board_cfg(omap44xx_mcbsp_pdata,
 						OMAP44XX_MCBSP_PDATA_SZ);
+		/* MCBSP1 PIN MUX configurations */
+		omap_mux_init_signal("abe_mcbsp1_clkx.abe_slimbus1_clock",
+							OMAP_PIN_INPUT);
+		omap_mux_init_signal("abe_mcbsp1_dr.abe_slimbus1_data",
+							OMAP_PIN_INPUT);
+		omap_mux_init_signal("abe_mcbsp1_dx.abe_mcbsp1_dx",
+							OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("abe_mcbsp1_fsx.abe_mcbsp1_fsx",
+							OMAP_PIN_INPUT);
+
+		/* MCBSP2 PIN MUX configurations */
+		omap_mux_init_signal("abe_mcbsp2_clkx.abe_mcbsp2_clkx",
+							OMAP_PIN_INPUT);
+		omap_mux_init_signal("abe_mcbsp2_dr.abe_mcbsp2_dr",
+							OMAP_PIN_INPUT);
+		omap_mux_init_signal("abe_mcbsp2_dx.abe_mcbsp2_dx",
+							OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("abe_mcbsp2_fsx.abe_mcbsp2_fsx",
+							OMAP_PIN_INPUT);
+
+		/* MCBSP 3 is configured as MCPDM */
+		omap_mux_init_signal("abe_pdm_ul_data.abe_pdm_ul_data",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("abe_pdm_dl_data.abe_pdm_dl_data",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("abe_pdm_frame.abe_pdm_frame",
+						OMAP_PIN_INPUT_PULLUP);
+		omap_mux_init_signal("abe_pdm_lb_clk.abe_pdm_lb_clk",
+						OMAP_PIN_INPUT_PULLDOWN);
+	}
 
 	return omap_mcbsp_init();
 }
-- 
1.7.0.4

[PATCH 4/5] OMAP4: board-4430sdp: Initialise the mcspi mux pins

[sricharan]

Use the mux framework to initialise the mcspi mux pins.

Signed-off-by: sricharan <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 323b62e..c0ffea1 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -501,6 +501,25 @@ static void __init omap_sfh7741prox_init(void)
 	}
 }
 
+static void __init omap_mcspi_mux_init(void)
+{
+	/* PIN MUX for MCSPI1 */
+	omap_mux_init_signal("mcspi1_clk.mcspi1_clk", OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi1_somi.mcspi1_somi",	OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi1_simo.mcspi1_simo",	OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi1_cs0.mcspi1_cs0", OMAP_PIN_INPUT);
+	/*
+	 * CS1 should be configured as gpio 138
+	 * to avoid interference with CS0
+	 */
+	omap_mux_init_signal("mcspi1_cs1.gpio_138", OMAP_PIN_INPUT);
+
+	/* PIN MUX for MCSPI4. This is not connected to any device */
+	omap_mux_init_signal("mcspi4_clk.mcspi4_clk", OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi4_somi.mcspi4_somi",	OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi4_simo.mcspi4_simo",	OMAP_PIN_INPUT);
+	omap_mux_init_signal("mcspi4_cs0.mcspi4_cs0", OMAP_PIN_INPUT_PULLDOWN);
+}
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
@@ -529,6 +548,7 @@ static void __init omap_4430sdp_init(void)
 	if (!cpu_is_omap44xx())
 		usb_musb_init(&musb_board_data);
 
+	omap_mcspi_mux_init();
 	status = omap_ethernet_init();
 	if (status) {
 		pr_err("Ethernet initialization failed: %d\n", status);
-- 
1.7.0.4

[PATCH 5/5] OMAP4: serial: Initialise the uart mux pins

[sricharan]

Use the mux framework to initialise the uart mux pins.

Signed-off-by: sricharan <r.sricharan@ti.com>
---
 arch/arm/mach-omap2/serial.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index ba8a5cc..6890054 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -44,6 +44,7 @@
 #include "cm.h"
 #include "prm-regbits-34xx.h"
 #include "control.h"
+#include "mux.h"
 
 #define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV	0x52
 #define UART_OMAP_WER		0x17	/* Wake-up enable register */
@@ -839,6 +840,41 @@ void __init omap_serial_init_port(int port)
 		uart->errata |= UART_ERRATA_i202_MDR1_ACCESS;
 }
 
+/*
+ * omap_serial_init_mux() - Initialize the PINMUX configurations
+ * for all supported UART modules.
+ */
+static void __init omap_serial_init_mux(void)
+{
+	if (cpu_is_omap44xx()) {
+		/* UART 2 MUX */
+		omap_mux_init_signal("uart2_cts.uart2_cts",
+					OMAP_PIN_INPUT_PULLUP);
+		omap_mux_init_signal("uart2_rts.uart2_rts",
+					OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("uart2_rx.uart2_rx",
+					OMAP_PIN_INPUT_PULLUP);
+		omap_mux_init_signal("uart2_tx.uart2_tx",
+					OMAP_PIN_OUTPUT);
+
+		/* UART 3 MUX */
+		omap_mux_init_signal("uart3_cts_rctx.uart3_cts_rctx",
+					OMAP_PIN_INPUT_PULLUP);
+		omap_mux_init_signal("uart3_rts_sd.uart3_rts_sd",
+					OMAP_PIN_OUTPUT);
+		omap_mux_init_signal("uart3_rx_irrx.uart3_rx_irrx",
+					OMAP_PIN_INPUT);
+		omap_mux_init_signal("uart3_tx_irtx.uart3_tx_irtx",
+					OMAP_PIN_OUTPUT);
+
+		/* UART 4 MUX */
+		omap_mux_init_signal("uart4_rx.uart4_rx",
+					OMAP_PIN_INPUT);
+		omap_mux_init_signal("uart4_tx.uart4_tx",
+					OMAP_PIN_OUTPUT);
+	}
+}
+
 /**
  * omap_serial_init() - intialize all supported serial ports
  *
@@ -850,6 +886,8 @@ void __init omap_serial_init(void)
 {
 	struct omap_uart_state *uart;
 
+	omap_serial_init_mux();
+
 	list_for_each_entry(uart, &uart_list, node)
 		omap_serial_init_port(uart->num);
 }
-- 
1.7.0.4

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

[Cousson, Benoit]

Hi Sricharan,

On 11/15/2010 8:38 AM, R, Sricharan wrote:
> 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

I've just realized that this is not the latest one, here it is:
http://www.spinics.net/lists/linux-omap/msg40039.html

Regards,
Benoit

>
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Tony Lindgren]

* sricharan <r.sricharan@ti.com> [101114 23:26]:
> 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.

<snip>
 
> 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.

For the common modules, we should have generic platform init code
using hwmod. And that init code is the logical place to do the muxing.

We also need to consider that the pin muxing is board specific.
So in cases where the are alternative signal paths, we need to pass
the signal names from board-*.c file to the platform driver init code.

Regards,

Tony

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

[Cousson, Benoit]

On 11/18/2010 8:06 PM, Tony Lindgren wrote:
> * sricharan<r.sricharan@ti.com>  [101114 23:26]:
>> 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.
>
> <snip>
>
>> 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.
>
> For the common modules, we should have generic platform init code
> using hwmod. And that init code is the logical place to do the muxing.
>
> We also need to consider that the pin muxing is board specific.
> So in cases where the are alternative signal paths, we need to pass
> the signal names from board-*.c file to the platform driver init code.

What about the omap_board_mux array in board file? Do you want to get 
rid of it, or is the plan is to use that for pads that does not belong 
to any driver or pads that are purely board specific?

Regards,
Benoit

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

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [101118 12:56]:
> On 11/18/2010 8:06 PM, Tony Lindgren wrote:
> >* sricharan<r.sricharan@ti.com>  [101114 23:26]:
> >>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.
> >
> ><snip>
> >
> >>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.
> >
> >For the common modules, we should have generic platform init code
> >using hwmod. And that init code is the logical place to do the muxing.
> >
> >We also need to consider that the pin muxing is board specific.
> >So in cases where the are alternative signal paths, we need to pass
> >the signal names from board-*.c file to the platform driver init code.
> 
> What about the omap_board_mux array in board file? Do you want to
> get rid of it, or is the plan is to use that for pads that does not
> belong to any driver or pads that are purely board specific?

Well we might as well keep it around for now as that's the way
some people prefer to do the muxing. But yeah, eventually that
could be for only board specific unused pads.

I'll post some sample patches related to the uart (re)muxing
within next few days, then let's see how that will work for
other devices.

Here's the rough plan in case you have some ideas on it:

1. board-*.c code calls omap_serial_init_port with struct omap_device_mux
   array that contains the pin names

2. serial.c init code muxes the pins the right way and sets
   wake-up events for omap3 & 4. It also populates the runtime
   remux values needed for omap2 uart

3. serial.c init code saves the struct omap_device_mux pointer
   to the related hwmod entry

4. omap_device_idle/shutdown can then call omap_remux if the
   omap_device_mux entry exists
   ...

This should solve how devices need to initialize the pads.
It should also work for all devices that may require runtime
remuxing, like some USB transceivers and eMMC.

Regards,

Tony

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

[R, Sricharan]

>-----Original Message-----
>From: Tony Lindgren [mailto:tony@atomide.com]
>Sent: Friday, November 19, 2010 2:56 AM
>To: Cousson, Benoit
>Cc: R, Sricharan; linux-omap@vger.kernel.org
>Subject: Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
>
>* Cousson, Benoit <b-cousson@ti.com> [101118 12:56]:
>> On 11/18/2010 8:06 PM, Tony Lindgren wrote:
>> >* sricharan<r.sricharan@ti.com>  [101114 23:26]:
>> >>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.
>> >
>> ><snip>
>> >
>> >>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.
>> >
>> >For the common modules, we should have generic platform init code
>> >using hwmod. And that init code is the logical place to do the muxing.
>> >
>> >We also need to consider that the pin muxing is board specific.
>> >So in cases where the are alternative signal paths, we need to pass
>> >the signal names from board-*.c file to the platform driver init code.
>>
>> What about the omap_board_mux array in board file? Do you want to
>> get rid of it, or is the plan is to use that for pads that does not
>> belong to any driver or pads that are purely board specific?
>
>Well we might as well keep it around for now as that's the way
>some people prefer to do the muxing. But yeah, eventually that
>could be for only board specific unused pads.
>
>I'll post some sample patches related to the uart (re)muxing
>within next few days, then let's see how that will work for
>other devices.
>
>Here's the rough plan in case you have some ideas on it:
>
>1. board-*.c code calls omap_serial_init_port with struct omap_device_mux
>   array that contains the pin names
>
>2. serial.c init code muxes the pins the right way and sets
>   wake-up events for omap3 & 4. It also populates the runtime
>   remux values needed for omap2 uart
>
>3. serial.c init code saves the struct omap_device_mux pointer
>   to the related hwmod entry
>
>4. omap_device_idle/shutdown can then call omap_remux if the
>   omap_device_mux entry exists
>   ...
>
>This should solve how devices need to initialize the pads.
>It should also work for all devices that may require runtime
>remuxing, like some USB transceivers and eMMC.


Ok . This means that the pin muxing introduced
 would be applicable for omap 2 ,3 and 4 also, with the
board file passing the respective data if they are different ?


>Regards,
>
>Tony

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

[Tony Lindgren]

* R, Sricharan <r.sricharan@ti.com> [101119 00:39]:
> 
> Ok . This means that the pin muxing introduced
>  would be applicable for omap 2 ,3 and 4 also, with the
> board file passing the respective data if they are different ?

Well the pin configuration stays board specific, but the code
to set the pads is same for all omap2/3/4.

Even if the signal names stay the same, the pad configuration
register value may be different if external pulls are used
instead of the internal ones.

Regards,

Tony

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

[R, Sricharan]

Adding people in CC.

>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/msg40039.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.