[patch-v2.6.39 0/7] Patches for next merge window

[patch-v2.6.39 0/7] Patches for next merge window

[Felipe Balbi]

Hi Tony,

here are the patches for next merge window which I
have queued for you. A pull request is comming tomorrow.

All patches where boot tested on omap4430 pandaboard.

Anand Gadiyar (2):
  arm: omap4: usb: explicitly configure MUSB pads
  arm: omap4: 4430sdp: drop ehci support

Hema HK (5):
  OMAP2430: hwmod data: Add USBOTG
  OMAP3xxx: hwmod data: Add USBOTG
  AM35xx: hwmod data: Add USBOTG
  OMAP4430: hwmod data: Adding USBOTG
  OMAP2+: musb: hwmod adaptation for musb registration

 arch/arm/mach-omap2/board-4430sdp.c        |   19 ---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   98 ++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  166 ++++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   93 ++++++++++++++++
 arch/arm/mach-omap2/usb-musb.c             |  122 ++++++++++++++-------
 5 files changed, 440 insertions(+), 58 deletions(-)

-- 
1.7.4.rc2

[patch-v2.6.39 1/7] arm: omap4: usb: explicitly configure MUSB pads

[Felipe Balbi]

From: Anand Gadiyar <gadiyar@ti.com>

Use the mux framework APIs to explicitly configure
the MUSB pads. The MUSB controller in OMAP4 can use
either the old ULPI interface, or the new internal PHY.
Configure the pads accordingly.

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |   40 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 5298949..5a82b43 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -31,6 +31,7 @@
 #include <mach/am35xx.h>
 #include <plat/usb.h>
 #include "control.h"
+#include "mux.h"
 
 #if defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined (CONFIG_USB_MUSB_AM35X)
 
@@ -181,6 +182,43 @@ static struct platform_device musb_device = {
 	.resource	= musb_resources,
 };
 
