Skip to contentSkip to conversation

omap4: changes for 4460 ES1.1

PATCH New Ricardo Salveti de Araujo 2 participants 6 messages Sep 21, 2011 – Sep 22, 2011 Arm (32-bit)

lore
Share & tools
lore

Ricardo Salveti de Araujo

author
#0 lore raw

cover omap4: changes for 4460 ES1.1

Changes to add proper support for 4460 ES1.1, including revision detection.

Ricardo Salveti de Araujo (3):
omap4: replacing OMAP4_CONTROL with OMAP4430_CONTROL
omap4: adding revision detection for 4460 ES1.1
omap4: splitting padconfs into common, 4430 and 4460

 arch/arm/cpu/armv7/omap4/board.c          |   24 ++++++++++++++++++------
 arch/arm/cpu/armv7/omap4/omap4_mux_data.h |    7 +++++++
 arch/arm/include/asm/arch-omap4/omap4.h   |   16 +++++++++++-----
 board/ti/panda/panda.c                    |   17 +++++++++++++++++
 board/ti/panda/panda_mux_data.h           |   14 ++++++++++++--
 5 files changed, 65 insertions(+), 13 deletions(-)
Signature · 1 line
1.7.4.1
author
#1 lore raw

PATCH 1/3 omap4: replacing OMAP4_CONTROL with OMAP4430_CONTROL

OMAP4460 has a different set of values for the ID code, so moving the old ones to be related just with 4430.

Signed-off-by Ricardo Salveti de Araujo <[email protected]>
 2 files changed, 8 insertions(+), 8 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +3 -3
index 309b244..140562b 100644
@@ -200,13 +200,13 @@ static void init_omap4_revision(void)
 		break;
 	case MIDR_CORTEX_A9_R1P2:
 		switch (readl(CONTROL_ID_CODE)) {
-		case OMAP4_CONTROL_ID_CODE_ES2_0:
+		case OMAP4430_CONTROL_ID_CODE_ES2_0:
 			*omap4_revision = OMAP4430_ES2_0;
 			break;
-		case OMAP4_CONTROL_ID_CODE_ES2_1:
+		case OMAP4430_CONTROL_ID_CODE_ES2_1:
 			*omap4_revision = OMAP4430_ES2_1;
 			break;
-		case OMAP4_CONTROL_ID_CODE_ES2_2:
+		case OMAP4430_CONTROL_ID_CODE_ES2_2:
 			*omap4_revision = OMAP4430_ES2_2;
 			break;
 		default:
arch/arm/include/asm/arch-omap4/omap4.h +5 -5
index a6e1e42..5d2d01d 100644
@@ -57,11 +57,11 @@
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE		0x4A002204
 
-#define OMAP4_CONTROL_ID_CODE_ES1_0	0x0B85202F
-#define OMAP4_CONTROL_ID_CODE_ES2_0	0x1B85202F
-#define OMAP4_CONTROL_ID_CODE_ES2_1	0x3B95C02F
-#define OMAP4_CONTROL_ID_CODE_ES2_2	0x4B95C02F
-#define OMAP4_CONTROL_ID_CODE_ES2_3	0x6B95C02F
+#define OMAP4430_CONTROL_ID_CODE_ES1_0	0x0B85202F
+#define OMAP4430_CONTROL_ID_CODE_ES2_0	0x1B85202F
+#define OMAP4430_CONTROL_ID_CODE_ES2_1	0x3B95C02F
+#define OMAP4430_CONTROL_ID_CODE_ES2_2	0x4B95C02F
+#define OMAP4430_CONTROL_ID_CODE_ES2_3	0x6B95C02F
 
 /* UART */
 #define UART1_BASE		(OMAP44XX_L4_PER_BASE + 0x6a000)
Signature · 1 line
1.7.4.1
author
#2 lore raw

PATCH 2/3 omap4: adding revision detection for 4460 ES1.1

In reply to Ricardo Salveti de Araujo
Signed-off-by Ricardo Salveti de Araujo <[email protected]>
 2 files changed, 17 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +11 -1
index 140562b..d9639ab 100644
@@ -218,7 +218,17 @@ static void init_omap4_revision(void)
 		*omap4_revision = OMAP4430_ES2_3;
 		break;
 	case MIDR_CORTEX_A9_R2P10:
-		*omap4_revision = OMAP4460_ES1_0;
+		switch (readl(CONTROL_ID_CODE)) {
+		case OMAP4460_CONTROL_ID_CODE_ES1_0:
+			*omap4_revision = OMAP4460_ES1_0;
+			break;
+		case OMAP4460_CONTROL_ID_CODE_ES1_1:
+			*omap4_revision = OMAP4460_ES1_1;
+			break;
+		default:
+			*omap4_revision = OMAP4460_ES1_0;
+			break;
+		}
 		break;
 	default:
 		*omap4_revision = OMAP4430_SILICON_ID_INVALID;
arch/arm/include/asm/arch-omap4/omap4.h +6 -0
index 5d2d01d..162ab43 100644
@@ -57,12 +57,17 @@
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE		0x4A002204
 
+/* 4430 */
 #define OMAP4430_CONTROL_ID_CODE_ES1_0	0x0B85202F
 #define OMAP4430_CONTROL_ID_CODE_ES2_0	0x1B85202F
 #define OMAP4430_CONTROL_ID_CODE_ES2_1	0x3B95C02F
 #define OMAP4430_CONTROL_ID_CODE_ES2_2	0x4B95C02F
 #define OMAP4430_CONTROL_ID_CODE_ES2_3	0x6B95C02F
 
+/* 4460 */
+#define OMAP4460_CONTROL_ID_CODE_ES1_0	0x0B94E02F
+#define OMAP4460_CONTROL_ID_CODE_ES1_1	0x2B94E02F
+
 /* UART */
 #define UART1_BASE		(OMAP44XX_L4_PER_BASE + 0x6a000)
 #define UART2_BASE		(OMAP44XX_L4_PER_BASE + 0x6c000)

@@ -185,6 +190,7 @@ struct control_lpddr2io_regs {
 #define OMAP4430_ES2_2	0x44300220
 #define OMAP4430_ES2_3	0x44300230
 #define OMAP4460_ES1_0	0x44600100
+#define OMAP4460_ES1_1	0x44600110
 
 /* ROM code defines */
 /* Boot device */
Signature · 1 line
1.7.4.1
author
#3 lore raw

PATCH 3/3 omap4: splitting padconfs into common, 4430 and 4460

In reply to Ricardo Salveti de Araujo

Not all padconfs are the same between 4430 and 4460, so instead of working around this with an if, we should have an specific padconf structure for both chips (like handling the differences between the LEDs GPIOs and TPS).

Signed-off-by Ricardo Salveti de Araujo <[email protected]>
 4 files changed, 40 insertions(+), 4 deletions(-)
arch/arm/cpu/armv7/omap4/board.c +4 -2
index d9639ab..b842782 100644
@@ -152,9 +152,11 @@ static void set_muxconf_regs_essential(void)
 		   sizeof(wkup_padconf_array_essential) /
 		   sizeof(struct pad_conf_entry));
 
-	/* gpio_wk7 is used for controlling TPS on 4460 */
 	if (omap_revision() >= OMAP4460_ES1_0)
-		writew(M3, CONTROL_WKUP_PAD1_FREF_CLK4_REQ);
+		do_set_mux(CONTROL_PADCONF_WKUP,
+				 wkup_padconf_array_essential_4460,
+				 sizeof(wkup_padconf_array_essential_4460) /
+				 sizeof(struct pad_conf_entry));
 }
 
 static void set_mux_conf_regs(void)
