All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] OMAP3: MMC: Add mux for pins
@ 2009-06-12 22:41 Vikram Pandita
  2009-06-15  8:12 ` Tony Lindgren
  0 siblings, 1 reply; 18+ messages in thread
From: Vikram Pandita @ 2009-06-12 22:41 UTC (permalink / raw)
  To: linux-omap; +Cc: Vikram Pandita, Chikkature Rajashekar

For OMAP3 add MMC1 MMC2 and MMC3 pin mux

Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
---
 arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
 arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++++++++++++
 arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
 3 files changed, 110 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 894cc35..f86cb1f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -513,6 +513,39 @@ static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
 			omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
 		}
 	}
+
+	if (cpu_is_omap3430()) {
+		if (controller_nr == 0) {
+			omap_cfg_reg(N28_3430_MMC1_CLK);
+			omap_cfg_reg(M27_3430_MMC1_CMD);
+			omap_cfg_reg(N27_3430_MMC1_DAT0);
+			omap_cfg_reg(N26_3430_MMC1_DAT1);
+			omap_cfg_reg(N25_3430_MMC1_DAT2);
+			omap_cfg_reg(P28_3430_MMC1_DAT3);
+			omap_cfg_reg(P27_3430_MMC1_DAT4);
+			omap_cfg_reg(P26_3430_MMC1_DAT5);
+			omap_cfg_reg(R27_3430_MMC1_DAT6);
+			omap_cfg_reg(R25_3430_MMC1_DAT7);
+		}
+		if (controller_nr == 1) {
+			/* MMC2 */
+			omap_cfg_reg(AE2_3430_MMC2_CLK);
+			omap_cfg_reg(AG5_3430_MMC2_CMD);
+			omap_cfg_reg(AH5_3430_MMC2_DAT0);
+			omap_cfg_reg(AH4_3430_MMC2_DAT1);
+			omap_cfg_reg(AG4_3430_MMC2_DAT2);
+			omap_cfg_reg(AF4_3430_MMC2_DAT3);
+		}
+		if (controller_nr == 2) {
+			/* MMC3 */
+			omap_cfg_reg(AF10_3430_MMC3_CLK);
+			omap_cfg_reg(AC3_3430_MMC3_CMD);
+			omap_cfg_reg(AE11_3430_MMC3_DAT0);
+			omap_cfg_reg(AH9_3430_MMC3_DAT1);
+			omap_cfg_reg(AF13_3430_MMC3_DAT2);
+			omap_cfg_reg(AF13_3430_MMC3_DAT3);
+		}
+	}
 }
 
 void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 026c4fc..d49b9a7 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
 MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+/* MMC1 */
+MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+
+/* MMC2 */
+MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
+		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
+
+/* MMC3 */
+MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
+		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
 };
 
 #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-omap/include/mach/mux.h
index 85a6217..d24fdf9 100644
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -853,6 +853,34 @@ enum omap34xx_index {
 	AE5_34XX_GPIO143,
 	H19_34XX_GPIO164_OUT,
 	J25_34XX_GPIO170,
+
+	/* MMC1 */
+	N28_3430_MMC1_CLK,
+	M27_3430_MMC1_CMD,
+	N27_3430_MMC1_DAT0,
+	N26_3430_MMC1_DAT1,
+	N25_3430_MMC1_DAT2,
+	P28_3430_MMC1_DAT3,
+	P27_3430_MMC1_DAT4,
+	P26_3430_MMC1_DAT5,
+	R27_3430_MMC1_DAT6,
+	R25_3430_MMC1_DAT7,
+
+	/* MMC2 */
+	AE2_3430_MMC2_CLK,
+	AG5_3430_MMC2_CMD,
+	AH5_3430_MMC2_DAT0,
+	AH4_3430_MMC2_DAT1,
+	AG4_3430_MMC2_DAT2,
+	AF4_3430_MMC2_DAT3,
+
+	/* MMC3 */
+	AF10_3430_MMC3_CLK,
+	AC3_3430_MMC3_CMD,
+	AE11_3430_MMC3_DAT0,
+	AH9_3430_MMC3_DAT1,
+	AF13_3430_MMC3_DAT2,
+	AF13_3430_MMC3_DAT3,
 };
 
 struct omap_mux_cfg {
-- 
1.6.0.3.613.g9f8f13


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-12 22:41 [PATCH] OMAP3: MMC: Add mux for pins Vikram Pandita
@ 2009-06-15  8:12 ` Tony Lindgren
  2009-06-15 10:44   ` Hugo Vincent
  0 siblings, 1 reply; 18+ messages in thread
From: Tony Lindgren @ 2009-06-15  8:12 UTC (permalink / raw)
  To: Vikram Pandita; +Cc: linux-omap, Chikkature Rajashekar

* Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
> 
> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> ---
>  arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>  arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++++++++++++
>  arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>  3 files changed, 110 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 894cc35..f86cb1f 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -513,6 +513,39 @@ static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
>  			omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
>  		}
>  	}
> +
> +	if (cpu_is_omap3430()) {
> +		if (controller_nr == 0) {
> +			omap_cfg_reg(N28_3430_MMC1_CLK);
> +			omap_cfg_reg(M27_3430_MMC1_CMD);
> +			omap_cfg_reg(N27_3430_MMC1_DAT0);
> +			omap_cfg_reg(N26_3430_MMC1_DAT1);
> +			omap_cfg_reg(N25_3430_MMC1_DAT2);
> +			omap_cfg_reg(P28_3430_MMC1_DAT3);
> +			omap_cfg_reg(P27_3430_MMC1_DAT4);
> +			omap_cfg_reg(P26_3430_MMC1_DAT5);
> +			omap_cfg_reg(R27_3430_MMC1_DAT6);
> +			omap_cfg_reg(R25_3430_MMC1_DAT7);
> +		}
> +		if (controller_nr == 1) {
> +			/* MMC2 */
> +			omap_cfg_reg(AE2_3430_MMC2_CLK);
> +			omap_cfg_reg(AG5_3430_MMC2_CMD);
> +			omap_cfg_reg(AH5_3430_MMC2_DAT0);
> +			omap_cfg_reg(AH4_3430_MMC2_DAT1);
> +			omap_cfg_reg(AG4_3430_MMC2_DAT2);
> +			omap_cfg_reg(AF4_3430_MMC2_DAT3);
> +		}
> +		if (controller_nr == 2) {
> +			/* MMC3 */
> +			omap_cfg_reg(AF10_3430_MMC3_CLK);
> +			omap_cfg_reg(AC3_3430_MMC3_CMD);
> +			omap_cfg_reg(AE11_3430_MMC3_DAT0);
> +			omap_cfg_reg(AH9_3430_MMC3_DAT1);
> +			omap_cfg_reg(AF13_3430_MMC3_DAT2);
> +			omap_cfg_reg(AF13_3430_MMC3_DAT3);
> +		}
> +	}
>  }

Great, just one issue: All data pins may not be connected, so you
need to look at wires in struct omap_mmc_slot_data to see how many
data pins to mux.

Regards,

Tony

  
>  void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 026c4fc..d49b9a7 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
>  		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>  MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>  		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
> +/* MMC1 */
> +MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +
> +/* MMC2 */
> +MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
> +
> +/* MMC3 */
> +MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
> +		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> +MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>  };
>  
>  #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-omap/include/mach/mux.h
> index 85a6217..d24fdf9 100644
> --- a/arch/arm/plat-omap/include/mach/mux.h
> +++ b/arch/arm/plat-omap/include/mach/mux.h
> @@ -853,6 +853,34 @@ enum omap34xx_index {
>  	AE5_34XX_GPIO143,
>  	H19_34XX_GPIO164_OUT,
>  	J25_34XX_GPIO170,
> +
> +	/* MMC1 */
> +	N28_3430_MMC1_CLK,
> +	M27_3430_MMC1_CMD,
> +	N27_3430_MMC1_DAT0,
> +	N26_3430_MMC1_DAT1,
> +	N25_3430_MMC1_DAT2,
> +	P28_3430_MMC1_DAT3,
> +	P27_3430_MMC1_DAT4,
> +	P26_3430_MMC1_DAT5,
> +	R27_3430_MMC1_DAT6,
> +	R25_3430_MMC1_DAT7,
> +
> +	/* MMC2 */
> +	AE2_3430_MMC2_CLK,
> +	AG5_3430_MMC2_CMD,
> +	AH5_3430_MMC2_DAT0,
> +	AH4_3430_MMC2_DAT1,
> +	AG4_3430_MMC2_DAT2,
> +	AF4_3430_MMC2_DAT3,
> +
> +	/* MMC3 */
> +	AF10_3430_MMC3_CLK,
> +	AC3_3430_MMC3_CMD,
> +	AE11_3430_MMC3_DAT0,
> +	AH9_3430_MMC3_DAT1,
> +	AF13_3430_MMC3_DAT2,
> +	AF13_3430_MMC3_DAT3,
>  };
>  
>  struct omap_mux_cfg {
> -- 
> 1.6.0.3.613.g9f8f13
> 
> --
> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-15  8:12 ` Tony Lindgren
@ 2009-06-15 10:44   ` Hugo Vincent
  2009-06-15 11:04     ` Tony Lindgren
  0 siblings, 1 reply; 18+ messages in thread