+static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
+{
+	switch (board_data->interface_type) {
+	case MUSB_INTERFACE_UTMI:
+		omap_mux_init_signal("usba0_otg_dp", OMAP_PIN_INPUT);
+		omap_mux_init_signal("usba0_otg_dm", OMAP_PIN_INPUT);
+		break;
+	case MUSB_INTERFACE_ULPI:
+		omap_mux_init_signal("usba0_ulpiphy_clk",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_stp",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dir",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_nxt",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat0",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat1",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat2",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat3",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat4",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat5",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat6",
+						OMAP_PIN_INPUT_PULLDOWN);
+		omap_mux_init_signal("usba0_ulpiphy_dat7",
+						OMAP_PIN_INPUT_PULLDOWN);
+		break;
+	default:
+		break;
+	}
+}
 void __init usb_musb_init(struct omap_musb_board_data *board_data)
 {
 	if (cpu_is_omap243x()) {
@@ -199,6 +237,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.4.rc2

[patch-v2.6.39 2/7] arm: omap4: 4430sdp: drop ehci support

[Felipe Balbi]

From: Anand Gadiyar <gadiyar@ti.com>

Most revisions of the OMAP4 Blaze/SDP platform do not have
the EHCI signals routed by default. The pads are routed
for the alternate HSI functionality instead, and explicit
board modifications are needed to route the signals to
the USB PHY on the board.

Also, turning on the PHY connected to the EHCI port causes
a board reboot during bootup due to an unintended short
on the rails - this affects many initial revisions of the
board, and needs a minor board mod to fix (or as a
workaround, one should not attempt to power on the
USB PHY).

Given that these boards need explicit board mods to even
get EHCI working (separate from the accidental short above),
we should not attempt to enable EHCI by default.

So drop the EHCI support from the board files for the
Blaze/SDP platforms.

Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |   19 -------------------
 1 files changed, 0 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 07d1b20..674c183 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -44,7 +44,6 @@
 #define ETH_KS8851_IRQ			34
 #define ETH_KS8851_POWER_ON		48
 #define ETH_KS8851_QUART		138
-#define OMAP4SDP_MDM_PWR_EN_GPIO	157
 #define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO	184
 #define OMAP4_SFH7741_ENABLE_GPIO		188
 
@@ -251,16 +250,6 @@ static void __init omap_4430sdp_init_irq(void)
 	gic_init_irq();
 }
 
-static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
-	.port_mode[0]	= EHCI_HCD_OMAP_MODE_PHY,
-	.port_mode[1]	= EHCI_HCD_OMAP_MODE_UNKNOWN,
-	.port_mode[2]	= EHCI_HCD_OMAP_MODE_UNKNOWN,
-	.phy_reset	= false,
-	.reset_gpio_port[0]  = -EINVAL,
-	.reset_gpio_port[1]  = -EINVAL,
-	.reset_gpio_port[2]  = -EINVAL,
-};
-
 static struct omap_musb_board_data musb_board_data = {
 	.interface_type		= MUSB_INTERFACE_UTMI,
 	.mode			= MUSB_OTG,
@@ -576,14 +565,6 @@ static void __init omap_4430sdp_init(void)
 	omap_serial_init();
 	omap4_twl6030_hsmmc_init(mmc);
 
-	/* Power on the ULPI PHY */
-	status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
-	if (status)
-		pr_err("%s: Could not get USBB1 PHY GPIO\n", __func__);
-	else
-		gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
-
-	usb_ehci_init(&ehci_pdata);
 	usb_musb_init(&musb_board_data);
 
 	status = omap_ethernet_init();
-- 
1.7.4.rc2

[patch-v2.6.39 3/7] OMAP2430: hwmod data: Add USBOTG

[Felipe Balbi]

From: Hema HK <hemahk@ti.com>

OMAP2430 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and off-mode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when suspended.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   98 ++++++++++++++++++++++++++++
 1 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..76bbf8a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -89,6 +89,16 @@ static struct omap_hwmod omap2430_uart3_hwmod;
 static struct omap_hwmod omap2430_i2c1_hwmod;
 static struct omap_hwmod omap2430_i2c2_hwmod;
 
+static struct omap_hwmod omap2430_usbhsotg_hwmod;
+
+/* l3_core -> usbhsotg  interface */
+static struct omap_hwmod_ocp_if omap2430_usbhsotg__l3 = {
+	.master		= &omap2430_usbhsotg_hwmod,
+	.slave		= &omap2430_l3_main_hwmod,
+	.clk		= "core_l3_ck",
+	.user		= OCP_USER_MPU,
+};
+
 /* I2C IP block address space length (in bytes) */
 #define OMAP2_I2C_AS_LEN		128
 
@@ -189,6 +199,35 @@ static struct omap_hwmod_ocp_if omap2_l4_core__uart3 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/*
+* usbhsotg interface data
+*/
+static struct omap_hwmod_addr_space omap2430_usbhsotg_addrs[] = {
+	{
+		.pa_start	= OMAP243X_HS_BASE,
+		.pa_end		= OMAP243X_HS_BASE + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/*  l4_core ->usbhsotg  interface */
+static struct omap_hwmod_ocp_if omap2430_l4_core__usbhsotg = {
+	.master		= &omap2430_l4_core_hwmod,
+	.slave		= &omap2430_usbhsotg_hwmod,
+	.clk		= "usb_l4_ick",
+	.addr		= omap2430_usbhsotg_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap2430_usbhsotg_addrs),
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *omap2430_usbhsotg_masters[] = {
+	&omap2430_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *omap2430_usbhsotg_slaves[] = {
+	&omap2430_l4_core__usbhsotg,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = {
 	&omap2430_l3_main__l4_core,
@@ -919,6 +958,62 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
 	.flags		= HWMOD_NO_IDLEST,
 };
 
+/*
+ * usbhsotg
+ */
+static struct omap_hwmod_class_sysconfig omap2430_usbhsotg_sysc = {
+	.rev_offs	= 0x0400,
+	.sysc_offs	= 0x0404,
+	.syss_offs	= 0x0408,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+			  SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class usbotg_class = {
+	.name = "usbotg",
+	.sysc = &omap2430_usbhsotg_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap2430_usbhsotg_mpu_irqs[] = {
+
+	{ .name = "mc", .irq = 92 },
+	{ .name = "dma", .irq = 93 },
+};
+
+static struct omap_hwmod omap2430_usbhsotg_hwmod = {
+	.name		= "usb_otg_hs",
+	.mpu_irqs	= omap2430_usbhsotg_mpu_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap2430_usbhsotg_mpu_irqs),
+	.main_clk	= "usbhs_ick",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP2430_EN_USBHS_MASK,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_idle_bit = OMAP2430_ST_USBHS_SHIFT,
+		},
+	},
+	.masters	= omap2430_usbhsotg_masters,
+	.masters_cnt	= ARRAY_SIZE(omap2430_usbhsotg_masters),
+	.slaves		= omap2430_usbhsotg_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap2430_usbhsotg_slaves),
+	.class		= &usbotg_class,
+	/*
+	 * Erratum ID: i479  idle_req / idle_ack mechanism potentially
+	 * broken when autoidle is enabled
+	 * workaround is to disable the autoidle bit at module level.
+	 */
+	.flags		= HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
+				| HWMOD_SWSUP_MSTANDBY,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP2430)
+};
+
 static __initdata struct omap_hwmod *omap2430_hwmods[] = {
 	&omap2430_l3_main_hwmod,
 	&omap2430_l4_core_hwmod,
@@ -941,6 +1036,9 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
 
 	/* dma_system class*/
 	&omap2430_dma_system_hwmod,
+
+	/* usbotg class*/
+	&omap2430_usbhsotg_hwmod,
 	NULL,
 };
 
-- 
1.7.4.rc2

[patch-v2.6.39 4/7] OMAP3xxx: hwmod data: Add USBOTG

[Felipe Balbi]

From: Hema HK <hemahk@ti.com>

OMAP3 hwmod data structures are populated for USBOTG with base address,
L3 and L4 interface clocks, IRQs and sysconfig register details.
This is applicable for OMAP3430 amd OMAP3630.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags, framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  101 ++++++++++++++++++++++++++++
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..cce09fd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -107,6 +107,15 @@ static struct omap_hwmod omap3xxx_uart1_hwmod;
 static struct omap_hwmod omap3xxx_uart2_hwmod;
 static struct omap_hwmod omap3xxx_uart3_hwmod;
 static struct omap_hwmod omap3xxx_uart4_hwmod;
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod;
+
+/* l3_core -> usbhsotg interface */
+static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = {
+	.master		= &omap3xxx_usbhsotg_hwmod,
+	.slave		= &omap3xxx_l3_main_hwmod,
+	.clk		= "core_l3_ick",
+	.user		= OCP_USER_MPU,
+};
 
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
@@ -301,6 +310,36 @@ static struct omap_hwmod_ocp_if omap3_l4_core__sr2 = {
 	.user		= OCP_USER_MPU,
 };
 
+/*
+* usbhsotg interface data
+*/
+
+static struct omap_hwmod_addr_space omap3xxx_usbhsotg_addrs[] = {
+	{
+		.pa_start	= OMAP34XX_HSUSB_OTG_BASE,
+		.pa_end		= OMAP34XX_HSUSB_OTG_BASE + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> usbhsotg  */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__usbhsotg = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &omap3xxx_usbhsotg_hwmod,
+	.clk		= "l4_ick",
+	.addr		= omap3xxx_usbhsotg_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap3xxx_usbhsotg_addrs),
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_masters[] = {
+	&omap3xxx_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = {
+	&omap3xxx_l4_core__usbhsotg,
+};
+
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
 	&omap3xxx_l3_main__l4_core,
@@ -1356,6 +1395,64 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
 };
 
+/*
+ * usbhsotg
+ */
+static struct omap_hwmod_class_sysconfig omap3xxx_usbhsotg_sysc = {
+	.rev_offs	= 0x0400,
+	.sysc_offs	= 0x0404,
+	.syss_offs	= 0x0408,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+			  SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class usbotg_class = {
+	.name = "usbotg",
+	.sysc = &omap3xxx_usbhsotg_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap3xxx_usbhsotg_mpu_irqs[] = {
+
+	{ .name = "mc", .irq = 92 },
+	{ .name = "dma", .irq = 93 },
+};
+
+static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
+	.name		= "usb_otg_hs",
+	.mpu_irqs	= omap3xxx_usbhsotg_mpu_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap3xxx_usbhsotg_mpu_irqs),
+	.main_clk	= "hsotgusb_ick",
+	.prcm		= {
+		.omap2 = {
+			.prcm_reg_id = 1,
+			.module_bit = OMAP3430_EN_HSOTGUSB_SHIFT,
+			.module_offs = CORE_MOD,
+			.idlest_reg_id = 1,
+			.idlest_idle_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT,
+			.idlest_stdby_bit = OMAP3430ES2_ST_HSOTGUSB_STDBY_SHIFT
+		},
+	},
+	.masters	= omap3xxx_usbhsotg_masters,
+	.masters_cnt	= ARRAY_SIZE(omap3xxx_usbhsotg_masters),
+	.slaves		= omap3xxx_usbhsotg_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap3xxx_usbhsotg_slaves),
+	.class		= &usbotg_class,
+
+	/*
+	 * Erratum ID: i479  idle_req / idle_ack mechanism potentially
+	 * broken when autoidle is enabled
+	 * workaround is to disable the autoidle bit at module level.
+	 */
+	.flags		= HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
+				| HWMOD_SWSUP_MSTANDBY,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
+};
+
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_l3_main_hwmod,
 	&omap3xxx_l4_core_hwmod,
@@ -1387,6 +1484,10 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 
 	/* dma_system class*/
 	&omap3xxx_dma_system_hwmod,
+
+	/* usbotg class */
+	&omap3xxx_usbhsotg_hwmod,
+
 	NULL,
 };
 
-- 
1.7.4.rc2

[patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG

[Felipe Balbi]

From: Hema HK <hemahk@ti.com>

AM35xx hwmod data structures are populated for USBOTG with base address,
L3 and L4 interface clocks and IRQ.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   65 ++++++++++++++++++++++++++++
 1 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index cce09fd..b4cd8dd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -28,6 +28,7 @@
 #include "prm-regbits-34xx.h"
 #include "cm-regbits-34xx.h"
 #include "wd_timer.h"
+#include <mach/am35xx.h>
 
 /*
  * OMAP3xxx hardware module integration data
@@ -55,6 +56,8 @@ static struct omap_hwmod omap3xxx_gpio5_hwmod;
 static struct omap_hwmod omap3xxx_gpio6_hwmod;
 static struct omap_hwmod omap34xx_sr1_hwmod;
 static struct omap_hwmod omap34xx_sr2_hwmod;
+static struct omap_hwmod am35xx_usbhsotg_hwmod;
+
 
 static struct omap_hwmod omap3xxx_dma_system_hwmod;
 
@@ -117,6 +120,13 @@ static struct omap_hwmod_ocp_if omap3xxx_usbhsotg__l3 = {
 	.user		= OCP_USER_MPU,
 };
 
+/* l3_core -> am35xx_usbhsotg interface */
+static struct omap_hwmod_ocp_if am35xx_usbhsotg__l3 = {
+	.master		= &am35xx_usbhsotg_hwmod,
+	.slave		= &omap3xxx_l3_main_hwmod,
+	.clk		= "core_l3_ick",
+	.user		= OCP_USER_MPU,
+};
 /* L4_CORE -> L4_WKUP interface */
 static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup = {
 	.master	= &omap3xxx_l4_core_hwmod,
@@ -340,6 +350,31 @@ static struct omap_hwmod_ocp_if *omap3xxx_usbhsotg_slaves[] = {
 	&omap3xxx_l4_core__usbhsotg,
 };
 
+static struct omap_hwmod_addr_space am35xx_usbhsotg_addrs[] = {
+	{
+		.pa_start	= AM35XX_IPSS_USBOTGSS_BASE,
+		.pa_end		= AM35XX_IPSS_USBOTGSS_BASE + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_core -> usbhsotg  */
+static struct omap_hwmod_ocp_if am35xx_l4_core__usbhsotg = {
+	.master		= &omap3xxx_l4_core_hwmod,
+	.slave		= &am35xx_usbhsotg_hwmod,
+	.clk		= "l4_ick",
+	.addr		= am35xx_usbhsotg_addrs,
+	.addr_cnt	= ARRAY_SIZE(am35xx_usbhsotg_addrs),
+	.user		= OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if *am35xx_usbhsotg_masters[] = {
+	&am35xx_usbhsotg__l3,
+};
+
+static struct omap_hwmod_ocp_if *am35xx_usbhsotg_slaves[] = {
+	&am35xx_l4_core__usbhsotg,
+};
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
 	&omap3xxx_l3_main__l4_core,
@@ -1452,6 +1487,33 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
 				| HWMOD_SWSUP_MSTANDBY,
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
 };
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info am35xx_usbhsotg_mpu_irqs[] = {
+
+	{ .name = "mc", .irq = 71 },
+};
+
+static struct omap_hwmod_class am35xx_usbotg_class = {
+	.name = "am35xx_usbotg",
+	.sysc = NULL,
+};
+
+static struct omap_hwmod am35xx_usbhsotg_hwmod = {
+	.name		= "am35x_otg_hs",
+	.mpu_irqs	= am35xx_usbhsotg_mpu_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(am35xx_usbhsotg_mpu_irqs),
+	.main_clk	= NULL,
+	.prcm = {
+		.omap2 = {
+		},
+	},
+	.masters	= am35xx_usbhsotg_masters,
+	.masters_cnt	= ARRAY_SIZE(am35xx_usbhsotg_masters),
+	.slaves		= am35xx_usbhsotg_slaves,
+	.slaves_cnt	= ARRAY_SIZE(am35xx_usbhsotg_slaves),
+	.class		= &am35xx_usbotg_class,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1)
+};
 
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	&omap3xxx_l3_main_hwmod,
@@ -1488,6 +1550,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	/* usbotg class */
 	&omap3xxx_usbhsotg_hwmod,
 
+	/* usbotg for am35x */
+	&am35xx_usbhsotg_hwmod,
+
 	NULL,
 };
 
-- 
1.7.4.rc2

[patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
> Sent: Thursday, February 17, 2011 6:11 PM
> To: Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kalliguddi,
> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> 
> From: Hema HK <hemahk@ti.com>
> 
> AM35xx hwmod data structures are populated for USBOTG with base address,
> L3 and L4 interface clocks and IRQ.
> 
> Signed-off-by: Hema HK <hemahk@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Cousson, Benoit <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   65
> ++++++++++++++++++++++++++++
>  1 files changed, 65 insertions(+), 0 deletions(-)
> 
[snip]
> 
> +	/* usbotg for am35x */
> +	&am35xx_usbhsotg_hwmod,
> +
>  	NULL,

Felipe, Hema,

This patch will break all existing OMAP35x (and I believe
OMAP3430 - since there is no difference - unless there is
some trick in the USB driver code).

I have seen similar problems with smart reflex included in
the AM35x hwmod data.

In this case accessing "unknown" registers corresponding to
SmartReflex in _setup() causes crash.
(http://marc.info/?l=linux-omap&m=129777408503329&w=2)

I expect similar to be happening on OMAP35x with inclusion
of am35xx_usbhsotg_hwmod. If you don't see any crash, there
would be side-effects - and _setup() would be initializing
non-existent OTG registers on OMAP35x.

Did you see any problems while testing?

~sanjeev

PS: Sending mail via webmailer. Formatting may break

>  };
> 
> --
> 1.7.4.rc2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG

[Hema Kalliguddi]

Hi Premi,

>-----Original Message-----
>From: Premi, Sanjeev [mailto:premi at ti.com]
>Sent: Friday, February 18, 2011 4:59 PM
>To: Balbi, Felipe; Tony Lindgren
>Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
>Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
>Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>
>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
>> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
>> Sent: Thursday, February 17, 2011 6:11 PM
>> To: Tony Lindgren
>> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
>Kalliguddi,
>> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
>> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
>>
>> From: Hema HK <hemahk@ti.com>
>>
>> AM35xx hwmod data structures are populated for USBOTG with
>base address,
>> L3 and L4 interface clocks and IRQ.
>>
>> Signed-off-by: Hema HK <hemahk@ti.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>> Cc: Cousson, Benoit <b-cousson@ti.com>
>> Cc: Paul Walmsley <paul@pwsan.com>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   65
>> ++++++++++++++++++++++++++++
>>  1 files changed, 65 insertions(+), 0 deletions(-)
>>
>[snip]
>>
>> +	/* usbotg for am35x */
>> +	&am35xx_usbhsotg_hwmod,
>> +
>>  	NULL,
>
>Felipe, Hema,
>
>This patch will break all existing OMAP35x (and I believe
>OMAP3430 - since there is no difference - unless there is
>some trick in the USB driver code).
>

I agree that this will break the AM35x because there is no
separate CHIP_IS* defined for AM35x.
AM35x is treated as one of the version of OMAP3430.

>I have seen similar problems with smart reflex included in
>the AM35x hwmod data.

Unless the new CHIP_IS_* introduced for AM35x this problem will
still exists.

I thought you are already working on this because you were
asking the questions in the list.

>
>In this case accessing "unknown" registers corresponding to
>SmartReflex in _setup() causes crash.
>(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
>
>I expect similar to be happening on OMAP35x with inclusion
>of am35xx_usbhsotg_hwmod. If you don't see any crash, there
>would be side-effects - and _setup() would be initializing
>non-existent OTG registers on OMAP35x.
>
This will not impact for OMAP3 as the IDCODE is different AM35x and
OMAP3, so passing the right chip version in the HWMOD database for AM35x
will avoid the hwod init incase of OMAP3.

>Did you see any problems while testing?
>
I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see
the problem.

Regards,
Hema

>~sanjeev
>
>PS: Sending mail via webmailer. Formatting may break
>
>>  };
>>
>> --
>> 1.7.4.rc2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG

[Premi, Sanjeev]

> -----Original Message-----
> From: Kalliguddi, Hema
> Sent: Friday, February 18, 2011 6:37 PM
> To: Premi, Sanjeev; Balbi, Felipe; Tony Lindgren
> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List; Kevin Hilman;
> Cousson, Benoit; Paul Walmsley
> Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> 
> Hi Premi,
> 
> >-----Original Message-----
> >From: Premi, Sanjeev [mailto:premi at ti.com]
> >Sent: Friday, February 18, 2011 4:59 PM
> >To: Balbi, Felipe; Tony Lindgren
> >Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
> >Kalliguddi, Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley
> >Subject: RE: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> >
> >> -----Original Message-----
> >> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> >> owner at vger.kernel.org] On Behalf Of Balbi, Felipe
> >> Sent: Thursday, February 17, 2011 6:11 PM
> >> To: Tony Lindgren
> >> Cc: Linux OMAP Mailing List; Linux ARM Kernel Mailing List;
> >Kalliguddi,
> >> Hema; Kevin Hilman; Cousson, Benoit; Paul Walmsley; Balbi, Felipe
> >> Subject: [patch-v2.6.39 5/7] AM35xx: hwmod data: Add USBOTG
> >>
> >> From: Hema HK <hemahk@ti.com>
> >>
> >> AM35xx hwmod data structures are populated for USBOTG with
> >base address,
> >> L3 and L4 interface clocks and IRQ.
> >>
> >> Signed-off-by: Hema HK <hemahk@ti.com>
> >> Cc: Tony Lindgren <tony@atomide.com>
> >> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> >> Cc: Cousson, Benoit <b-cousson@ti.com>
> >> Cc: Paul Walmsley <paul@pwsan.com>
> >> Signed-off-by: Felipe Balbi <balbi@ti.com>
> >> ---
> >>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   65
> >> ++++++++++++++++++++++++++++
> >>  1 files changed, 65 insertions(+), 0 deletions(-)
> >>
> >[snip]
> >>
> >> +	/* usbotg for am35x */
> >> +	&am35xx_usbhsotg_hwmod,
> >> +
> >>  	NULL,
> >
> >Felipe, Hema,
> >
> >This patch will break all existing OMAP35x (and I believe
> >OMAP3430 - since there is no difference - unless there is
> >some trick in the USB driver code).
> >
> 
> I agree that this will break the AM35x because there is no
> separate CHIP_IS* defined for AM35x.
> AM35x is treated as one of the version of OMAP3430.
> 
> >I have seen similar problems with smart reflex included in
> >the AM35x hwmod data.
> 
> Unless the new CHIP_IS_* introduced for AM35x this problem will
> still exists.
> 
> I thought you are already working on this because you were
> asking the questions in the list.

[sp] Yes. I am working on it. Just responded to same query.

> 
> >
> >In this case accessing "unknown" registers corresponding to
> >SmartReflex in _setup() causes crash.
> >(http://marc.info/?l=linux-omap&m=129777408503329&w=2)
> >
> >I expect similar to be happening on OMAP35x with inclusion
> >of am35xx_usbhsotg_hwmod. If you don't see any crash, there
> >would be side-effects - and _setup() would be initializing
> >non-existent OTG registers on OMAP35x.
> >
> This will not impact for OMAP3 as the IDCODE is different AM35x and
> OMAP3, so passing the right chip version in the HWMOD database for AM35x
> will avoid the hwod init incase of OMAP3.

[sp] Are you saying that IDCODE is being used in HWMOD to prevent
     possible 'pollution' in the current implementation of
     am35xx_usbhsotg_hwmod?

> 
> >Did you see any problems while testing?
> >
> I tested with OMAP3430SDP and OMAP3630Zoom3 and did not see
> the problem.

[sp] Could this be due to difference in kind of processing done
     in _setup() for this hwmod. OR that addresses are (possibly)
     overlapping/ or not used?

     I suggest verifying this at the earliest.
> 
> Regards,
> Hema
> 
> >~sanjeev
> >
> >PS: Sending mail via webmailer. Formatting may break
> >
> >>  };
> >>
> >> --
> >> 1.7.4.rc2
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >linux-omap" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

From: Hema HK <hemahk@ti.com>

OMAP4 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.

Signed-off-by: Cousson, Benoit <b-cousson@ti.com>
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   93 ++++++++++++++++++++++++++++
 1 files changed, 93 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..a78e6d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -55,6 +55,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod;
 static struct omap_hwmod omap44xx_l4_wkup_hwmod;
 static struct omap_hwmod omap44xx_mpu_hwmod;
 static struct omap_hwmod omap44xx_mpu_private_hwmod;
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
 
 /*
  * Interconnects omap_hwmod structures
@@ -286,12 +287,21 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* usb_otg_hs -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = {
+	.master		= &omap44xx_usb_otg_hs_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "l3_div_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l3_main_2 slave ports */
 static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
 	&omap44xx_dma_system__l3_main_2,
 	&omap44xx_iva__l3_main_2,
 	&omap44xx_l3_main_1__l3_main_2,
 	&omap44xx_l4_cfg__l3_main_2,
+	&omap44xx_usb_otg_hs__l3_main_2,
 };
 
 static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
@@ -2001,6 +2011,87 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+/*
+ * 'usb_otg_hs' class
+ * high-speed on-the-go universal serial bus (usb_otg_hs) controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
+	.rev_offs	= 0x0400,
+	.sysc_offs	= 0x0404,
+	.syss_offs	= 0x0408,
+	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
+			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+			  SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = {
+	.name = "usb_otg_hs",
+	.sysc = &omap44xx_usb_otg_hs_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = {
+	{ .name = "mc", .irq = 92 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "dma", .irq = 93 + OMAP44XX_IRQ_GIC_START },
+};
+
+/* usb_otg_hs master ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = {
+	&omap44xx_usb_otg_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
+	{
+		.pa_start	= OMAP44XX_HSUSB_OTG_BASE,
+		.pa_end		= OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_cfg -> usb_otg_hs */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_otg_hs_hwmod,
+	.clk		= "l4_div_ck",
+	.addr		= omap44xx_usb_otg_hs_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* usb_otg_hs slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_otg_hs,
+};
+
+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
+	{ .role = "xclk", .clk = "otg_60m_gfclk_ck" },
+};
+
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
+	.name		= "usb_otg_hs",
+	.class		= &omap44xx_usb_otg_hs_hwmod_class,
+	.mpu_irqs	= omap44xx_usb_otg_hs_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_irqs),
+	.main_clk	= "usb_otg_hs_ick",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
+		},
+	},
+	.opt_clks	= usb_otg_hs_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks),
+	.slaves		= omap44xx_usb_otg_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_slaves),
+	.masters	= omap44xx_usb_otg_hs_masters,
+	.masters_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_masters),
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
 static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 
 	/* dmm class */