arch/arm/cpu/armv7/omap4/omap4_mux_data.h +7 -0
index 00c52f8..b940391 100644
@@ -73,4 +73,11 @@ const struct pad_conf_entry wkup_padconf_array_essential[] = {
 
 };
 
+const struct pad_conf_entry wkup_padconf_array_essential_4460[] = {
+
+{PAD1_FREF_CLK4_REQ, (M3)},	 /* gpio_wk7, TPS */
+
+};
+
+
 #endif  /* _OMAP4_MUX_DATA_H_ */
board/ti/panda/panda.c +17 -0
index 9afed80..97320cb 100644
@@ -71,9 +71,26 @@ void set_muxconf_regs_non_essential(void)
 		   sizeof(core_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
 
+	if (omap_revision() < OMAP4460_ES1_0)
+		do_set_mux(CONTROL_PADCONF_CORE,
+				core_padconf_array_non_essential_4430,
+				sizeof(core_padconf_array_non_essential_4430) /
+				sizeof(struct pad_conf_entry));
+	else
+		do_set_mux(CONTROL_PADCONF_CORE,
+				core_padconf_array_non_essential_4460,
+				sizeof(core_padconf_array_non_essential_4460) /
+				sizeof(struct pad_conf_entry));
+
 	do_set_mux(CONTROL_PADCONF_WKUP, wkup_padconf_array_non_essential,
 		   sizeof(wkup_padconf_array_non_essential) /
 		   sizeof(struct pad_conf_entry));
+
+	if (omap_revision() < OMAP4460_ES1_0)
+		do_set_mux(CONTROL_PADCONF_WKUP,
+				wkup_padconf_array_non_essential_4430,
+				sizeof(wkup_padconf_array_non_essential_4430) /
+				sizeof(struct pad_conf_entry));
 }
 
 #ifdef CONFIG_GENERIC_MMC