From: Hugo Vincent @ 2009-06-15 10:44 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: Vikram Pandita, linux-omap, Chikkature Rajashekar


On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:

> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>
>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>> ---
>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++ 
>> ++++++++++
>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>> 3 files changed, 110 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/ 
>> devices.c
>> index 894cc35..f86cb1f 100644
>> --- a/arch/arm/mach-omap2/devices.c
>> +++ b/arch/arm/mach-omap2/devices.c
>> @@ -513,6 +513,39 @@ static inline void omap2_mmc_mux(struct  
>> omap_mmc_platform_data *mmc_controller,
>> 			omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
>> 		}
>> 	}
>> +
>> +	if (cpu_is_omap3430()) {
>> +		if (controller_nr == 0) {
>> +			omap_cfg_reg(N28_3430_MMC1_CLK);
>> +			omap_cfg_reg(M27_3430_MMC1_CMD);
>> +			omap_cfg_reg(N27_3430_MMC1_DAT0);
>> +			omap_cfg_reg(N26_3430_MMC1_DAT1);
>> +			omap_cfg_reg(N25_3430_MMC1_DAT2);
>> +			omap_cfg_reg(P28_3430_MMC1_DAT3);
>> +			omap_cfg_reg(P27_3430_MMC1_DAT4);
>> +			omap_cfg_reg(P26_3430_MMC1_DAT5);
>> +			omap_cfg_reg(R27_3430_MMC1_DAT6);
>> +			omap_cfg_reg(R25_3430_MMC1_DAT7);
>> +		}
>> +		if (controller_nr == 1) {
>> +			/* MMC2 */
>> +			omap_cfg_reg(AE2_3430_MMC2_CLK);
>> +			omap_cfg_reg(AG5_3430_MMC2_CMD);
>> +			omap_cfg_reg(AH5_3430_MMC2_DAT0);
>> +			omap_cfg_reg(AH4_3430_MMC2_DAT1);
>> +			omap_cfg_reg(AG4_3430_MMC2_DAT2);
>> +			omap_cfg_reg(AF4_3430_MMC2_DAT3);
>> +		}
>> +		if (controller_nr == 2) {
>> +			/* MMC3 */
>> +			omap_cfg_reg(AF10_3430_MMC3_CLK);
>> +			omap_cfg_reg(AC3_3430_MMC3_CMD);
>> +			omap_cfg_reg(AE11_3430_MMC3_DAT0);
>> +			omap_cfg_reg(AH9_3430_MMC3_DAT1);
>> +			omap_cfg_reg(AF13_3430_MMC3_DAT2);
>> +			omap_cfg_reg(AF13_3430_MMC3_DAT3);
>> +		}
>> +	}
>> }
>
> Great, just one issue: All data pins may not be connected, so you
> need to look at wires in struct omap_mmc_slot_data to see how many
> data pins to mux.

There is another issue: different mux-outs are possible for different  
board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of  
AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,  
but at a minimum, perhaps make mux setting optional, e.g. add no_mux  
to struct omap_mmc_slot_data.

Hugo