@@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_wd_timer2_hwmod,
 	&omap44xx_wd_timer3_hwmod,
 
+	/* hsusb otg class */
+	&omap44xx_usb_otg_hs_hwmod,
 	NULL,
 };
 
-- 
1.7.4.rc2

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

Hi Felipe and Hema,

Sorry for this late review, but I have a couple of comments on this one.

Since I was planning to send usb hwmod data file to Tony directly like I 
did for the other drivers, I can handle the update myself if you want.


On 2/17/2011 1:41 PM, Balbi, Felipe wrote:
> From: Hema HK<hemahk@ti.com>

The authorship is not correct. It should be me.

[...]

> +static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
> +	.rev_offs	= 0x0400,
> +	.sysc_offs	= 0x0404,
> +	.syss_offs	= 0x0408,
> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
> +			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
> +			  SYSC_HAS_AUTOIDLE),

These flags does not contains the latest reset flag 
(SYSS_HAS_RESET_STATUS) introduced in 2.6.37.

[...]

> +static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
> +	{
> +		.pa_start	= OMAP44XX_HSUSB_OTG_BASE,
> +		.pa_end		= OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,

You should not use the defines anymore, since the only user of the 
physical address should be this file.

[...]

> +static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
> +	{ .role = "xclk", .clk = "otg_60m_gfclk_ck" },

That optional clock does not exist anymore, it should be "usb_otg_hs_xclk".

[...]

> @@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
>   	&omap44xx_wd_timer2_hwmod,
>   	&omap44xx_wd_timer3_hwmod,
>
> +	/* hsusb otg class */
> +	&omap44xx_usb_otg_hs_hwmod,

"usb_otb_hs" should be before "wd_timer2".

For information, the updated version is below. It is based on rc5 + 
for_2.6.39/omap4_hwmod_data series I've just sent.

Regards,
Benoit


---
 From 5c2017f9405588127bf0b41f718409411d01abf8 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Thu, 17 Feb 2011 12:41:05 +0000
Subject: [PATCH] OMAP4430: hwmod data: Add USBOTG

OMAP4 hwmod data structures are populated with base address, L3 and L4
interface clocks, IRQs and sysconfig register details.

As per OMAP USBOTG specification, need to configure the USBOTG
to smart idle/standby or no idle/standby during data transfer and
force idle/standby when not in use to support retention and offmode.
By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework
will take care of configuring to no idle/standby when module is enabled
and force idle/standby when idled.

Signed-off-by: Cousson, Benoit <b-cousson@ti.com>
Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
[b-cousson at ti.com: Fix position, opt_clk, and author]
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   95 
++++++++++++++++++++++++++++
  1 files changed, 95 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 989bc96..b27e1e3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -62,6 +62,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod;
  static struct omap_hwmod omap44xx_mmc2_hwmod;
  static struct omap_hwmod omap44xx_mpu_hwmod;
  static struct omap_hwmod omap44xx_mpu_private_hwmod;
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;

  /*
   * Interconnects omap_hwmod structures
@@ -344,6 +345,14 @@ static struct omap_hwmod_ocp_if 
omap44xx_l4_cfg__l3_main_2 = {
  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
  };

+/* usb_otg_hs -> l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = {
+	.master		= &omap44xx_usb_otg_hs_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "l3_div_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
  /* l3_main_2 slave ports */
  static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
  	&omap44xx_dma_system__l3_main_2,
@@ -353,6 +362,7 @@ static struct omap_hwmod_ocp_if 
*omap44xx_l3_main_2_slaves[] = {
  	&omap44xx_iva__l3_main_2,
  	&omap44xx_l3_main_1__l3_main_2,
  	&omap44xx_l4_cfg__l3_main_2,
+	&omap44xx_usb_otg_hs__l3_main_2,
  };

  static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
@@ -4725,6 +4735,88 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
  };

  /*
+ * 'usb_otg_hs' class
+ * high-speed on-the-go universal serial bus (usb_otg_hs) controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
+	.rev_offs	= 0x0400,
+	.sysc_offs	= 0x0404,
+	.syss_offs	= 0x0408,
+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
+			   SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = {
+	.name = "usb_otg_hs",
+	.sysc = &omap44xx_usb_otg_hs_sysc,
+};
+
+/* usb_otg_hs */
+static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = {
+	{ .name = "mc", .irq = 92 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "dma", .irq = 93 + OMAP44XX_IRQ_GIC_START },
+};
+
+/* usb_otg_hs master ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = {
+	&omap44xx_usb_otg_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
+	{
+		.pa_start	= 0x4a0ab000,
+		.pa_end		= 0x4a0ab003,
+		.flags		= ADDR_TYPE_RT
+	},
+};
+
+/* l4_cfg -> usb_otg_hs */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_otg_hs_hwmod,
+	.clk		= "l4_div_ck",
+	.addr		= omap44xx_usb_otg_hs_addrs,
+	.addr_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_addrs),
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* usb_otg_hs slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_otg_hs,
+};
+
+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
+	{ .role = "xclk", .clk = "otg_60m_gfclk_ck" },
+};
+
+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
+	.name		= "usb_otg_hs",
+	.class		= &omap44xx_usb_otg_hs_hwmod_class,
+	.mpu_irqs	= omap44xx_usb_otg_hs_irqs,
+	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_irqs),
+	.main_clk	= "usb_otg_hs_ick",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_reg = OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
+		},
+	},
+	.opt_clks	= usb_otg_hs_opt_clks,
+	.opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks),
+	.slaves		= omap44xx_usb_otg_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_slaves),
+	.masters	= omap44xx_usb_otg_hs_masters,
+	.masters_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_masters),
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
   * 'wd_timer' class
   * 32-bit watchdog upward counter that generates a pulse on the reset 