board/ti/panda/panda_mux_data.h +12 -2
index 63448b6..83d0c3f 100644
@@ -100,7 +100,6 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{USBB1_HSIC_STROBE, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* usbb1_hsic_strobe */
 	{USBC1_ICUSB_DP, (IEN | M0)},					/* usbc1_icusb_dp */
 	{USBC1_ICUSB_DM, (IEN | M0)},					/* usbc1_icusb_dm */
-	{ABE_MCBSP2_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_clkx */
 	{ABE_MCBSP2_DR, (IEN | OFF_EN | OFF_OUT_PTD | M0)},		/* abe_mcbsp2_dr */
 	{ABE_MCBSP2_DX, (OFF_EN | OFF_OUT_PTD | M0)},			/* abe_mcbsp2_dx */
 	{ABE_MCBSP2_FSX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_fsx */

@@ -202,6 +201,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = {
 	{DPM_EMU19, (IEN | M5)},					/* dispc2_data0 */
 };
 
+const struct pad_conf_entry core_padconf_array_non_essential_4430[] = {
+	{ABE_MCBSP2_CLKX, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},	/* abe_mcbsp2_clkx */
+};
+
+const struct pad_conf_entry core_padconf_array_non_essential_4460[] = {
+	{ABE_MCBSP2_CLKX, (PTU | OFF_EN | OFF_OUT_PTU | M3)},		/* led status_1 */
+};
+
 const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
 	{PAD0_SIM_IO, (IEN | M0)},		/* sim_io */
 	{PAD1_SIM_CLK, (M0)},			/* sim_clk */

@@ -214,7 +221,6 @@ const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
 	{PAD0_FREF_CLK0_OUT, (M2)},		/* sys_drm_msecure */
 	{PAD1_FREF_CLK3_REQ, M7},					/* safe mode */
 	{PAD0_FREF_CLK3_OUT, (M0)},		/* fref_clk3_out */
-	{PAD1_FREF_CLK4_REQ, (PTU | M3)},	/* led status_1 */
 	{PAD0_FREF_CLK4_OUT, (PTU | M3)},	/* led status_2 */
 	{PAD0_SYS_NRESPWRON, (M0)},		/* sys_nrespwron */
 	{PAD1_SYS_NRESWARM, (M0)},		/* sys_nreswarm */

@@ -224,4 +230,8 @@ const struct pad_conf_entry wkup_padconf_array_non_essential[] = {
 	{PAD1_SYS_BOOT7, (IEN | M3)},		/* gpio_wk10 */
 };
 
+const struct pad_conf_entry wkup_padconf_array_non_essential_4430[] = {
+	{PAD1_FREF_CLK4_REQ, (PTU | M3)},	/* led status_1 */
+};
+
 #endif /* _PANDA_MUX_DATA_H_ */
Signature · 1 line
1.7.4.1
#4 lore raw

PATCH 3/3 omap4: splitting padconfs into common, 4430 and 4460

Hi Ricardo,

Quoted 4 lines · Ricardo Salveti de Araujo

Not all padconfs are the same between 4430 and 4460, so instead of working around this with an if, we should have an specific padconf structure for both chips (like handling the differences between the LEDs GPIOs and TPS).

I was actually wondering whether I was right in keeping some mux data in the SoC directory and was thinking of moving it back to the board dir. Strictly speaking mux data is board specific and I have already encountered a customer board that uses a different UART for traces. So essential, non_essential etc completely depends on the boards not SoCs. So, I am inclined to move it back to the board directories, because that will be more maintainable when more and more boards get added with conflicting mux definitions.

So, the arrays should be rather padconf_panda_common, padconf_4460panda, padconf_4430panda etc. and they should be all in their respective board directories.

What do you think?

br,
Aneesh

author
#5 lore raw

PATCH 3/3 omap4: splitting padconfs into common, 4430 and 4460

Hi Aneesh,

Quoted 17 lines · Aneesh V

Hi Ricardo,

Quoted 4 lines · Ricardo Salveti de Araujo

Not all padconfs are the same between 4430 and 4460, so instead of working around this with an if, we should have an specific padconf structure for both chips (like handling the differences between the LEDs GPIOs and TPS).

I was actually wondering whether I was right in keeping some mux data in the SoC directory and was thinking of moving it back to the board dir. Strictly speaking mux data is board specific and I have already encountered a customer board that uses a different UART for traces. So essential, non_essential etc completely depends on the boards not SoCs. So, I am inclined to move it back to the board directories, because that will be more maintainable when more and more boards get added with conflicting mux definitions.

Quoted 5 lines

So, the arrays should be rather padconf_panda_common, padconf_4460panda, padconf_4430panda etc. and they should be all in their respective board directories.

What do you think?

Sure, makes sense, and will also help once we start seeing more OMAP4 boards around.

Cheers,

Signature · 1 line
Ricardo Salveti de Araujo