>
> Regards,
>
> Tony
>
>
>> void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
>> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
>> index 026c4fc..d49b9a7 100644
>> --- a/arch/arm/mach-omap2/mux.c
>> +++ b/arch/arm/mach-omap2/mux.c
>> @@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>> MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
>> +/* MMC1 */
>> +MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +
>> +/* MMC2 */
>> +MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>> +
>> +/* MMC3 */
>> +MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
>> +		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>> };
>>
>> #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
>> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat- 
>> omap/include/mach/mux.h
>> index 85a6217..d24fdf9 100644
>> --- a/arch/arm/plat-omap/include/mach/mux.h
>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>> @@ -853,6 +853,34 @@ enum omap34xx_index {
>> 	AE5_34XX_GPIO143,
>> 	H19_34XX_GPIO164_OUT,
>> 	J25_34XX_GPIO170,
>> +
>> +	/* MMC1 */
>> +	N28_3430_MMC1_CLK,
>> +	M27_3430_MMC1_CMD,
>> +	N27_3430_MMC1_DAT0,
>> +	N26_3430_MMC1_DAT1,
>> +	N25_3430_MMC1_DAT2,
>> +	P28_3430_MMC1_DAT3,
>> +	P27_3430_MMC1_DAT4,
>> +	P26_3430_MMC1_DAT5,
>> +	R27_3430_MMC1_DAT6,
>> +	R25_3430_MMC1_DAT7,
>> +
>> +	/* MMC2 */
>> +	AE2_3430_MMC2_CLK,
>> +	AG5_3430_MMC2_CMD,
>> +	AH5_3430_MMC2_DAT0,
>> +	AH4_3430_MMC2_DAT1,
>> +	AG4_3430_MMC2_DAT2,
>> +	AF4_3430_MMC2_DAT3,
>> +
>> +	/* MMC3 */
>> +	AF10_3430_MMC3_CLK,
>> +	AC3_3430_MMC3_CMD,
>> +	AE11_3430_MMC3_DAT0,
>> +	AH9_3430_MMC3_DAT1,
>> +	AF13_3430_MMC3_DAT2,
>> +	AF13_3430_MMC3_DAT3,
>> };
>>
>> struct omap_mux_cfg {
>> -- 
>> 1.6.0.3.613.g9f8f13
>>
>> --
>> 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
> --
> 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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-15 10:44   ` Hugo Vincent
@ 2009-06-15 11:04     ` Tony Lindgren
  2009-06-15 15:46       ` Madhusudhan
  2009-06-16 14:56       ` Pandita, Vikram
  0 siblings, 2 replies; 18+ messages in thread
From: Tony Lindgren @ 2009-06-15 11:04 UTC (permalink / raw)
  To: Hugo Vincent; +Cc: Vikram Pandita, linux-omap, Chikkature Rajashekar

* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>
> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>
>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>>
>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>>> ---
>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++ 
>>> ++++++++++
>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>>> 3 files changed, 110 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/ 
>>> devices.c
>>> index 894cc35..f86cb1f 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>>> @@ -513,6 +513,39 @@ static inline void omap2_mmc_mux(struct  
>>> omap_mmc_platform_data *mmc_controller,
>>> 			omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
>>> 		}
>>> 	}
>>> +
>>> +	if (cpu_is_omap3430()) {
>>> +		if (controller_nr == 0) {
>>> +			omap_cfg_reg(N28_3430_MMC1_CLK);
>>> +			omap_cfg_reg(M27_3430_MMC1_CMD);
>>> +			omap_cfg_reg(N27_3430_MMC1_DAT0);
>>> +			omap_cfg_reg(N26_3430_MMC1_DAT1);
>>> +			omap_cfg_reg(N25_3430_MMC1_DAT2);
>>> +			omap_cfg_reg(P28_3430_MMC1_DAT3);
>>> +			omap_cfg_reg(P27_3430_MMC1_DAT4);
>>> +			omap_cfg_reg(P26_3430_MMC1_DAT5);
>>> +			omap_cfg_reg(R27_3430_MMC1_DAT6);
>>> +			omap_cfg_reg(R25_3430_MMC1_DAT7);
>>> +		}
>>> +		if (controller_nr == 1) {
>>> +			/* MMC2 */
>>> +			omap_cfg_reg(AE2_3430_MMC2_CLK);
>>> +			omap_cfg_reg(AG5_3430_MMC2_CMD);
>>> +			omap_cfg_reg(AH5_3430_MMC2_DAT0);
>>> +			omap_cfg_reg(AH4_3430_MMC2_DAT1);
>>> +			omap_cfg_reg(AG4_3430_MMC2_DAT2);
>>> +			omap_cfg_reg(AF4_3430_MMC2_DAT3);
>>> +		}
>>> +		if (controller_nr == 2) {
>>> +			/* MMC3 */
>>> +			omap_cfg_reg(AF10_3430_MMC3_CLK);
>>> +			omap_cfg_reg(AC3_3430_MMC3_CMD);
>>> +			omap_cfg_reg(AE11_3430_MMC3_DAT0);
>>> +			omap_cfg_reg(AH9_3430_MMC3_DAT1);
>>> +			omap_cfg_reg(AF13_3430_MMC3_DAT2);
>>> +			omap_cfg_reg(AF13_3430_MMC3_DAT3);
>>> +		}
>>> +	}
>>> }
>>
>> Great, just one issue: All data pins may not be connected, so you
>> need to look at wires in struct omap_mmc_slot_data to see how many
>> data pins to mux.
>
> There is another issue: different mux-outs are possible for different  
> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of  
> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,  
> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to 
> struct omap_mmc_slot_data.

Hmm, yeah that's right. I guess only the common pins should be muxed
in  devices.c, and any optional pins should be muxed in the board-*.c
files.

Tony