pin on
   * overflow condition
@@ -4995,6 +5087,9 @@ static __initdata struct omap_hwmod 
*omap44xx_hwmods[] = {
  	&omap44xx_uart3_hwmod,
  	&omap44xx_uart4_hwmod,

+	/* usb_otg_hs class */
+	&omap44xx_usb_otg_hs_hwmod,
+
  	/* wd_timer class */
  	&omap44xx_wd_timer2_hwmod,
  	&omap44xx_wd_timer3_hwmod,
-- 
1.7.0.4

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Hema Kalliguddi]

Benoit,

>-----Original Message-----
>From: Cousson, Benoit [mailto:b-cousson at ti.com]
>Sent: Thursday, February 17, 2011 7:13 PM
>To: Balbi, Felipe
>Cc: Tony Lindgren; Linux OMAP Mailing List; Linux ARM Kernel
>Mailing List; Kalliguddi, Hema; Kevin Hilman; Paul Walmsley
>Subject: Re: [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
>
>Hi Felipe and Hema,
>
>Sorry for this late review, but I have a couple of comments on
>this one.
:-)....

>
>Since I was planning to send usb hwmod data file to Tony
>directly like I
>did for the other drivers, I can handle the update myself if you want.
>

I was not aware that you are sending the Hwmod patches for OMAP4
for all the drivers. Anyway I am OK with you sending the patch or
required I can also send it.

>
>On 2/17/2011 1:41 PM, Balbi, Felipe wrote:
>> From: Hema HK<hemahk@ti.com>
>
>The authorship is not correct. It should be me.
>
Yes. I agree. It is a mistake.
>[...]
>
>> +static struct omap_hwmod_class_sysconfig
>omap44xx_usb_otg_hs_sysc = {
>> +	.rev_offs	= 0x0400,
>> +	.sysc_offs	= 0x0404,
>> +	.syss_offs	= 0x0408,
>> +	.sysc_flags	= (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE|
>> +			  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
>> +			  SYSC_HAS_AUTOIDLE),
>
>These flags does not contains the latest reset flag
>(SYSS_HAS_RESET_STATUS) introduced in 2.6.37.
OK.
>
>[...]
>
>> +static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>> +	{
>> +		.pa_start	= OMAP44XX_HSUSB_OTG_BASE,
>> +		.pa_end		= OMAP44XX_HSUSB_OTG_BASE + SZ_4K - 1,
>
>You should not use the defines anymore, since the only user of the
>physical address should be this file.

Then we shlould be removing these defines right?
>
>[...]
>
>> +static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
>> +	{ .role = "xclk", .clk = "otg_60m_gfclk_ck" },
>
>That optional clock does not exist anymore, it should be
>"usb_otg_hs_xclk".
>
Since this clock is not enabled for musb as 60Mhz clock is external,
I did not notice this.

In your updated patch  below still the optional clock name is not changed.

>[...]
>
>> @@ -2068,6 +2159,8 @@ static __initdata struct omap_hwmod
>*omap44xx_hwmods[] = {
>>   	&omap44xx_wd_timer2_hwmod,
>>   	&omap44xx_wd_timer3_hwmod,
>>
>> +	/* hsusb otg class */
>> +	&omap44xx_usb_otg_hs_hwmod,
>
>"usb_otb_hs" should be before "wd_timer2".

Is this because of the automated scripts which generates the hwmod?
>
>For information, the updated version is below. It is based on rc5 +
>for_2.6.39/omap4_hwmod_data series I've just sent.

Regards,
Hema
>
>Regards,
>Benoit
>
>
>---
> From 5c2017f9405588127bf0b41f718409411d01abf8 Mon Sep 17 00:00:00 2001
>From: Benoit Cousson <b-cousson@ti.com>
>Date: Thu, 17 Feb 2011 12:41:05 +0000
>Subject: [PATCH] OMAP4430: hwmod data: Add USBOTG
>
>OMAP4 hwmod data structures are populated with base address, L3 and L4
>interface clocks, IRQs and sysconfig register details.
>
>As per OMAP USBOTG specification, need to configure the USBOTG
>to smart idle/standby or no idle/standby during data transfer and
>force idle/standby when not in use to support retention and offmode.
>By setting HWMOD_SWSUP_SIDLE and HWMOD_SWSUP_MSTANDBY flags,framework
>will take care of configuring to no idle/standby when module is enabled
>and force idle/standby when idled.
>
>Signed-off-by: Cousson, Benoit <b-cousson@ti.com>
>Signed-off-by: Hema HK <hemahk@ti.com>
>Cc: Tony Lindgren <tony@atomide.com>
>Cc: Kevin Hilman <khilman@deeprootsystems.com>
>Cc: Paul Walmsley <paul@pwsan.com>
>Signed-off-by: Felipe Balbi <balbi@ti.com>
>[b-cousson at ti.com: Fix position, opt_clk, and author]
>---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   95
>++++++++++++++++++++++++++++
>  1 files changed, 95 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>index 989bc96..b27e1e3 100644
>--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>@@ -62,6 +62,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod;
>  static struct omap_hwmod omap44xx_mmc2_hwmod;
>  static struct omap_hwmod omap44xx_mpu_hwmod;
>  static struct omap_hwmod omap44xx_mpu_private_hwmod;
>+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
>
>  /*
>   * Interconnects omap_hwmod structures
>@@ -344,6 +345,14 @@ static struct omap_hwmod_ocp_if
>omap44xx_l4_cfg__l3_main_2 = {
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
>
>+/* usb_otg_hs -> l3_main_2 */
>+static struct omap_hwmod_ocp_if omap44xx_usb_otg_hs__l3_main_2 = {
>+	.master		= &omap44xx_usb_otg_hs_hwmod,
>+	.slave		= &omap44xx_l3_main_2_hwmod,
>+	.clk		= "l3_div_ck",
>+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>+};
>+
>  /* l3_main_2 slave ports */
>  static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
>  	&omap44xx_dma_system__l3_main_2,
>@@ -353,6 +362,7 @@ static struct omap_hwmod_ocp_if
>*omap44xx_l3_main_2_slaves[] = {
>  	&omap44xx_iva__l3_main_2,
>  	&omap44xx_l3_main_1__l3_main_2,
>  	&omap44xx_l4_cfg__l3_main_2,
>+	&omap44xx_usb_otg_hs__l3_main_2,
>  };
>
>  static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
>@@ -4725,6 +4735,88 @@ static struct omap_hwmod
>omap44xx_uart4_hwmod = {
>  };
>
>  /*
>+ * 'usb_otg_hs' class
>+ * high-speed on-the-go universal serial bus (usb_otg_hs) controller
>+ */
>+
>+static struct omap_hwmod_class_sysconfig omap44xx_usb_otg_hs_sysc = {
>+	.rev_offs	= 0x0400,
>+	.sysc_offs	= 0x0404,
>+	.syss_offs	= 0x0408,
>+	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_ENAWAKEUP |
>+			   SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
>+			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
>+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE |
>MSTANDBY_NO |
>+			   MSTANDBY_SMART),
>+	.sysc_fields	= &omap_hwmod_sysc_type1,
>+};
>+
>+static struct omap_hwmod_class omap44xx_usb_otg_hs_hwmod_class = {
>+	.name = "usb_otg_hs",
>+	.sysc = &omap44xx_usb_otg_hs_sysc,
>+};
>+
>+/* usb_otg_hs */
>+static struct omap_hwmod_irq_info omap44xx_usb_otg_hs_irqs[] = {
>+	{ .name = "mc", .irq = 92 + OMAP44XX_IRQ_GIC_START },
>+	{ .name = "dma", .irq = 93 + OMAP44XX_IRQ_GIC_START },
>+};
>+
>+/* usb_otg_hs master ports */
>+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_masters[] = {
>+	&omap44xx_usb_otg_hs__l3_main_2,
>+};
>+
>+static struct omap_hwmod_addr_space omap44xx_usb_otg_hs_addrs[] = {
>+	{
>+		.pa_start	= 0x4a0ab000,
>+		.pa_end		= 0x4a0ab003,
>+		.flags		= ADDR_TYPE_RT
>+	},
>+};
>+
>+/* l4_cfg -> usb_otg_hs */
>+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_otg_hs = {
>+	.master		= &omap44xx_l4_cfg_hwmod,
>+	.slave		= &omap44xx_usb_otg_hs_hwmod,
>+	.clk		= "l4_div_ck",
>+	.addr		= omap44xx_usb_otg_hs_addrs,
>+	.addr_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_addrs),
>+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>+};
>+
>+/* usb_otg_hs slave ports */
>+static struct omap_hwmod_ocp_if *omap44xx_usb_otg_hs_slaves[] = {
>+	&omap44xx_l4_cfg__usb_otg_hs,
>+};
>+
>+static struct omap_hwmod_opt_clk usb_otg_hs_opt_clks[] = {
>+	{ .role = "xclk", .clk = "otg_60m_gfclk_ck" },
>+};
>+
>+static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
>+	.name		= "usb_otg_hs",
>+	.class		= &omap44xx_usb_otg_hs_hwmod_class,
>+	.mpu_irqs	= omap44xx_usb_otg_hs_irqs,
>+	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_irqs),
>+	.main_clk	= "usb_otg_hs_ick",
>+	.prcm = {
>+		.omap4 = {
>+			.clkctrl_reg =
>OMAP4430_CM_L3INIT_USB_OTG_CLKCTRL,
>+		},
>+	},
>+	.opt_clks	= usb_otg_hs_opt_clks,
>+	.opt_clks_cnt = ARRAY_SIZE(usb_otg_hs_opt_clks),
>+	.slaves		= omap44xx_usb_otg_hs_slaves,
>+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_slaves),
>+	.masters	= omap44xx_usb_otg_hs_masters,
>+	.masters_cnt	= ARRAY_SIZE(omap44xx_usb_otg_hs_masters),
>+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
>+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
>+};
>+
>+/*
>   * 'wd_timer' class
>   * 32-bit watchdog upward counter that generates a pulse on
>the reset
>pin on
>   * overflow condition
>@@ -4995,6 +5087,9 @@ static __initdata struct omap_hwmod
>*omap44xx_hwmods[] = {
>  	&omap44xx_uart3_hwmod,
>  	&omap44xx_uart4_hwmod,
>
>+	/* usb_otg_hs class */
>+	&omap44xx_usb_otg_hs_hwmod,
>+
>  	/* wd_timer class */
>  	&omap44xx_wd_timer2_hwmod,
>  	&omap44xx_wd_timer3_hwmod,
>--
>1.7.0.4
>
>

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> Hi Felipe and Hema,
> 
> Sorry for this late review, but I have a couple of comments on this one.
> 
> Since I was planning to send usb hwmod data file to Tony directly
> like I did for the other drivers, I can handle the update myself if
> you want.

I'll change this particular patch to yours.

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> > Hi Felipe and Hema,
> > 
> > Sorry for this late review, but I have a couple of comments on this one.
> > 
> > Since I was planning to send usb hwmod data file to Tony directly
> > like I did for the other drivers, I can handle the update myself if
> > you want.
> 
> I'll change this particular patch to yours.

doesn't apply:

$ patch -p1 < ~/benoit.diff 
patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
patch: **** malformed patch@line 42: omap44xx_l4_cfg__l3_main_2 = {

could you base this off of v2.6.38-rc5 ?

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
>> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
>>> Hi Felipe and Hema,
>>>
>>> Sorry for this late review, but I have a couple of comments on this one.
>>>
>>> Since I was planning to send usb hwmod data file to Tony directly
>>> like I did for the other drivers, I can handle the update myself if
>>> you want.
>>
>> I'll change this particular patch to yours.
>
> doesn't apply:
>
> $ patch -p1<  ~/benoit.diff
> patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
>
> could you base this off of v2.6.38-rc5 ?

This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch
in git://gitorious.org/omap-pm/linux.git.

Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> >>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> >>>Hi Felipe and Hema,
> >>>
> >>>Sorry for this late review, but I have a couple of comments on this one.
> >>>
> >>>Since I was planning to send usb hwmod data file to Tony directly
> >>>like I did for the other drivers, I can handle the update myself if
> >>>you want.
> >>
> >>I'll change this particular patch to yours.
> >
> >doesn't apply:
> >
> >$ patch -p1<  ~/benoit.diff
> >patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> >patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> >
> >could you base this off of v2.6.38-rc5 ?
> 
> This is what I was about to say.
> You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> in git://gitorious.org/omap-pm/linux.git.

I cannot have such a dependency and if you create that I can't send a
pull request to Tony otherwise we will have conflicts later. Either you
clear up that dependency or Tony will have to manually apply the patches
I have queued. It's only 7 of them anyway, so maybe not a big deal.

Tony, what do you prefer ? Do we clear out the dependency, or you queue
all the patches I have manually ??

A simple way to clear this out would be with a git rebase -i v2.6.38-rc5
and moving the MUSB HWMOD to be the first one in the series, then it
should apply cleanly on my tree.

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
>>> On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
>>>> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
>>>>> Hi Felipe and Hema,
>>>>>
>>>>> Sorry for this late review, but I have a couple of comments on this one.
>>>>>
>>>>> Since I was planning to send usb hwmod data file to Tony directly
>>>>> like I did for the other drivers, I can handle the update myself if
>>>>> you want.
>>>>
>>>> I'll change this particular patch to yours.
>>>
>>> doesn't apply:
>>>
>>> $ patch -p1<   ~/benoit.diff
>>> patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
>>> patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
>>>
>>> could you base this off of v2.6.38-rc5 ?
>>
>> This is what I was about to say.
>> You have a dependency with the for_2.6.39/omap4_hwmod_data branch
>> in git://gitorious.org/omap-pm/linux.git.
>
> I cannot have such a dependency and if you create that I can't send a
> pull request to Tony otherwise we will have conflicts later. Either you
> clear up that dependency or Tony will have to manually apply the patches
> I have queued. It's only 7 of them anyway, so maybe not a big deal.

I will try to rebase that one on v2.6.38-rc5 and see if it will generate 
any issue during the merge with the omap4_hwmod_data series. Generally 
issues appears if the data are located at the same place in the file. 
Since the usb is between uart and wd_timer, that might work.

Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110217 07:52]:
> On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> >>On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> >>>On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> >>>>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> >>>>>Hi Felipe and Hema,
> >>>>>
> >>>>>Sorry for this late review, but I have a couple of comments on this one.
> >>>>>
> >>>>>Since I was planning to send usb hwmod data file to Tony directly
> >>>>>like I did for the other drivers, I can handle the update myself if
> >>>>>you want.
> >>>>
> >>>>I'll change this particular patch to yours.
> >>>
> >>>doesn't apply:
> >>>
> >>>$ patch -p1<   ~/benoit.diff
> >>>patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >>>Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> >>>patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> >>>
> >>>could you base this off of v2.6.38-rc5 ?
> >>
> >>This is what I was about to say.
> >>You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> >>in git://gitorious.org/omap-pm/linux.git.
> >
> >I cannot have such a dependency and if you create that I can't send a
> >pull request to Tony otherwise we will have conflicts later. Either you
> >clear up that dependency or Tony will have to manually apply the patches
> >I have queued. It's only 7 of them anyway, so maybe not a big deal.
> 
> I will try to rebase that one on v2.6.38-rc5 and see if it will
> generate any issue during the merge with the omap4_hwmod_data
> series. Generally issues appears if the data are located at the same
> place in the file. Since the usb is between uart and wd_timer, that
> might work.

Maybe no need to rebase, I'll apply Benoit's series first into
omap-for-linus, then let's applying the other hwmod related patches
should be trivial.

Regards,

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> * Cousson, Benoit <b-cousson@ti.com> [110217 07:52]:
> > On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> > >On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> > >>On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> > >>>On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> > >>>>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> > >>>>>Hi Felipe and Hema,
> > >>>>>
> > >>>>>Sorry for this late review, but I have a couple of comments on this one.
> > >>>>>
> > >>>>>Since I was planning to send usb hwmod data file to Tony directly
> > >>>>>like I did for the other drivers, I can handle the update myself if
> > >>>>>you want.
> > >>>>
> > >>>>I'll change this particular patch to yours.
> > >>>
> > >>>doesn't apply:
> > >>>
> > >>>$ patch -p1<   ~/benoit.diff
> > >>>patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > >>>Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> > >>>patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> > >>>
> > >>>could you base this off of v2.6.38-rc5 ?
> > >>
> > >>This is what I was about to say.
> > >>You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> > >>in git://gitorious.org/omap-pm/linux.git.
> > >
> > >I cannot have such a dependency and if you create that I can't send a
> > >pull request to Tony otherwise we will have conflicts later. Either you
> > >clear up that dependency or Tony will have to manually apply the patches
> > >I have queued. It's only 7 of them anyway, so maybe not a big deal.
> > 
> > I will try to rebase that one on v2.6.38-rc5 and see if it will
> > generate any issue during the merge with the omap4_hwmod_data
> > series. Generally issues appears if the data are located at the same
> > place in the file. Since the usb is between uart and wd_timer, that
> > might work.
> 
> Maybe no need to rebase, I'll apply Benoit's series first into
> omap-for-linus, then let's applying the other hwmod related patches
> should be trivial.

So I can drop the omap4 HWMOD part from my branch ?

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [110217 08:20]:
> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> > 
> > Maybe no need to rebase, I'll apply Benoit's series first into
> > omap-for-linus, then let's applying the other hwmod related patches
> > should be trivial.
> 
> So I can drop the omap4 HWMOD part from my branch ?

Yeh assuming Benoit's data is correct.

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> * Felipe Balbi<balbi@ti.com>  [110217 08:20]:
>> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
>>>
>>> Maybe no need to rebase, I'll apply Benoit's series first into
>>> omap-for-linus, then let's applying the other hwmod related patches
>>> should be trivial.
>>
>> So I can drop the omap4 HWMOD part from my branch ?
>
> Yeh assuming Benoit's data is correct.

Of course, it is :-)

Then I will add USB in my series.

Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >* Felipe Balbi<balbi@ti.com>  [110217 08:20]:
> >>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>
> >>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>omap-for-linus, then let's applying the other hwmod related patches
> >>>should be trivial.
> >>
> >>So I can drop the omap4 HWMOD part from my branch ?
> >
> >Yeh assuming Benoit's data is correct.
> 
> Of course, it is :-)
> 
> Then I will add USB in my series.