>
> Hugo
>
>>
>> Regards,
>>
>> Tony
>>
>>
>>> void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
>>> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
>>> index 026c4fc..d49b9a7 100644
>>> --- a/arch/arm/mach-omap2/mux.c
>>> +++ b/arch/arm/mach-omap2/mux.c
>>> @@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>>> MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
>>> +/* MMC1 */
>>> +MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +
>>> +/* MMC2 */
>>> +MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +
>>> +/* MMC3 */
>>> +MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
>>> +		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> };
>>>
>>> #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
>>> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat- 
>>> omap/include/mach/mux.h
>>> index 85a6217..d24fdf9 100644
>>> --- a/arch/arm/plat-omap/include/mach/mux.h
>>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>>> @@ -853,6 +853,34 @@ enum omap34xx_index {
>>> 	AE5_34XX_GPIO143,
>>> 	H19_34XX_GPIO164_OUT,
>>> 	J25_34XX_GPIO170,
>>> +
>>> +	/* MMC1 */
>>> +	N28_3430_MMC1_CLK,
>>> +	M27_3430_MMC1_CMD,
>>> +	N27_3430_MMC1_DAT0,
>>> +	N26_3430_MMC1_DAT1,
>>> +	N25_3430_MMC1_DAT2,
>>> +	P28_3430_MMC1_DAT3,
>>> +	P27_3430_MMC1_DAT4,
>>> +	P26_3430_MMC1_DAT5,
>>> +	R27_3430_MMC1_DAT6,
>>> +	R25_3430_MMC1_DAT7,
>>> +
>>> +	/* MMC2 */
>>> +	AE2_3430_MMC2_CLK,
>>> +	AG5_3430_MMC2_CMD,
>>> +	AH5_3430_MMC2_DAT0,
>>> +	AH4_3430_MMC2_DAT1,
>>> +	AG4_3430_MMC2_DAT2,
>>> +	AF4_3430_MMC2_DAT3,
>>> +
>>> +	/* MMC3 */
>>> +	AF10_3430_MMC3_CLK,
>>> +	AC3_3430_MMC3_CMD,
>>> +	AE11_3430_MMC3_DAT0,
>>> +	AH9_3430_MMC3_DAT1,
>>> +	AF13_3430_MMC3_DAT2,
>>> +	AF13_3430_MMC3_DAT3,
>>> };
>>>
>>> struct omap_mux_cfg {
>>> -- 
>>> 1.6.0.3.613.g9f8f13
>>>
>>> --
>>> 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
>> --
>> 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
>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-15 11:04     ` Tony Lindgren
@ 2009-06-15 15:46       ` Madhusudhan
  2009-06-16 14:56       ` Pandita, Vikram
  1 sibling, 0 replies; 18+ messages in thread
From: Madhusudhan @ 2009-06-15 15:46 UTC (permalink / raw)
  To: 'Tony Lindgren', 'Hugo Vincent'
  Cc: 'Vikram Pandita', linux-omap



-----Original Message-----
From: Tony Lindgren [mailto:tony@atomide.com] 
Sent: Monday, June 15, 2009 6:05 AM
To: Hugo Vincent
Cc: Vikram Pandita; linux-omap@vger.kernel.org; Chikkature Rajashekar
Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins

* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>
> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>
>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>>
>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>>> ---
>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++ 
>>> ++++++++++
>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>>> 3 files changed, 110 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/ 
>>> devices.c
>>> index 894cc35..f86cb1f 100644
>>> --- a/arch/arm/mach-omap2/devices.c
>>> +++ b/arch/arm/mach-omap2/devices.c
>>> @@ -513,6 +513,39 @@ static inline void omap2_mmc_mux(struct  
>>> omap_mmc_platform_data *mmc_controller,
>>> 			omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
>>> 		}
>>> 	}
>>> +
>>> +	if (cpu_is_omap3430()) {
>>> +		if (controller_nr == 0) {
>>> +			omap_cfg_reg(N28_3430_MMC1_CLK);
>>> +			omap_cfg_reg(M27_3430_MMC1_CMD);
>>> +			omap_cfg_reg(N27_3430_MMC1_DAT0);
>>> +			omap_cfg_reg(N26_3430_MMC1_DAT1);
>>> +			omap_cfg_reg(N25_3430_MMC1_DAT2);
>>> +			omap_cfg_reg(P28_3430_MMC1_DAT3);
>>> +			omap_cfg_reg(P27_3430_MMC1_DAT4);
>>> +			omap_cfg_reg(P26_3430_MMC1_DAT5);
>>> +			omap_cfg_reg(R27_3430_MMC1_DAT6);
>>> +			omap_cfg_reg(R25_3430_MMC1_DAT7);
>>> +		}
>>> +		if (controller_nr == 1) {
>>> +			/* MMC2 */
>>> +			omap_cfg_reg(AE2_3430_MMC2_CLK);
>>> +			omap_cfg_reg(AG5_3430_MMC2_CMD);
>>> +			omap_cfg_reg(AH5_3430_MMC2_DAT0);
>>> +			omap_cfg_reg(AH4_3430_MMC2_DAT1);
>>> +			omap_cfg_reg(AG4_3430_MMC2_DAT2);
>>> +			omap_cfg_reg(AF4_3430_MMC2_DAT3);
>>> +		}
>>> +		if (controller_nr == 2) {
>>> +			/* MMC3 */
>>> +			omap_cfg_reg(AF10_3430_MMC3_CLK);
>>> +			omap_cfg_reg(AC3_3430_MMC3_CMD);
>>> +			omap_cfg_reg(AE11_3430_MMC3_DAT0);
>>> +			omap_cfg_reg(AH9_3430_MMC3_DAT1);
>>> +			omap_cfg_reg(AF13_3430_MMC3_DAT2);
>>> +			omap_cfg_reg(AF13_3430_MMC3_DAT3);
>>> +		}
>>> +	}
>>> }
>>
>> Great, just one issue: All data pins may not be connected, so you
>> need to look at wires in struct omap_mmc_slot_data to see how many
>> data pins to mux.
>
> There is another issue: different mux-outs are possible for different  
> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of  
> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,  
> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to 
> struct omap_mmc_slot_data.

Hmm, yeah that's right. I guess only the common pins should be muxed
in  devices.c, and any optional pins should be muxed in the board-*.c
files.

Tony


The MMC1 and MMC2 configurations done above seem to be okay as they are the
only configuration on 3430. Whereas MMC3 pins seem to be having multiple
options for CMD,CLK and Dat0-Dat3. Let us move MMC3 muxing from devices.c to
board-*.c??

Regards,
Madhu

>
> Hugo
>
>>
>> Regards,
>>
>> Tony
>>
>>
>>> void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
>>> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
>>> index 026c4fc..d49b9a7 100644
>>> --- a/arch/arm/mach-omap2/mux.c
>>> +++ b/arch/arm/mach-omap2/mux.c
>>> @@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>>> MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
>>> +/* MMC1 */
>>> +MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +
>>> +/* MMC2 */
>>> +MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +
>>> +/* MMC3 */
>>> +MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
>>> +		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> };
>>>
>>> #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
>>> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat- 
>>> omap/include/mach/mux.h
>>> index 85a6217..d24fdf9 100644
>>> --- a/arch/arm/plat-omap/include/mach/mux.h
>>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>>> @@ -853,6 +853,34 @@ enum omap34xx_index {
>>> 	AE5_34XX_GPIO143,
>>> 	H19_34XX_GPIO164_OUT,
>>> 	J25_34XX_GPIO170,
>>> +
>>> +	/* MMC1 */
>>> +	N28_3430_MMC1_CLK,
>>> +	M27_3430_MMC1_CMD,
>>> +	N27_3430_MMC1_DAT0,
>>> +	N26_3430_MMC1_DAT1,
>>> +	N25_3430_MMC1_DAT2,
>>> +	P28_3430_MMC1_DAT3,
>>> +	P27_3430_MMC1_DAT4,
>>> +	P26_3430_MMC1_DAT5,
>>> +	R27_3430_MMC1_DAT6,
>>> +	R25_3430_MMC1_DAT7,
>>> +
>>> +	/* MMC2 */
>>> +	AE2_3430_MMC2_CLK,
>>> +	AG5_3430_MMC2_CMD,
>>> +	AH5_3430_MMC2_DAT0,
>>> +	AH4_3430_MMC2_DAT1,
>>> +	AG4_3430_MMC2_DAT2,
>>> +	AF4_3430_MMC2_DAT3,
>>> +
>>> +	/* MMC3 */
>>> +	AF10_3430_MMC3_CLK,
>>> +	AC3_3430_MMC3_CMD,
>>> +	AE11_3430_MMC3_DAT0,
>>> +	AH9_3430_MMC3_DAT1,
>>> +	AF13_3430_MMC3_DAT2,
>>> +	AF13_3430_MMC3_DAT3,
>>> };
>>>
>>> struct omap_mux_cfg {
>>> -- 
>>> 1.6.0.3.613.g9f8f13
>>>
>>> --
>>> 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
>> --
>> 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
>



^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-15 11:04     ` Tony Lindgren
  2009-06-15 15:46       ` Madhusudhan
@ 2009-06-16 14:56       ` Pandita, Vikram
  2009-06-16 15:35         ` Kevin Hilman
  1 sibling, 1 reply; 18+ messages in thread
From: Pandita, Vikram @ 2009-06-16 14:56 UTC (permalink / raw)
  To: Tony Lindgren, Hugo Vincent
  Cc: linux-omap, Chikkature Rajashekar, Madhusudhan



>-----Original Message-----
>From: Tony Lindgren [mailto:tony@atomide.com]
>Sent: Monday, June 15, 2009 6:05 AM
>To: Hugo Vincent
>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan
>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>
>* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>>
>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>>
>>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>>>
>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>>>> ---
>>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++
>>>> ++++++++++
>>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>>>
>>> Great, just one issue: All data pins may not be connected, so you
>>> need to look at wires in struct omap_mmc_slot_data to see how many
>>> data pins to mux.
>>
>> There is another issue: different mux-outs are possible for different
>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of
>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,
>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to
>> struct omap_mmc_slot_data.
>
>Hmm, yeah that's right. I guess only the common pins should be muxed
>in  devices.c, and any optional pins should be muxed in the board-*.c
>files.

Please check this patch set:
[PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag

I used the nomux flag to do this distinction.

Please comment.

>
>Tony
>
>>
>> Hugo
>>
>>>
>>> Regards,
>>>
>>> Tony
>>>
>>>
>>>> void __init omap2_init_mmc(struct omap_mmc_platform_data **mmc_data,
>>>> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
>>>> index 026c4fc..d49b9a7 100644
>>>> --- a/arch/arm/mach-omap2/mux.c
>>>> +++ b/arch/arm/mach-omap2/mux.c
>>>> @@ -486,6 +486,55 @@ MUX_CFG_34XX("H19_34XX_GPIO164_OUT", 0x19c,
>>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>>>> MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
>>>> 		OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
>>>> +/* MMC1 */
>>>> +MUX_CFG_34XX("N28_3430_MMC1_CLK", 0x144,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("M27_3430_MMC1_CMD", 0x146,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("N27_3430_MMC1_DAT0", 0x148,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("N26_3430_MMC1_DAT1", 0x14a,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("N25_3430_MMC1_DAT2", 0x14c,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("P28_3430_MMC1_DAT3", 0x14e,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("P27_3430_MMC1_DAT4", 0x150,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("P26_3430_MMC1_DAT5", 0x152,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("R27_3430_MMC1_DAT6", 0x154,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("R25_3430_MMC1_DAT7", 0x156,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +
>>>> +/* MMC2 */
>>>> +MUX_CFG_34XX("AE2_3430_MMC2_CLK", 0x158,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AG5_3430_MMC2_CMD", 0x15A,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AH5_3430_MMC2_DAT0", 0x15c,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AH4_3430_MMC2_DAT1", 0x15e,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AG4_3430_MMC2_DAT2", 0x160,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AF4_3430_MMC2_DAT3", 0x162,
>>>> +		OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +
>>>> +/* MMC3 */
>>>> +MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
>>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
>>>> +		OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> +MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>> +		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> };
>>>>
>>>> #define OMAP34XX_PINS_SZ	ARRAY_SIZE(omap34xx_pins)
>>>> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
>>>> omap/include/mach/mux.h
>>>> index 85a6217..d24fdf9 100644
>>>> --- a/arch/arm/plat-omap/include/mach/mux.h
>>>> +++ b/arch/arm/plat-omap/include/mach/mux.h
>>>> @@ -853,6 +853,34 @@ enum omap34xx_index {
>>>> 	AE5_34XX_GPIO143,
>>>> 	H19_34XX_GPIO164_OUT,
>>>> 	J25_34XX_GPIO170,
>>>> +
>>>> +	/* MMC1 */
>>>> +	N28_3430_MMC1_CLK,
>>>> +	M27_3430_MMC1_CMD,
>>>> +	N27_3430_MMC1_DAT0,
>>>> +	N26_3430_MMC1_DAT1,
>>>> +	N25_3430_MMC1_DAT2,
>>>> +	P28_3430_MMC1_DAT3,
>>>> +	P27_3430_MMC1_DAT4,
>>>> +	P26_3430_MMC1_DAT5,
>>>> +	R27_3430_MMC1_DAT6,
>>>> +	R25_3430_MMC1_DAT7,
>>>> +
>>>> +	/* MMC2 */
>>>> +	AE2_3430_MMC2_CLK,
>>>> +	AG5_3430_MMC2_CMD,
>>>> +	AH5_3430_MMC2_DAT0,
>>>> +	AH4_3430_MMC2_DAT1,
>>>> +	AG4_3430_MMC2_DAT2,
>>>> +	AF4_3430_MMC2_DAT3,
>>>> +
>>>> +	/* MMC3 */
>>>> +	AF10_3430_MMC3_CLK,
>>>> +	AC3_3430_MMC3_CMD,
>>>> +	AE11_3430_MMC3_DAT0,
>>>> +	AH9_3430_MMC3_DAT1,
>>>> +	AF13_3430_MMC3_DAT2,
>>>> +	AF13_3430_MMC3_DAT3,
>>>> };
>>>>
>>>> struct omap_mux_cfg {
>>>> --
>>>> 1.6.0.3.613.g9f8f13
>>>>
>>>> --
>>>> 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
>>> --
>>> 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
>>


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-16 14:56       ` Pandita, Vikram
@ 2009-06-16 15:35         ` Kevin Hilman
  2009-06-16 16:50           ` Pandita, Vikram
  0 siblings, 1 reply; 18+ messages in thread
From: Kevin Hilman @ 2009-06-16 15:35 UTC (permalink / raw)
  To: Pandita, Vikram
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan

"Pandita, Vikram" <vikram.pandita@ti.com> writes:

>>-----Original Message-----
>>From: Tony Lindgren [mailto:tony@atomide.com]
>>Sent: Monday, June 15, 2009 6:05 AM
>>To: Hugo Vincent
>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan
>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>>
>>* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>>>
>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>>>
>>>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>>>>
>>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>>>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>>>>> ---
>>>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>>>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++
>>>>> ++++++++++
>>>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>>>>
>>>> Great, just one issue: All data pins may not be connected, so you
>>>> need to look at wires in struct omap_mmc_slot_data to see how many
>>>> data pins to mux.
>>>
>>> There is another issue: different mux-outs are possible for different
>>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of
>>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,
>>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to
>>> struct omap_mmc_slot_data.
>>
>>Hmm, yeah that's right. I guess only the common pins should be muxed
>>in  devices.c, and any optional pins should be muxed in the board-*.c
>>files.
>
> Please check this patch set:
> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag
>
> I used the nomux flag to do this distinction.
>

This still doesn't address the problem that when you do mux, you mux
all OMAP3 platforms the same way, and that is not correct.

Only some of it is common, the others are platform specific.

Kevin

^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-16 15:35         ` Kevin Hilman
@ 2009-06-16 16:50           ` Pandita, Vikram
  2009-06-17  8:12             ` Tony Lindgren
  0 siblings, 1 reply; 18+ messages in thread
From: Pandita, Vikram @ 2009-06-16 16:50 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan


>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>
>"Pandita, Vikram" <vikram.pandita@ti.com> writes:
>
>>>-----Original Message-----
>>>From: Tony Lindgren [mailto:tony@atomide.com]
>>>Sent: Monday, June 15, 2009 6:05 AM
>>>To: Hugo Vincent
>>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan
>>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>>>
>>>* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>>>>
>>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>>>>
>>>>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>>>>>>
>>>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>>>>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>>>>>> ---
>>>>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>>>>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++
>>>>>> ++++++++++
>>>>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>>>>>
>>>>> Great, just one issue: All data pins may not be connected, so you
>>>>> need to look at wires in struct omap_mmc_slot_data to see how many
>>>>> data pins to mux.
>>>>
>>>> There is another issue: different mux-outs are possible for different
>>>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of
>>>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,
>>>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to
>>>> struct omap_mmc_slot_data.
>>>
>>>Hmm, yeah that's right. I guess only the common pins should be muxed
>>>in  devices.c, and any optional pins should be muxed in the board-*.c
>>>files.
>>
>> Please check this patch set:
>> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag
>>
>> I used the nomux flag to do this distinction.
>>
>
>This still doesn't address the problem that when you do mux, you mux
>all OMAP3 platforms the same way, and that is not correct.

The patch tries to address this exact concern.

Using nomux flag, the board file decides if the default mux for each MMC(n) controller is good for it or not.

In case default is good, then MMC(n).nomux=0
In case default mux for any one MMC controller is not good, then for that MMC(n).nomux=1

And the board file specifies the mux for that MMC(n) only. 

I do not see any advantage to control mux at ball level for each mmc controller instance.


>
>Only some of it is common, the others are platform specific.
>
>Kevin


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-16 16:50           ` Pandita, Vikram
@ 2009-06-17  8:12             ` Tony Lindgren
  2009-06-17 17:44               ` Pandita, Vikram
  0 siblings, 1 reply; 18+ messages in thread
From: Tony Lindgren @ 2009-06-17  8:12 UTC (permalink / raw)
  To: Pandita, Vikram
  Cc: Kevin Hilman, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan

* Pandita, Vikram <vikram.pandita@ti.com> [090616 09:50]:
> 
> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >
> >"Pandita, Vikram" <vikram.pandita@ti.com> writes:
> >
> >>>-----Original Message-----
> >>>From: Tony Lindgren [mailto:tony@atomide.com]
> >>>Sent: Monday, June 15, 2009 6:05 AM
> >>>To: Hugo Vincent
> >>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan
> >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
> >>>
> >>>* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
> >>>>
> >>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
> >>>>
> >>>>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
> >>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
> >>>>>>
> >>>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
> >>>>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
> >>>>>> ---
> >>>>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
> >>>>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++
> >>>>>> ++++++++++
> >>>>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
> >>>>>
> >>>>> Great, just one issue: All data pins may not be connected, so you
> >>>>> need to look at wires in struct omap_mmc_slot_data to see how many
> >>>>> data pins to mux.
> >>>>
> >>>> There is another issue: different mux-outs are possible for different
> >>>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of
> >>>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,
> >>>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to
> >>>> struct omap_mmc_slot_data.
> >>>
> >>>Hmm, yeah that's right. I guess only the common pins should be muxed
> >>>in  devices.c, and any optional pins should be muxed in the board-*.c
> >>>files.
> >>
> >> Please check this patch set:
> >> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag
> >>
> >> I used the nomux flag to do this distinction.
> >>
> >
> >This still doesn't address the problem that when you do mux, you mux
> >all OMAP3 platforms the same way, and that is not correct.
> 
> The patch tries to address this exact concern.
> 
> Using nomux flag, the board file decides if the default mux for each MMC(n) controller is good for it or not.
> 
> In case default is good, then MMC(n).nomux=0
> In case default mux for any one MMC controller is not good, then for that MMC(n).nomux=1
> 
> And the board file specifies the mux for that MMC(n) only. 
> 
> I do not see any advantage to control mux at ball level for each mmc controller instance.

To me it seems cleanest just to do the muxing in board-*.c files and not even
attempt to do it in a generic way. As we also support doing the muxing in
the bootloader only, adding a flag for nomux can easily create hard to
track bugs.

If some pins are always needed, and don't have alternative pinouts, then
the common pins could be muxed in devices.c.

Regards,

Tony

^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17  8:12             ` Tony Lindgren
@ 2009-06-17 17:44               ` Pandita, Vikram
  2009-06-17 18:27                 ` Kevin Hilman
  0 siblings, 1 reply; 18+ messages in thread
From: Pandita, Vikram @ 2009-06-17 17:44 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Kevin Hilman, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan



>-----Original Message-----
>From: Tony Lindgren [mailto:tony@atomide.com]
>
>* Pandita, Vikram <vikram.pandita@ti.com> [090616 09:50]:
>>
>> >From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>> >
>> >"Pandita, Vikram" <vikram.pandita@ti.com> writes:
>> >
>> >>>-----Original Message-----
>> >>>From: Tony Lindgren [mailto:tony@atomide.com]
>> >>>Sent: Monday, June 15, 2009 6:05 AM
>> >>>To: Hugo Vincent
>> >>>Cc: Pandita, Vikram; linux-omap@vger.kernel.org; Chikkature Rajashekar, Madhusudhan
>> >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>> >>>
>> >>>* Hugo Vincent <hugo.vincent@gmail.com> [090615 03:44]:
>> >>>>
>> >>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>> >>>>
>> >>>>> * Vikram Pandita <vikram.pandita@ti.com> [090612 15:43]:
>> >>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>> >>>>>>
>> >>>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@ti.com>
>> >>>>>> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
>> >>>>>> ---
>> >>>>>> arch/arm/mach-omap2/devices.c         |   33 ++++++++++++++++++++++
>> >>>>>> arch/arm/mach-omap2/mux.c             |   49 +++++++++++++++++++++++
>> >>>>>> ++++++++++
>> >>>>>> arch/arm/plat-omap/include/mach/mux.h |   28 +++++++++++++++++++
>> >>>>>
>> >>>>> Great, just one issue: All data pins may not be connected, so you
>> >>>>> need to look at wires in struct omap_mmc_slot_data to see how many
>> >>>>> data pins to mux.
>> >>>>
>> >>>> There is another issue: different mux-outs are possible for different
>> >>>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of
>> >>>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is,
>> >>>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to
>> >>>> struct omap_mmc_slot_data.
>> >>>
>> >>>Hmm, yeah that's right. I guess only the common pins should be muxed
>> >>>in  devices.c, and any optional pins should be muxed in the board-*.c
>> >>>files.
>> >>
>> >> Please check this patch set:
>> >> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag
>> >>
>> >> I used the nomux flag to do this distinction.
>> >>
>> >
>> >This still doesn't address the problem that when you do mux, you mux
>> >all OMAP3 platforms the same way, and that is not correct.
>>
>> The patch tries to address this exact concern.
>>
>> Using nomux flag, the board file decides if the default mux for each MMC(n) controller is good for
>it or not.
>>
>> In case default is good, then MMC(n).nomux=0
>> In case default mux for any one MMC controller is not good, then for that MMC(n).nomux=1
>>
>> And the board file specifies the mux for that MMC(n) only.
>>
>> I do not see any advantage to control mux at ball level for each mmc controller instance.
>
>To me it seems cleanest just to do the muxing in board-*.c files and not even
>attempt to do it in a generic way. As we also support doing the muxing in
>the bootloader only, adding a flag for nomux can easily create hard to
>track bugs.

Ok.

>
>If some pins are always needed, and don't have alternative pinouts, then
>the common pins could be muxed in devices.c.

This is the algo we can use for MMC pin muxing in that case:

MMC1: No pin has mux clash
	Mux all 10 pins in devices.c 

MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash
	In case board needs 8 bit support,
	then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board file"

MMC3: All pins have mux clash: No mux done in devices.c
	In case board specifies MMC3 usage, 
	then in devices.c print KERN_WARNING "Configure MMC3 mux in board file"

Let me know if this is final and I can submit a patch.

>
>Regards,
>
>Tony


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 17:44               ` Pandita, Vikram
@ 2009-06-17 18:27                 ` Kevin Hilman
  2009-06-17 18:38                   ` Pandita, Vikram
  0 siblings, 1 reply; 18+ messages in thread
From: Kevin Hilman @ 2009-06-17 18:27 UTC (permalink / raw)
  To: Pandita, Vikram
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan

"Pandita, Vikram" <vikram.pandita@ti.com> writes:

>>
>>If some pins are always needed, and don't have alternative pinouts, then
>>the common pins could be muxed in devices.c.
>
> This is the algo we can use for MMC pin muxing in that case:
>
> MMC1: No pin has mux clash
> 	Mux all 10 pins in devices.c 

Is this common across 34xx and 35xx?

> MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash
> 	In case board needs 8 bit support,
> 	then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board file"

I don't think you need a KERN_WARNING, what if the board code does this
later?  Probably a comment in the code would suffice.

> MMC3: All pins have mux clash: No mux done in devices.c
> 	In case board specifies MMC3 usage, 
> 	then in devices.c print KERN_WARNING "Configure MMC3 mux in board file"
>
> Let me know if this is final and I can submit a patch.

Kevin



^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 18:27                 ` Kevin Hilman
@ 2009-06-17 18:38                   ` Pandita, Vikram
  2009-06-17 21:39                     ` Kevin Hilman
  0 siblings, 1 reply; 18+ messages in thread
From: Pandita, Vikram @ 2009-06-17 18:38 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan



>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>
>>>If some pins are always needed, and don't have alternative pinouts, then
>>>the common pins could be muxed in devices.c.
>>
>> This is the algo we can use for MMC pin muxing in that case:
>>
>> MMC1: No pin has mux clash
>> 	Mux all 10 pins in devices.c
>
>Is this common across 34xx and 35xx?

Yes this is common.
Both are same OMAP3 marketed differently.

>
>> MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash
>> 	In case board needs 8 bit support,
>> 	then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board file"
>
>I don't think you need a KERN_WARNING, what if the board code does this
>later?  Probably a comment in the code would suffice.

Given this split of common MMC mux in devices.c
and non-common MMC mux in board file, 
for someone starting new, a warning message helps a lot...

The idea is to warn only MMC2-8bit and MMC3 user to setup the mux.

If already done in uboot/board file, purpose is solved... 

>
>> MMC3: All pins have mux clash: No mux done in devices.c
>> 	In case board specifies MMC3 usage,
>> 	then in devices.c print KERN_WARNING "Configure MMC3 mux in board file"
>>
>> Let me know if this is final and I can submit a patch.
>
>Kevin
>
>


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 18:38                   ` Pandita, Vikram
@ 2009-06-17 21:39                     ` Kevin Hilman
  2009-06-17 22:48                       ` Jon Hunter
  0 siblings, 1 reply; 18+ messages in thread
From: Kevin Hilman @ 2009-06-17 21:39 UTC (permalink / raw)
  To: Pandita, Vikram
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan

"Pandita, Vikram" <vikram.pandita@ti.com> writes:

>>-----Original Message-----
>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>
>>>>If some pins are always needed, and don't have alternative pinouts, then
>>>>the common pins could be muxed in devices.c.
>>>
>>> This is the algo we can use for MMC pin muxing in that case:
>>>
>>> MMC1: No pin has mux clash
>>> 	Mux all 10 pins in devices.c
>>
>>Is this common across 34xx and 35xx?
>
> Yes this is common.
> Both are same OMAP3 marketed differently.

Yes, but they are in different packages, so I was curious if the pin
muxing is identical across the different packages.

Kevin

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 21:39                     ` Kevin Hilman
@ 2009-06-17 22:48                       ` Jon Hunter
  2009-06-17 22:57                         ` Kevin Hilman
  0 siblings, 1 reply; 18+ messages in thread
From: Jon Hunter @ 2009-06-17 22:48 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: Pandita, Vikram, Tony Lindgren, Hugo Vincent, linux-omap,
	Chikkature Rajashekar, Madhusudhan


Kevin Hilman wrote:
> "Pandita, Vikram" <vikram.pandita@ti.com> writes:
> 
>>> -----Original Message-----
>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>
>>>>> If some pins are always needed, and don't have alternative pinouts, then
>>>>> the common pins could be muxed in devices.c.
>>>> This is the algo we can use for MMC pin muxing in that case:
>>>>
>>>> MMC1: No pin has mux clash
>>>> 	Mux all 10 pins in devices.c
>>> Is this common across 34xx and 35xx?
>> Yes this is common.
>> Both are same OMAP3 marketed differently.
> 
> Yes, but they are in different packages, so I was curious if the pin
> muxing is identical across the different packages.

The ball/pad numbers may change due to the package, but the registers
used to configure the pin muxing and the pin muxing options will not 
change. So from a software standpoint it is the same.

The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS 
according to the data manual [1]. The OMAP3430 is only available in the 
CBB package.

What this means is that the name "N28_3430_MMC1_CLK", which associates 
ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and OMAP3530 
CBB package, but not applicable to the OMAP3530 CBC and CUS packages
as this ball number does not exist on these packages. This is simply a 
difference in naming of the balls between the packages but does not 
impact the pin muxing options.

Cheers
Jon

[1] OMAP3530 Data Manual
http://www.ti.com/lit/gpn/omap3530





^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 22:48                       ` Jon Hunter
@ 2009-06-17 22:57                         ` Kevin Hilman
  2009-06-17 23:25                           ` Pandita, Vikram
  0 siblings, 1 reply; 18+ messages in thread
From: Kevin Hilman @ 2009-06-17 22:57 UTC (permalink / raw)
  To: Jon Hunter
  Cc: Pandita, Vikram, Tony Lindgren, Hugo Vincent, linux-omap,
	Chikkature Rajashekar, Madhusudhan

Jon Hunter <jon-hunter@ti.com> writes:

> Kevin Hilman wrote:
>> "Pandita, Vikram" <vikram.pandita@ti.com> writes:
>>
>>>> -----Original Message-----
>>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>
>>>>>> If some pins are always needed, and don't have alternative pinouts, then
>>>>>> the common pins could be muxed in devices.c.
>>>>> This is the algo we can use for MMC pin muxing in that case:
>>>>>
>>>>> MMC1: No pin has mux clash
>>>>> 	Mux all 10 pins in devices.c
>>>> Is this common across 34xx and 35xx?
>>> Yes this is common.
>>> Both are same OMAP3 marketed differently.
>>
>> Yes, but they are in different packages, so I was curious if the pin
>> muxing is identical across the different packages.
>
> The ball/pad numbers may change due to the package, but the registers
> used to configure the pin muxing and the pin muxing options will not
> change. So from a software standpoint it is the same.
>
> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS
> according to the data manual [1]. The OMAP3430 is only available in
> the CBB package.
>
> What this means is that the name "N28_3430_MMC1_CLK", which associates
> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and
> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS
> packages
> as this ball number does not exist on these packages. This is simply a
> difference in naming of the balls between the packages but does not
> impact the pin muxing options.

OK, good.  Thanks for the clarification.

Tony and I were thinking a few weeks back that we should drop the ball
names from these mux options anyways as they don't really add any
value, and seem to add more confusion.  Sounds like it's the right
thing to do in this context.

Kevin




^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 22:57                         ` Kevin Hilman
@ 2009-06-17 23:25                           ` Pandita, Vikram
  2009-06-18  0:08                             ` Jon Hunter
  0 siblings, 1 reply; 18+ messages in thread
From: Pandita, Vikram @ 2009-06-17 23:25 UTC (permalink / raw)
  To: Kevin Hilman, Hunter, Jon
  Cc: Tony Lindgren, Hugo Vincent, linux-omap, Chikkature Rajashekar,
	Madhusudhan



>-----Original Message-----
>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>Sent: Wednesday, June 17, 2009 5:58 PM
>To: Hunter, Jon
>Cc: Pandita, Vikram; Tony Lindgren; Hugo Vincent; linux-omap@vger.kernel.org; Chikkature Rajashekar,
>Madhusudhan
>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>
>Jon Hunter <jon-hunter@ti.com> writes:
>
>> Kevin Hilman wrote:
>>> "Pandita, Vikram" <vikram.pandita@ti.com> writes:
>>>
>>>>> -----Original Message-----
>>>>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>
>>>>>>> If some pins are always needed, and don't have alternative pinouts, then
>>>>>>> the common pins could be muxed in devices.c.
>>>>>> This is the algo we can use for MMC pin muxing in that case:
>>>>>>
>>>>>> MMC1: No pin has mux clash
>>>>>> 	Mux all 10 pins in devices.c
>>>>> Is this common across 34xx and 35xx?
>>>> Yes this is common.
>>>> Both are same OMAP3 marketed differently.
>>>
>>> Yes, but they are in different packages, so I was curious if the pin
>>> muxing is identical across the different packages.
>>
>> The ball/pad numbers may change due to the package, but the registers
>> used to configure the pin muxing and the pin muxing options will not
>> change. So from a software standpoint it is the same.
>>
>> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS
>> according to the data manual [1]. The OMAP3430 is only available in
>> the CBB package.
>>
>> What this means is that the name "N28_3430_MMC1_CLK", which associates
>> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and
>> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS
>> packages
>> as this ball number does not exist on these packages. This is simply a
>> difference in naming of the balls between the packages but does not
>> impact the pin muxing options.

So looks like I should keep the MMC mux under cpu_is_omap3430()
And not include 3530 as CBC and CUS may not be valid cases for this mux.

>
>OK, good.  Thanks for the clarification.
>
>Tony and I were thinking a few weeks back that we should drop the ball
>names from these mux options anyways as they don't really add any
>value, and seem to add more confusion.  Sounds like it's the right
>thing to do in this context.
>
>Kevin
>
>
>


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-17 23:25                           ` Pandita, Vikram
@ 2009-06-18  0:08                             ` Jon Hunter
  2009-06-18  5:04                               ` Tony Lindgren
  0 siblings, 1 reply; 18+ messages in thread
From: Jon Hunter @ 2009-06-18  0:08 UTC (permalink / raw)
  To: Pandita, Vikram
  Cc: Kevin Hilman, Tony Lindgren, Hugo Vincent, linux-omap,
	Chikkature Rajashekar, Madhusudhan


Pandita, Vikram wrote:
>>> The ball/pad numbers may change due to the package, but the registers
>>> used to configure the pin muxing and the pin muxing options will not
>>> change. So from a software standpoint it is the same.
>>>
>>> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS
>>> according to the data manual [1]. The OMAP3430 is only available in
>>> the CBB package.
>>>
>>> What this means is that the name "N28_3430_MMC1_CLK", which associates
>>> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and
>>> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS
>>> packages
>>> as this ball number does not exist on these packages. This is simply a
>>> difference in naming of the balls between the packages but does not
>>> impact the pin muxing options.
> 
> So looks like I should keep the MMC mux under cpu_is_omap3430()
> And not include 3530 as CBC and CUS may not be valid cases for this mux.

Actually, the mux configuration is still valid for the CBC and CUS 
packages. The only difference is the balls have different names. Sorry 
if this is not clear.

For example, on the OMAP3530 CBB package if you look at ball N28 you 
will find:

mux-mode0 --> mmc1_clk
mux-mode4 --> gpio120
mux-mode7 --> safe mode

For the OMAP3530 CBC package you will find the same options on N19 and 
for the CUS package the same options on ball M23.

I have been doing a bit more looking at this and we do need to becareful 
here. I think that we really need to view the OMAP3430 as a superset of 
the OMAP3530. One example being, with the OMAP3530 I don't see support 
for peripherals such as DSI, CSI, and MS. Hence, muxing options for the 
signals corresponding to these peripherals are not shown in the OMAP3530 
data manual.

This just means that there are less muxing options on some of the balls 
for the OMAP3530, but the good news is that there will not be any 
conflicts between the OMAP3430 and OMAP3530 as far as muxing goes.

>> OK, good.  Thanks for the clarification.
>>
>> Tony and I were thinking a few weeks back that we should drop the ball
>> names from these mux options anyways as they don't really add any
>> value, and seem to add more confusion.  Sounds like it's the right
>> thing to do in this context.

I was thinking this too. For different applications different packages 
make sense. So this is fairly common to see. So dropping the ball name 
would make this easier.

I guess the only benefit is knowing the actual ball that you are using 
for hardware purposes. However, on OMAP2/3 the register names imply what 
is mux-mode0 and so it fairly easy to figure out the ball number from 
the data manual.

Cheers
Jon

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] OMAP3: MMC: Add mux for pins
  2009-06-18  0:08                             ` Jon Hunter
@ 2009-06-18  5:04                               ` Tony Lindgren
  0 siblings, 0 replies; 18+ messages in thread