Cool, my for-tony branch has been updated without OMAP4 HWMOD data.

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >* Felipe Balbi<balbi@ti.com>  [110217 08:20]:
> >>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>
> >>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>omap-for-linus, then let's applying the other hwmod related patches
> >>>should be trivial.
> >>
> >>So I can drop the omap4 HWMOD part from my branch ?
> >
> >Yeh assuming Benoit's data is correct.
> 
> Of course, it is :-)
> 
> Then I will add USB in my series.

BTW, which branch should I use from your tree to test ?

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
>>> * Felipe Balbi<balbi@ti.com>   [110217 08:20]:
>>>> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
>>>>>
>>>>> Maybe no need to rebase, I'll apply Benoit's series first into
>>>>> omap-for-linus, then let's applying the other hwmod related patches
>>>>> should be trivial.
>>>>
>>>> So I can drop the omap4 HWMOD part from my branch ?
>>>
>>> Yeh assuming Benoit's data is correct.
>>
>> Of course, it is :-)
>>
>> Then I will add USB in my series.
>
> BTW, which branch should I use from your tree to test ?

I'll put that in the refresh version of the branch I have done for Tony. 
I messed up the McSPI changelog... and Tony caught me :-)

I'll push that in 5 minutes.

Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 06:24:53PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> >>On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >>>* Felipe Balbi<balbi@ti.com>   [110217 08:20]:
> >>>>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>>>
> >>>>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>>>omap-for-linus, then let's applying the other hwmod related patches
> >>>>>should be trivial.
> >>>>
> >>>>So I can drop the omap4 HWMOD part from my branch ?
> >>>
> >>>Yeh assuming Benoit's data is correct.
> >>
> >>Of course, it is :-)
> >>
> >>Then I will add USB in my series.
> >
> >BTW, which branch should I use from your tree to test ?
> 
> I'll put that in the refresh version of the branch I have done for
> Tony. I messed up the McSPI changelog... and Tony caught me :-)
> 
> I'll push that in 5 minutes.

cool, let me know

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/17/2011 6:37 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 06:24:53PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
>>> On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
>>>> On 2/17/2011 5:59 PM, Tony Lindgren wrote:
>>>>> * Felipe Balbi<balbi@ti.com>    [110217 08:20]:
>>>>>> On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
>>>>>>>
>>>>>>> Maybe no need to rebase, I'll apply Benoit's series first into
>>>>>>> omap-for-linus, then let's applying the other hwmod related patches
>>>>>>> should be trivial.
>>>>>>
>>>>>> So I can drop the omap4 HWMOD part from my branch ?
>>>>>
>>>>> Yeh assuming Benoit's data is correct.
>>>>
>>>> Of course, it is :-)
>>>>
>>>> Then I will add USB in my series.
>>>
>>> BTW, which branch should I use from your tree to test ?
>>
>> I'll put that in the refresh version of the branch I have done for
>> Tony. I messed up the McSPI changelog... and Tony caught me :-)
>>
>> I'll push that in 5 minutes.
>
> cool, let me know

Done, boot tested, and that does remove the warning about the missing 
opt clock you had with the previous data.

git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data

Just let me know if it does break anything else.

Thanks,
Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 06:46:59PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 6:37 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 06:24:53PM +0100, Cousson, Benoit wrote:
> >>On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> >>>On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> >>>>On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> >>>>>* Felipe Balbi<balbi@ti.com>    [110217 08:20]:
> >>>>>>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> >>>>>>>
> >>>>>>>Maybe no need to rebase, I'll apply Benoit's series first into
> >>>>>>>omap-for-linus, then let's applying the other hwmod related patches
> >>>>>>>should be trivial.
> >>>>>>
> >>>>>>So I can drop the omap4 HWMOD part from my branch ?
> >>>>>
> >>>>>Yeh assuming Benoit's data is correct.
> >>>>
> >>>>Of course, it is :-)
> >>>>
> >>>>Then I will add USB in my series.
> >>>
> >>>BTW, which branch should I use from your tree to test ?
> >>
> >>I'll put that in the refresh version of the branch I have done for
> >>Tony. I messed up the McSPI changelog... and Tony caught me :-)
> >>
> >>I'll push that in 5 minutes.
> >
> >cool, let me know
> 
> Done, boot tested, and that does remove the warning about the missing
> opt clock you had with the previous data.
> 
> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> 
> Just let me know if it does break anything else.

Ok, pulling ;-)

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 07:52:17PM +0200, Felipe Balbi wrote:
> On Thu, Feb 17, 2011 at 06:46:59PM +0100, Cousson, Benoit wrote:
> > On 2/17/2011 6:37 PM, Balbi, Felipe wrote:
> > >On Thu, Feb 17, 2011 at 06:24:53PM +0100, Cousson, Benoit wrote:
> > >>On 2/17/2011 6:17 PM, Balbi, Felipe wrote:
> > >>>On Thu, Feb 17, 2011 at 06:14:24PM +0100, Cousson, Benoit wrote:
> > >>>>On 2/17/2011 5:59 PM, Tony Lindgren wrote:
> > >>>>>* Felipe Balbi<balbi@ti.com>    [110217 08:20]:
> > >>>>>>On Thu, Feb 17, 2011 at 08:20:01AM -0800, Tony Lindgren wrote:
> > >>>>>>>
> > >>>>>>>Maybe no need to rebase, I'll apply Benoit's series first into
> > >>>>>>>omap-for-linus, then let's applying the other hwmod related patches
> > >>>>>>>should be trivial.
> > >>>>>>
> > >>>>>>So I can drop the omap4 HWMOD part from my branch ?
> > >>>>>
> > >>>>>Yeh assuming Benoit's data is correct.
> > >>>>
> > >>>>Of course, it is :-)
> > >>>>
> > >>>>Then I will add USB in my series.
> > >>>
> > >>>BTW, which branch should I use from your tree to test ?
> > >>
> > >>I'll put that in the refresh version of the branch I have done for
> > >>Tony. I messed up the McSPI changelog... and Tony caught me :-)
> > >>
> > >>I'll push that in 5 minutes.
> > >
> > >cool, let me know
> > 
> > Done, boot tested, and that does remove the warning about the missing
> > opt clock you had with the previous data.
> > 
> > git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> > 
> > Just let me know if it does break anything else.
> 
> Ok, pulling ;-)

Just tested, all good ;-) Tomorrow I'll test more and send my pull
request.

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110217 09:45]:
> 
> Done, boot tested, and that does remove the warning about the
> missing opt clock you had with the previous data.
> 
> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> 
> Just let me know if it does break anything else.

Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
and devel-mcspi branches.

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 10:18:49AM -0800, Tony Lindgren wrote:
> * Cousson, Benoit <b-cousson@ti.com> [110217 09:45]:
> > 
> > Done, boot tested, and that does remove the warning about the
> > missing opt clock you had with the previous data.
> > 
> > git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> > 
> > Just let me know if it does break anything else.
> 
> Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
> and devel-mcspi branches.

Ok good. Tomorrow I'll send you a proper pull request for my part, will
leave testusb running over night.

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [110217 11:06]:
> On Thu, Feb 17, 2011 at 10:18:49AM -0800, Tony Lindgren wrote:
> > * Cousson, Benoit <b-cousson@ti.com> [110217 09:45]:
> > > 
> > > Done, boot tested, and that does remove the warning about the
> > > missing opt clock you had with the previous data.
> > > 
> > > git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> > > 
> > > Just let me know if it does break anything else.
> > 
> > Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
> > and devel-mcspi branches.
> 
> Ok good. Tomorrow I'll send you a proper pull request for my part, will
> leave testusb running over night.

OK sounds good to me.

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

Hi Tony

On 2/17/2011 7:18 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110217 09:45]:
>>
>> Done, boot tested, and that does remove the warning about the
>> missing opt clock you had with the previous data.
>>
>> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
>>
>> Just let me know if it does break anything else.
> 
> Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
> and devel-mcspi branches.

McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.

Govindraj should rebase on the omap4_hwmod_data branch and add the missing rev and dev_attr for the McSPI.

Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:

[    0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517
[    0.886657] usbcore: registered new interface driver usbfs
[    0.892822] usbcore: registered new interface driver hub
[    0.898681] usbcore: registered new device driver usb
[    0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz


Regards,
Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

Hi all,

On Fri, Feb 18, 2011 at 03:11:11PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 7:18 PM, Tony Lindgren wrote:
> > * Cousson, Benoit<b-cousson@ti.com>  [110217 09:45]:
> >>
> >> Done, boot tested, and that does remove the warning about the
> >> missing opt clock you had with the previous data.
> >>
> >> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
> >>
> >> Just let me know if it does break anything else.
> > 
> > Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
> > and devel-mcspi branches.
> 
> McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
> 
> Govindraj should rebase on the omap4_hwmod_data branch and add the missing rev and dev_attr for the McSPI.
> 
> Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
> 
> [    0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517
> [    0.886657] usbcore: registered new interface driver usbfs
> [    0.892822] usbcore: registered new interface driver hub
> [    0.898681] usbcore: registered new device driver usb
> [    0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz

I tested your branch merged with mine and it was working fine. What else
is on omap-for-linus ? There are only 28 patches on that branch, a
bisect would be quick ?

-- 
balbi

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

Hi Felipe,

On 2/18/2011 4:41 PM, Balbi, Felipe wrote:
> Hi all,
> 
> On Fri, Feb 18, 2011 at 03:11:11PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 7:18 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com>   [110217 09:45]:
>>>>
>>>> Done, boot tested, and that does remove the warning about the
>>>> missing opt clock you had with the previous data.
>>>>
>>>> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
>>>>
>>>> Just let me know if it does break anything else.
>>>
>>> Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
>>> and devel-mcspi branches.
>>
>> McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
>>
>> Govindraj should rebase on the omap4_hwmod_data branch and add the missing rev and dev_attr for the McSPI.
>>
>> Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
>>
>> [    0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517
>> [    0.886657] usbcore: registered new interface driver usbfs
>> [    0.892822] usbcore: registered new interface driver hub
>> [    0.898681] usbcore: registered new device driver usb
>> [    0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
> 
> I tested your branch merged with mine and it was working fine. What else
> is on omap-for-linus ? There are only 28 patches on that branch, a
> bisect would be quick ?

This is what I observed too. There are some early stuff in it + some TI816X... I do not know what is going wrong. 
Please note that there are a little bit more (47) stuff added but they are below the -rc5 tag... The bisect will be longer :-)

 + [HEAD^2] OMAP: runtime: McSPI driver runtime conversion
 + [HEAD^2^] OMAP: devices: Modify McSPI device to adapt to hwmod framework
 + [HEAD^2~2] OMAP3: hwmod data: Add McSPI
 + [HEAD^2~3] OMAP2430: hwmod data: Add McSPI
 + [HEAD^2~4] OMAP2420: hwmod data: Add McSPI
 + [HEAD^] omap: add hwspinlock device
 + [HEAD~2] drivers: hwspinlock: add OMAP implementation
 + [HEAD~3] drivers: hwspinlock: add framework
 + [HEAD~4^2] OMAP4: hwmod data: Add USBOTG
 + [HEAD~4^2^] OMAP4: hwmod data: Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU
 + [HEAD~4^2~2] OMAP4: hwmod data: Add McBSP
 + [HEAD~4^2~3] OMAP4: hwmod data: Add DMIC
 + [HEAD~4^2~4] OMAP4: hwmod data: Add mailbox
 + [HEAD~4^2~5] OMAP4: hwmod data: Add DSS, DISPC, DSI1&2, RFBI, HDMI and VENC
 + [HEAD~4^2~6] OMAP4: hwmod data: Add timer
 + [HEAD~4^2~7] OMAP4: hwmod data: Add McSPI
 + [HEAD~4^2~8] OMAP4: hwmod data: Add hwspinlock
 + [HEAD~5^3] TI816X: Update to use init_early
 + [HEAD~5^3^] TI816X: Add low level debug support
 + [HEAD~5^3~2] TI816X: Create board support and enable build for TI816X EVM
 + [HEAD~5^3~3] TI816X: Update common OMAP machine specific sources
 + [HEAD~5^3~4] TI816X: Update common omap platform files
 + [HEAD~5^3~5] omap: hwmod: Populate _mpu_rt_va later on in omap_hwmod_late_init
 + [HEAD~5^3~6] omap2+: Fix omap_serial_early_init to work with init_early hook
 + [HEAD~5^3~7] omap2+: Make omap_hwmod_late_init into core_initcall
 + [HEAD~5^3~8] ARM: OMAP2: use early init hook
 + [HEAD~5^2] omap: McBSP: Remove unused audio macros in mcbsp.h
 + [HEAD~5^2^] wip: fix section mismatches in omap1_defconfig
 + [HEAD~5^2~2] ARM: omap: move omap_board_config_kernel to .init.data
 + [HEAD~5^2~3] ARM: omap: move omap_get_config et al. to .init.text
 + [HEAD~5^2~4] ARM: omap1/nokia770: mark some functions __init
 + [HEAD~5^2~5] arm: mach-omap1: board-voiceblue: add missing include
 + [HEAD~5^2~6] ARM: OMAP: Allow platforms to hook reset cleanly
 + [HEAD~5^2~7] arm: mach-omap1: board-h3: make nand_platdata static
 + [HEAD~5^2~8] arm: mach-omap1: board-htcherald: make htcpld_chips and htcpld_pfdata static
 + [HEAD~5^2~9] arm: mach-omap1: board-innovator: make innovator_mmc_init() static
 + [HEAD~5^2~10] arm: mach-omap1: board-h2: make h2_nand_platdata static
 + [HEAD~5^2~11] arm: plat-omap: dma: make omap_dma_in_1510_mode() static
 + [HEAD~5^2~12] arm: omap2: irq: fix compile warning:
 + [HEAD~5^2~13] arm: omap1: fix a bunch of section mismatches
 + [HEAD~5^2~14] arm: omap1: fix compile warnings
 + [HEAD~5^2~15] arm: omap1: fix compile warning
 + [HEAD~5^2~16] arm: omap: i2c: fix compile warning
 + [HEAD~5^2~17] omap: Start using CONFIG_SOC_OMAP
++ [85e2efb] Linux 2.6.38-rc5


Regards,
Benoit

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/18/2011 4:41 PM, Balbi, Felipe wrote:
> Hi all,
>
> On Fri, Feb 18, 2011 at 03:11:11PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 7:18 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com>   [110217 09:45]:
>>>>
>>>> Done, boot tested, and that does remove the warning about the
>>>> missing opt clock you had with the previous data.
>>>>
>>>> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap4_hwmod_data
>>>>
>>>> Just let me know if it does break anything else.
>>>
>>> Pulled into omap-for-linus. Also now merged are the devel-hwspinlock
>>> and devel-mcspi branches.
>>
>> McSPI OMAP4 hwmod data are missing a couple of flags that break the boot for the moment.
>>
>> Govindraj should rebase on the omap4_hwmod_data branch and add the missing rev and dev_attr for the McSPI.
>>
>> Unfortunately, even with that patch omap-for-linus boot hangs after the following trace:
>>
>> [    0.875091] omap_device: omap2_mcspi.1: new worst case activate latency 0: 30517
>> [    0.886657] usbcore: registered new interface driver usbfs
>> [    0.892822] usbcore: registered new interface driver hub
>> [    0.898681] usbcore: registered new device driver usb
>> [    0.904815] omap_i2c omap_i2c.1: bus 1 rev4.0 at 400 kHz
>
> I tested your branch merged with mine and it was working fine. What else
> is on omap-for-linus ? There are only 28 patches on that branch, a
> bisect would be quick ?

This patch is at least fixing the McSPI crash. I still don't have a clue 
about the final hang :-(

Benoit

---
 From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 18 Feb 2011 14:01:06 +0100
Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI

- Add a rev attribute to identify various McSPI IP version.
- Add a dev_attr structure to provide the number of chipselect
   supported by the instance.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Govindraj.R <govindraj.raja@ti.com>
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   26 
++++++++++++++++++++++++++
  1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 84e795c..182aa79 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
  #include <plat/cpu.h>
  #include <plat/gpio.h>
  #include <plat/dma.h>
+#include <plat/mcspi.h>

  #include "omap_hwmod_common_data.h"

@@ -3114,6 +3115,7 @@ static struct omap_hwmod_class_sysconfig 
omap44xx_mcspi_sysc = {
  static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
  	.name	= "mcspi",
  	.sysc	= &omap44xx_mcspi_sysc,
+	.rev	= OMAP4_MCSPI_REV,
  };

  /* mcspi1 */
@@ -3156,6 +3158,11 @@ static struct omap_hwmod_ocp_if 
*omap44xx_mcspi1_slaves[] = {
  	&omap44xx_l4_per__mcspi1,
  };

+/* mcspi1 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi1_dev_attr = {
+	.num_chipselect	= 4,
+};
+
  static struct omap_hwmod omap44xx_mcspi1_hwmod = {
  	.name		= "mcspi1",
  	.class		= &omap44xx_mcspi_hwmod_class,
@@ -3169,6 +3176,7 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
  			.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
  		},
  	},
+	.dev_attr	= &mcspi1_dev_attr,
  	.slaves		= omap44xx_mcspi1_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap44xx_mcspi1_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3210,6 +3218,11 @@ static struct omap_hwmod_ocp_if 
*omap44xx_mcspi2_slaves[] = {
  	&omap44xx_l4_per__mcspi2,
  };

+/* mcspi2 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi2_dev_attr = {
+	.num_chipselect	= 2,
+};
+
  static struct omap_hwmod omap44xx_mcspi2_hwmod = {
  	.name		= "mcspi2",
  	.class		= &omap44xx_mcspi_hwmod_class,
@@ -3223,6 +3236,7 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
  			.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI2_CLKCTRL,
  		},
  	},
+	.dev_attr	= &mcspi2_dev_attr,
  	.slaves		= omap44xx_mcspi2_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap44xx_mcspi2_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3264,6 +3278,11 @@ static struct omap_hwmod_ocp_if 
*omap44xx_mcspi3_slaves[] = {
  	&omap44xx_l4_per__mcspi3,
  };

+/* mcspi3 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi3_dev_attr = {
+	.num_chipselect	= 2,
+};
+
  static struct omap_hwmod omap44xx_mcspi3_hwmod = {
  	.name		= "mcspi3",
  	.class		= &omap44xx_mcspi_hwmod_class,
@@ -3277,6 +3296,7 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
  			.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI3_CLKCTRL,
  		},
  	},
+	.dev_attr	= &mcspi3_dev_attr,
  	.slaves		= omap44xx_mcspi3_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap44xx_mcspi3_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
@@ -3316,6 +3336,11 @@ static struct omap_hwmod_ocp_if 
*omap44xx_mcspi4_slaves[] = {
  	&omap44xx_l4_per__mcspi4,
  };

+/* mcspi4 dev_attr */
+static struct omap2_mcspi_dev_attr mcspi4_dev_attr = {
+	.num_chipselect	= 1,
+};
+
  static struct omap_hwmod omap44xx_mcspi4_hwmod = {
  	.name		= "mcspi4",
  	.class		= &omap44xx_mcspi_hwmod_class,
@@ -3329,6 +3354,7 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
  			.clkctrl_reg = OMAP4430_CM_L4PER_MCSPI4_CLKCTRL,
  		},
  	},
+	.dev_attr	= &mcspi4_dev_attr,
  	.slaves		= omap44xx_mcspi4_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap44xx_mcspi4_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
-- 
1.7.0.4

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110218 08:49]:
> ---
> From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
> From: Benoit Cousson <b-cousson@ti.com>
> Date: Fri, 18 Feb 2011 14:01:06 +0100
> Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
> 
> - Add a rev attribute to identify various McSPI IP version.
> - Add a dev_attr structure to provide the number of chipselect
>   supported by the instance.

Looks like one seems to be wrapped and does not apply even after unwapping..

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/21/2011 7:22 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110218 08:49]:
>> ---
>>  From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
>> From: Benoit Cousson<b-cousson@ti.com>
>> Date: Fri, 18 Feb 2011 14:01:06 +0100
>> Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
>>
>> - Add a rev attribute to identify various McSPI IP version.
>> - Add a dev_attr structure to provide the number of chipselect
>>    supported by the instance.
> 
> Looks like one seems to be wrapped and does not apply even after unwapping..

#$*%&!@ Thunderbird...

Here is the same one without the "enable word wrap" and attached as well just in case.

It should apply on your omap-for-linus branch at commit df7ffd3.

Regards,
Benoit

---

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110221 13:35]:
> On 2/21/2011 7:22 PM, Tony Lindgren wrote:
> >* Cousson, Benoit<b-cousson@ti.com>  [110218 08:49]:
> >>---
> >> From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
> >>From: Benoit Cousson<b-cousson@ti.com>
> >>Date: Fri, 18 Feb 2011 14:01:06 +0100
> >>Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
> >>
> >>- Add a rev attribute to identify various McSPI IP version.
> >>- Add a dev_attr structure to provide the number of chipselect
> >>   supported by the instance.
> >
> >Looks like one seems to be wrapped and does not apply even after unwapping..
> 
> #$*%&!@ Thunderbird...

:) The earlier one had double spaces in the beginning of each line in
addition to the line wrapping..
 
> Here is the same one without the "enable word wrap" and attached as well just in case.
> 
> It should apply on your omap-for-linus branch at commit df7ffd3.

Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
caused by the timer patch, the following fixes it. How do you want
to deal with fixing this issue?

Tony


--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5094,7 +5094,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_spinlock_hwmod,
 
 	/* timer class */
-	&omap44xx_timer1_hwmod,
+/*	&omap44xx_timer1_hwmod, */
 	&omap44xx_timer2_hwmod,
 	&omap44xx_timer3_hwmod,
 	&omap44xx_timer4_hwmod,

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Cousson, Benoit]