From: Tony Lindgren @ 2009-06-18  5:04 UTC (permalink / raw)
  To: Jon Hunter
  Cc: Pandita, Vikram, Kevin Hilman, Hugo Vincent, linux-omap,
	Chikkature Rajashekar, Madhusudhan

* Jon Hunter <jon-hunter@ti.com> [090618 03:08]:
>
> Pandita, Vikram wrote:
>>>> The ball/pad numbers may change due to the package, but the registers
>>>> used to configure the pin muxing and the pin muxing options will not
>>>> change. So from a software standpoint it is the same.
>>>>
>>>> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS
>>>> according to the data manual [1]. The OMAP3430 is only available in
>>>> the CBB package.
>>>>
>>>> What this means is that the name "N28_3430_MMC1_CLK", which associates
>>>> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and
>>>> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS
>>>> packages
>>>> as this ball number does not exist on these packages. This is simply a
>>>> difference in naming of the balls between the packages but does not
>>>> impact the pin muxing options.
>>
>> So looks like I should keep the MMC mux under cpu_is_omap3430()
>> And not include 3530 as CBC and CUS may not be valid cases for this mux.
>
> Actually, the mux configuration is still valid for the CBC and CUS  
> packages. The only difference is the balls have different names. Sorry  
> if this is not clear.
>
> For example, on the OMAP3530 CBB package if you look at ball N28 you  
> will find:
>
> mux-mode0 --> mmc1_clk
> mux-mode4 --> gpio120
> mux-mode7 --> safe mode
>
> For the OMAP3530 CBC package you will find the same options on N19 and  
> for the CUS package the same options on ball M23.
>
> I have been doing a bit more looking at this and we do need to becareful  
> here. I think that we really need to view the OMAP3430 as a superset of  
> the OMAP3530. One example being, with the OMAP3530 I don't see support  
> for peripherals such as DSI, CSI, and MS. Hence, muxing options for the  
> signals corresponding to these peripherals are not shown in the OMAP3530  
> data manual.
>
> This just means that there are less muxing options on some of the balls  
> for the OMAP3530, but the good news is that there will not be any  
> conflicts between the OMAP3430 and OMAP3530 as far as muxing goes.

Sounds good. We also need to consider the number of MMC data lines
used for muxing, that's available as wires from the board-*.c files.

>>> OK, good.  Thanks for the clarification.
>>>
>>> Tony and I were thinking a few weeks back that we should drop the ball
>>> names from these mux options anyways as they don't really add any
>>> value, and seem to add more confusion.  Sounds like it's the right
>>> thing to do in this context.
>
> I was thinking this too. For different applications different packages  
> make sense. So this is fairly common to see. So dropping the ball name  
> would make this easier.
>
> I guess the only benefit is knowing the actual ball that you are using  
> for hardware purposes. However, on OMAP2/3 the register names imply what  
> is mux-mode0 and so it fairly easy to figure out the ball number from  
> the data manual.

Yeah let's plan on making that change.

Tony

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2009-06-18  7:04 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-12 22:41 [PATCH] OMAP3: MMC: Add mux for pins Vikram Pandita
2009-06-15  8:12 ` Tony Lindgren
2009-06-15 10:44   ` Hugo Vincent
2009-06-15 11:04     ` Tony Lindgren
2009-06-15 15:46       ` Madhusudhan
2009-06-16 14:56       ` Pandita, Vikram
2009-06-16 15:35         ` Kevin Hilman
2009-06-16 16:50           ` Pandita, Vikram
2009-06-17  8:12             ` Tony Lindgren
2009-06-17 17:44               ` Pandita, Vikram
2009-06-17 18:27                 ` Kevin Hilman
2009-06-17 18:38                   ` Pandita, Vikram
2009-06-17 21:39                     ` Kevin Hilman
2009-06-17 22:48                       ` Jon Hunter
2009-06-17 22:57                         ` Kevin Hilman
2009-06-17 23:25                           ` Pandita, Vikram
2009-06-18  0:08                             ` Jon Hunter
2009-06-18  5:04                               ` Tony Lindgren

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.