On 2/21/2011 11:08 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com>  [110221 13:35]:
>> On 2/21/2011 7:22 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com>   [110218 08:49]:
>>>> ---
>>>>  From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
>>>> From: Benoit Cousson<b-cousson@ti.com>
>>>> Date: Fri, 18 Feb 2011 14:01:06 +0100
>>>> Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
>>>>
>>>> - Add a rev attribute to identify various McSPI IP version.
>>>> - Add a dev_attr structure to provide the number of chipselect
>>>>    supported by the instance.
>>>
>>> Looks like one seems to be wrapped and does not apply even after unwapping..
>>
>> #$*%&!@ Thunderbird...
>
> :) The earlier one had double spaces in the beginning of each line in
> addition to the line wrapping..

...The Thunderbird wrapping option is more powerful than expected...

>> Here is the same one without the "enable word wrap" and attached as well just in case.
>>
>> It should apply on your omap-for-linus branch at commit df7ffd3.
>
> Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
> caused by the timer patch, the following fixes it. How do you want
> to deal with fixing this issue?

I guess it is due to the early_init change?

I have some concern bypassing hwmod to handle system timer. The idea, 
before the introduction of the early_init, was to use hwmod for early 
initialization as well including timers. It will become a little bit 
harder now :-(

I still didn't fully understand the rational behind that early_init for 
timer BTW.

Meanwhile, the following will just prevent the fmwk to reset and idle 
the timer during hwmod_init.

Regards,
Benoit


--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if 
*omap44xx_timer1_slaves[] = {
  static struct omap_hwmod omap44xx_timer1_hwmod = {
  	.name		= "timer1",
  	.class		= &omap44xx_timer_1ms_hwmod_class,
+	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
  	.mpu_irqs	= omap44xx_timer1_irqs,
  	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
  	.main_clk	= "timer1_fck",

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110221 14:51]:
> On 2/21/2011 11:08 PM, Tony Lindgren wrote:
> >
> >Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
> >caused by the timer patch, the following fixes it. How do you want
> >to deal with fixing this issue?
> 
> I guess it is due to the early_init change?

Yes that seems to be the case.
 
> I have some concern bypassing hwmod to handle system timer. The
> idea, before the introduction of the early_init, was to use hwmod
> for early initialization as well including timers. It will become a
> little bit harder now :-(

If we get rid of the system timer dependency to hwmod we can
pretty much initialize everything later on and don't need to
use early_init stuff at all.
 
> I still didn't fully understand the rational behind that early_init
> for timer BTW.

I'm currently thinking that we should just have omap[234]_init_timer
functions that do not depend on hwmod at all.
 
> Meanwhile, the following will just prevent the fmwk to reset and
> idle the timer during hwmod_init.

That seems like a good to fix for now until the hwmod timer
changes are sorted out.

Tony

> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
> *omap44xx_timer1_slaves[] = {
>  static struct omap_hwmod omap44xx_timer1_hwmod = {
>  	.name		= "timer1",
>  	.class		= &omap44xx_timer_1ms_hwmod_class,
> +	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
>  	.mpu_irqs	= omap44xx_timer1_irqs,
>  	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
>  	.main_clk	= "timer1_fck",
> 

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Russell King - ARM Linux]

On Mon, Feb 21, 2011 at 11:53:00PM +0100, Cousson, Benoit wrote:
> I still didn't fully understand the rational behind that early_init for  
> timer BTW.

To ensure that sched_clock() is setup and running before its first use.

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Paul Walmsley]

On Mon, 21 Feb 2011, Cousson, Benoit wrote:

> Meanwhile, the following will just prevent the fmwk to reset and idle the
> timer during hwmod_init.
> 
> Regards,
> Benoit

Looks okay to me for the time being.

Acked-by: Paul Walmsley <paul@pwsan.com>

> 
> 
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
> *omap44xx_timer1_slaves[] = {
>  static struct omap_hwmod omap44xx_timer1_hwmod = {
>  	.name		= "timer1",
>  	.class		= &omap44xx_timer_1ms_hwmod_class,
> +	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
>  	.mpu_irqs	= omap44xx_timer1_irqs,
>  	.mpu_irqs_cnt	= ARRAY_SIZE(omap44xx_timer1_irqs),
>  	.main_clk	= "timer1_fck",
> 


- Paul

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Tony Lindgren]

* Felipe Balbi <balbi@ti.com> [110217 07:25]:
> 
> Tony, what do you prefer ? Do we clear out the dependency, or you queue
> all the patches I have manually ??

Let's apply Benoit's hwmod data patches first into omap-for-linus,
then rebasing other patches to that should be trivial and I can
pull in your patches.

Regards,

Tony

[patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG

[Felipe Balbi]

On Thu, Feb 17, 2011 at 08:21:57AM -0800, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [110217 07:25]:
> > 
> > Tony, what do you prefer ? Do we clear out the dependency, or you queue
> > all the patches I have manually ??
> 
> Let's apply Benoit's hwmod data patches first into omap-for-linus,
> then rebasing other patches to that should be trivial and I can
> pull in your patches.

ok, let me know and I'll rebase on top of omap-for-linus.

-- 
balbi

[patch-v2.6.39 7/7] OMAP2+: musb: hwmod adaptation for musb registration

[Felipe Balbi]

From: Hema HK <hemahk@ti.com>

Using omap_device_build API instead of platform_device_register for
OMAP2430,OMAP3xxx, OMAP4430 and AM35x musb device registration.
The device specific resources defined in centralized
database will be used.

Signed-off-by: Hema HK <hemahk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |   84 +++++++++++++++++++++-------------------
 1 files changed, 44 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 5a82b43..b089ea4 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -30,6 +30,7 @@
 #include <mach/irqs.h>
 #include <mach/am35xx.h>
 #include <plat/usb.h>
+#include <plat/omap_device.h>
 #include "control.h"
 #include "mux.h"
 
@@ -127,22 +128,6 @@ static void am35x_musb_set_mode(u8 musb_mode)
 	omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 }
 
-static struct resource musb_resources[] = {
-	[0] = { /* start and end set dynamically */
-		.flags	= IORESOURCE_MEM,
-	},
-	[1] = {	/* general IRQ */
-		.start	= INT_243X_HS_USB_MC,
-		.flags	= IORESOURCE_IRQ,
-		.name	= "mc",
-	},
-	[2] = {	/* DMA IRQ */
-		.start	= INT_243X_HS_USB_DMA,
-		.flags	= IORESOURCE_IRQ,
-		.name	= "dma",
-	},
-};
-
 static struct musb_hdrc_config musb_config = {
 	.multipoint	= 1,
 	.dyn_fifo	= 1,
@@ -170,16 +155,12 @@ static struct musb_hdrc_platform_data musb_plat = {
 
 static u64 musb_dmamask = DMA_BIT_MASK(32);
 
-static struct platform_device musb_device = {
-	.name		= "musb-omap2430",
-	.id		= -1,
-	.dev = {
-		.dma_mask		= &musb_dmamask,
-		.coherent_dma_mask	= DMA_BIT_MASK(32),
-		.platform_data		= &musb_plat,
+static struct omap_device_pm_latency omap_musb_latency[] = {
+	{
+		.deactivate_func	= omap_device_idle_hwmods,
+		.activate_func		= omap_device_enable_hwmods,
+		.flags			= OMAP_DEVICE_LATENCY_AUTO_ADJUST,
 	},
-	.num_resources	= ARRAY_SIZE(musb_resources),
-	.resource	= musb_resources,
 };
 
 static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
@@ -219,28 +200,24 @@ static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
 		break;
 	}
 }
+
 void __init usb_musb_init(struct omap_musb_board_data *board_data)
 {
-	if (cpu_is_omap243x()) {
-		musb_resources[0].start = OMAP243X_HS_BASE;
-	} else if (cpu_is_omap3517() || cpu_is_omap3505()) {
-		musb_device.name = "musb-am35x";
-		musb_resources[0].start = AM35XX_IPSS_USBOTGSS_BASE;
-		musb_resources[1].start = INT_35XX_USBOTG_IRQ;
+	struct omap_hwmod		*oh;
+	struct omap_device		*od;
+	struct platform_device		*pdev;
+	struct device			*dev;
+	int				bus_id = -1;
+	const char			*oh_name, *name;
+
+	if (cpu_is_omap3517() || cpu_is_omap3505()) {
 		board_data->set_phy_power = am35x_musb_phy_power;
 		board_data->clear_irq = am35x_musb_clear_irq;
 		board_data->set_mode = am35x_musb_set_mode;
 		board_data->reset = am35x_musb_reset;
-	} else if (cpu_is_omap34xx()) {
-		musb_resources[0].start = OMAP34XX_HSUSB_OTG_BASE;
 	} else if (cpu_is_omap44xx()) {
-		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;
 
 	/*
 	 * REVISIT: This line can be removed once all the platforms using
@@ -252,8 +229,35 @@ void __init usb_musb_init(struct omap_musb_board_data *board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (platform_device_register(&musb_device) < 0)
-		printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n");
+	if (cpu_is_omap3517() || cpu_is_omap3505()) {
+		oh_name = "am35x_otg_hs";
+		name = "musb-am35x";
+	} else {
+		oh_name = "usb_otg_hs";
+		name = "musb-omap2430";
+	}
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("Could not look up %s\n", oh_name);
+		return;
+	}
+
+	od = omap_device_build(name, bus_id, oh, &musb_plat,
+			       sizeof(musb_plat), omap_musb_latency,
+			       ARRAY_SIZE(omap_musb_latency), false);
+	if (IS_ERR(od)) {
+		pr_err("Could not build omap_device for %s %s\n",
+						name, oh_name);
+		return;
+	}
+
+	pdev = &od->pdev;
+	dev = &pdev->dev;
+	get_device(dev);
+	dev->dma_mask = &musb_dmamask;
+	dev->coherent_dma_mask = musb_dmamask;
+	put_device(dev);
 }
 
 #else
-- 
1.7.4.rc2