[PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Keshava Munegowda]

From: Benoit Cousson <b-cousson@ti.com>

Following 2 hwmod structures are added
1. usb_host_hs
     The hwmod of usbhs with uhh, ehci and ohci base addresses
     functional clock and ehci, ohci irqs

2. usb_tll_hs
      hwmod of usbhs with the TLL base address and irq.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>

- rebased to kernel version 3.0
- Workarounds for hardware issues

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  206 +++++++++++++++++++++++++++-
 1 files changed, 205 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..e404fd6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,8 @@ 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;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
 
 /*
  * Interconnects omap_hwmod structures
@@ -5336,6 +5338,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
 
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+	.master		= &omap44xx_usb_host_hs_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "l3_div_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+	.name = "usb_host_hs",
+	.sysc = &omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+	&omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+	{
+		.name		= "uhh",
+		.pa_start	= 0x4a064000,
+		.pa_end		= 0x4a0647ff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.name		= "ohci",
+		.pa_start	= 0x4a064800,
+		.pa_end		= 0x4a064bff,
+	},
+	{
+		.name		= "ehci",
+		.pa_start	= 0x4a064c00,
+		.pa_end		= 0x4a064fff,
+	},
+	{}
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+	{ .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "ehci-irq", .irq = 77 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_host_hs_hwmod,
+	.clk		= "l4_div_ck",
+	.addr		= omap44xx_usb_host_hs_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+	.name		= "usb_host_hs",
+	.class		= &omap44xx_usb_host_hs_hwmod_class,
+	.clkdm_name	= "l3_init_clkdm",
+	.main_clk	= "usb_host_hs_fck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+			.context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_usb_host_hs_irqs,
+	.slaves		= omap44xx_usb_host_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+	.masters	= omap44xx_usb_host_hs_masters,
+	.masters_cnt	= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+/*
+ *	Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+ *	id: i660
+ *
+ *	Description:
+ *	In the following configuration :
+ *	- USBHOST module is set to smart-idle mode
+ *	- PRCM asserts idle_req to the USBHOST module ( This typically happens
+ *	  when the system is going to a low power mode : all ports have been
+ *	  suspended, the master part of the USBHOST module has entered the
+ *	  standby state, and SW has cut the functional clocks.)
+ *	- an USBHOST interrupt occurs before the module is able to answer
+ *	  idle_ack, typically a remote wakeup IRQ.
+ *	Then the USB HOST module will enter a deadlock situation where it is no
+ *	more accessible nor functional.
+ *
+ *	Workaround:
+ *	Don't use smart idle; use only force idle, hence HWMOD_SWSUP_SIDLE
+ */
+
+/*	Errata: USB host EHCI may stall when entering smart-standby mode
+ *	Id: i571
+ *
+ *	Description:
+ *	When the USBHOST module is set to smart-standby mode, and when it is
+ *	ready to enter the standby state (i.e. all ports are suspended and
+ *	all attached devices are in suspend mode), then it can wrongly assert
+ *	the Mstandby signal too early while there are still some residual OCP
+ *	transactions ongoing. If this condition occurs, the internal state
+ *	machine may go to an undefined state and the USB link may be stuck
+ *	upon the next resume.
+ *
+ *	Workaround:
+ *	Don't use smart standby; use only force standby,
+ *	hence HWMOD_SWSUP_MSTANDBY
+ */
+
+/*	During system boot; If the hwmod framework resets the module
+ *	the module will have smart idle settings; which can lead to deadlock
+ *	(above Errata Id:i660); so, dont reset the module during boot;
+ *	Use HWMOD_INIT_NO_RESET.
+ */
+
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+			  HWMOD_INIT_NO_RESET,
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+			   SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_tll_hs_hwmod_class = {
+	.name = "usb_tll_hs",
+	.sysc = &omap44xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_tll_hs_irqs[] = {
+	{ .name = "tll-irq", .irq = 78 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_tll_hs_addrs[] = {
+	{
+		.name		= "tll",
+		.pa_start	= 0x4a062000,
+		.pa_end		= 0x4a063fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_tll_hs_hwmod,
+	.addr		= omap44xx_usb_tll_hs_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_tll_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
+	.name		= "usb_tll_hs",
+	.class		= &omap44xx_usb_tll_hs_hwmod_class,
+	.clkdm_name	= "l3_init_clkdm",
+	.main_clk	= "usb_tll_hs_ick",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET,
+			.context_offs = OMAP4_RM_L3INIT_USB_TLL_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_usb_tll_hs_irqs,
+	.slaves		= omap44xx_usb_tll_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
+	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
 static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 
 	/* dmm class */
@@ -5475,13 +5676,16 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_uart3_hwmod,
 	&omap44xx_uart4_hwmod,
 
+	/* usb host class */
+	&omap44xx_usb_host_hs_hwmod,
+	&omap44xx_usb_tll_hs_hwmod,
+
 	/* usb_otg_hs class */
 	&omap44xx_usb_otg_hs_hwmod,
 
 	/* wd_timer class */
 	&omap44xx_wd_timer2_hwmod,
 	&omap44xx_wd_timer3_hwmod,
-
 	NULL,
 };
 
-- 
1.6.0.4

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

On Thu, 6 Oct 2011, Keshava Munegowda wrote:

> From: Benoit Cousson <b-cousson@ti.com>
> 
> Following 2 hwmod structures are added
> 1. usb_host_hs
>      The hwmod of usbhs with uhh, ehci and ohci base addresses
>      functional clock and ehci, ohci irqs
> 
> 2. usb_tll_hs
>       hwmod of usbhs with the TLL base address and irq.
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> 
> - rebased to kernel version 3.0
> - Workarounds for hardware issues
> 
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
> Reviewed-by: Partha Basak <parthab@india.ti.com>

A few minor issues in this patch have been fixed.  Please be careful with 
whitespace and with multi-line comment style - see 
Documentation/CodingStyle for more information.


- Paul

>From fdf7c66244af5ca5ba4cdc820f7644efb9f6c1bf Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 7 Oct 2011 02:40:51 -0600
Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap4

Following 2 hwmod structures are added
1. usb_host_hs
     The hwmod of usbhs with uhh, ehci and ohci base addresses
     functional clock and ehci, ohci irqs

2. usb_tll_hs
      hwmod of usbhs with the TLL base address and irq.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>

- rebased to kernel version 3.0
- Workarounds for hardware issues

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Reviewed-by: Partha Basak <parthab@india.ti.com>
[paul@pwsan.com: fixed whitespace, fixed multi-line comment style]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  206 +++++++++++++++++++++++++++-
 1 files changed, 205 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index caaf409..6149407 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,8 @@ 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;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
 
 /*
  * Interconnects omap_hwmod structures
@@ -5254,6 +5256,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.slaves_cnt	= ARRAY_SIZE(omap44xx_wd_timer3_slaves),
 };
 
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+	.master		= &omap44xx_usb_host_hs_hwmod,
+	.slave		= &omap44xx_l3_main_2_hwmod,
+	.clk		= "l3_div_ck",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_SOFTRESET),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+			   SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+			   MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+	.name = "usb_host_hs",
+	.sysc = &omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+	&omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+	{
+		.name		= "uhh",
+		.pa_start	= 0x4a064000,
+		.pa_end		= 0x4a0647ff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{
+		.name		= "ohci",
+		.pa_start	= 0x4a064800,
+		.pa_end		= 0x4a064bff,
+	},
+	{
+		.name		= "ehci",
+		.pa_start	= 0x4a064c00,
+		.pa_end		= 0x4a064fff,
+	},
+	{}
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
+	{ .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
+	{ .name = "ehci-irq", .irq = 77 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_host_hs_hwmod,
+	.clk		= "l4_div_ck",
+	.addr		= omap44xx_usb_host_hs_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+	.name		= "usb_host_hs",
+	.class		= &omap44xx_usb_host_hs_hwmod_class,
+	.clkdm_name	= "l3_init_clkdm",
+	.main_clk	= "usb_host_hs_fck",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+			.context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_usb_host_hs_irqs,
+	.slaves		= omap44xx_usb_host_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+	.masters	= omap44xx_usb_host_hs_masters,
+	.masters_cnt	= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+/*
+ *	Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+ *	id: i660
+ *
+ *	Description:
+ *	In the following configuration :
+ *	- USBHOST module is set to smart-idle mode
+ *	- PRCM asserts idle_req to the USBHOST module ( This typically happens
+ *	  when the system is going to a low power mode : all ports have been
+ *	  suspended, the master part of the USBHOST module has entered the
+ *	  standby state, and SW has cut the functional clocks.)
+ *	- an USBHOST interrupt occurs before the module is able to answer
+ *	  idle_ack, typically a remote wakeup IRQ.
+ *	Then the USB HOST module will enter a deadlock situation where it is no
+ *	more accessible nor functional.
+ *
+ *	Workaround:
+ *	Don't use smart idle; use only force idle, hence HWMOD_SWSUP_SIDLE
+ */
+
+/*
+ *	Errata: USB host EHCI may stall when entering smart-standby mode
+ *	Id: i571
+ *
+ *	Description:
+ *	When the USBHOST module is set to smart-standby mode, and when it is
+ *	ready to enter the standby state (i.e. all ports are suspended and
+ *	all attached devices are in suspend mode), then it can wrongly assert
+ *	the Mstandby signal too early while there are still some residual OCP
+ *	transactions ongoing. If this condition occurs, the internal state
+ *	machine may go to an undefined state and the USB link may be stuck
+ *	upon the next resume.
+ *
+ *	Workaround:
+ *	Don't use smart standby; use only force standby,
+ *	hence HWMOD_SWSUP_MSTANDBY
+ */
+
+/*
+ *	During system boot; If the hwmod framework resets the module
+ *	the module will have smart idle settings; which can lead to deadlock
+ *	(above Errata Id:i660); so, dont reset the module during boot;
+ *	Use HWMOD_INIT_NO_RESET.
+ */
+
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+			  HWMOD_INIT_NO_RESET,
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
+	.rev_offs	= 0x0000,
+	.sysc_offs	= 0x0010,
+	.syss_offs	= 0x0014,
+	.sysc_flags	= (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+			   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+			   SYSC_HAS_AUTOIDLE),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_usb_tll_hs_hwmod_class = {
+	.name = "usb_tll_hs",
+	.sysc = &omap44xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod_irq_info omap44xx_usb_tll_hs_irqs[] = {
+	{ .name = "tll-irq", .irq = 78 + OMAP44XX_IRQ_GIC_START },
+	{ .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_tll_hs_addrs[] = {
+	{
+		.name		= "tll",
+		.pa_start	= 0x4a062000,
+		.pa_end		= 0x4a063fff,
+		.flags		= ADDR_TYPE_RT
+	},
+	{}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
+	.master		= &omap44xx_l4_cfg_hwmod,
+	.slave		= &omap44xx_usb_tll_hs_hwmod,
+	.addr		= omap44xx_usb_tll_hs_addrs,
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_tll_hs_slaves[] = {
+	&omap44xx_l4_cfg__usb_tll_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
+	.name		= "usb_tll_hs",
+	.class		= &omap44xx_usb_tll_hs_hwmod_class,
+	.clkdm_name	= "l3_init_clkdm",
+	.main_clk	= "usb_tll_hs_ick",
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET,
+			.context_offs = OMAP4_RM_L3INIT_USB_TLL_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+	.mpu_irqs	= omap44xx_usb_tll_hs_irqs,
+	.slaves		= omap44xx_usb_tll_hs_slaves,
+	.slaves_cnt	= ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
+};
+
 static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 
 	/* dmm class */
@@ -5393,13 +5594,16 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
 	&omap44xx_uart3_hwmod,
 	&omap44xx_uart4_hwmod,
 
+	/* usb host class */
+	&omap44xx_usb_host_hs_hwmod,
+	&omap44xx_usb_tll_hs_hwmod,
+
 	/* usb_otg_hs class */
 	&omap44xx_usb_otg_hs_hwmod,
 
 	/* wd_timer class */
 	&omap44xx_wd_timer2_hwmod,
 	&omap44xx_wd_timer3_hwmod,
-
 	NULL,
 };
 
-- 
1.7.6.3

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Fri, Oct 7, 2011 at 2:36 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hi
>
> On Thu, 6 Oct 2011, Keshava Munegowda wrote:
>
>> From: Benoit Cousson <b-cousson@ti.com>
>>
>> Following 2 hwmod structures are added
>> 1. usb_host_hs
>>      The hwmod of usbhs with uhh, ehci and ohci base addresses
>>      functional clock and ehci, ohci irqs
>>
>> 2. usb_tll_hs
>>       hwmod of usbhs with the TLL base address and irq.
>>
>> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
>>
>> - rebased to kernel version 3.0
>> - Workarounds for hardware issues
>>
>> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
>> Reviewed-by: Partha Basak <parthab@india.ti.com>
>
> A few minor issues in this patch have been fixed.  Please be careful with
> whitespace and with multi-line comment style - see
> Documentation/CodingStyle for more information.

Thanks Paul;
yes, I can your changes in the patches.
so, you don't need v14 from me right? please confirm.
I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
Thanks for guiding me and helping on the finalizing the hwmod configurations.


regards
keshava

>
>
> - Paul
>
> From fdf7c66244af5ca5ba4cdc820f7644efb9f6c1bf Mon Sep 17 00:00:00 2001
> From: Benoit Cousson <b-cousson@ti.com>
> Date: Fri, 7 Oct 2011 02:40:51 -0600
> Subject: [PATCH] arm: omap: usb: ehci and ohci hwmod structures for omap4
>
> Following 2 hwmod structures are added
> 1. usb_host_hs
>     The hwmod of usbhs with uhh, ehci and ohci base addresses
>     functional clock and ehci, ohci irqs
>
> 2. usb_tll_hs
>      hwmod of usbhs with the TLL base address and irq.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
>
> - rebased to kernel version 3.0
> - Workarounds for hardware issues
>
> Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
> Reviewed-by: Partha Basak <parthab@india.ti.com>
> [paul@pwsan.com: fixed whitespace, fixed multi-line comment style]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  206 +++++++++++++++++++++++++++-
>  1 files changed, 205 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index caaf409..6149407 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -68,6 +68,8 @@ 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;
> +static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
> +static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
>
>  /*
>  * Interconnects omap_hwmod structures
> @@ -5254,6 +5256,205 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
>        .slaves_cnt     = ARRAY_SIZE(omap44xx_wd_timer3_slaves),
>  };
>
> +/*
> + * 'usb_host_hs' class
> + * high-speed multi-port usb host controller
> + */
> +static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
> +       .master         = &omap44xx_usb_host_hs_hwmod,
> +       .slave          = &omap44xx_l3_main_2_hwmod,
> +       .clk            = "l3_div_ck",
> +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
> +       .rev_offs       = 0x0000,
> +       .sysc_offs      = 0x0010,
> +       .syss_offs      = 0x0014,
> +       .sysc_flags     = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
> +                          SYSC_HAS_SOFTRESET),
> +       .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +                          SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> +                          MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> +       .sysc_fields    = &omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
> +       .name = "usb_host_hs",
> +       .sysc = &omap44xx_usb_host_hs_sysc,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
> +       &omap44xx_usb_host_hs__l3_main_2,
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
> +       {
> +               .name           = "uhh",
> +               .pa_start       = 0x4a064000,
> +               .pa_end         = 0x4a0647ff,
> +               .flags          = ADDR_TYPE_RT
> +       },
> +       {
> +               .name           = "ohci",
> +               .pa_start       = 0x4a064800,
> +               .pa_end         = 0x4a064bff,
> +       },
> +       {
> +               .name           = "ehci",
> +               .pa_start       = 0x4a064c00,
> +               .pa_end         = 0x4a064fff,
> +       },
> +       {}
> +};
> +
> +static struct omap_hwmod_irq_info omap44xx_usb_host_hs_irqs[] = {
> +       { .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
> +       { .name = "ehci-irq", .irq = 77 + OMAP44XX_IRQ_GIC_START },
> +       { .irq = -1 }
> +};
> +
> +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
> +       .master         = &omap44xx_l4_cfg_hwmod,
> +       .slave          = &omap44xx_usb_host_hs_hwmod,
> +       .clk            = "l4_div_ck",
> +       .addr           = omap44xx_usb_host_hs_addrs,
> +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
> +       &omap44xx_l4_cfg__usb_host_hs,
> +};
> +
> +static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
> +       .name           = "usb_host_hs",
> +       .class          = &omap44xx_usb_host_hs_hwmod_class,
> +       .clkdm_name     = "l3_init_clkdm",
> +       .main_clk       = "usb_host_hs_fck",
> +       .prcm = {
> +               .omap4 = {
> +                       .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
> +                       .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
> +                       .modulemode   = MODULEMODE_SWCTRL,
> +               },
> +       },
> +       .mpu_irqs       = omap44xx_usb_host_hs_irqs,
> +       .slaves         = omap44xx_usb_host_hs_slaves,
> +       .slaves_cnt     = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
> +       .masters        = omap44xx_usb_host_hs_masters,
> +       .masters_cnt    = ARRAY_SIZE(omap44xx_usb_host_hs_masters),
> +/*
> + *     Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
> + *     id: i660
> + *
> + *     Description:
> + *     In the following configuration :
> + *     - USBHOST module is set to smart-idle mode
> + *     - PRCM asserts idle_req to the USBHOST module ( This typically happens
> + *       when the system is going to a low power mode : all ports have been
> + *       suspended, the master part of the USBHOST module has entered the
> + *       standby state, and SW has cut the functional clocks.)
> + *     - an USBHOST interrupt occurs before the module is able to answer
> + *       idle_ack, typically a remote wakeup IRQ.
> + *     Then the USB HOST module will enter a deadlock situation where it is no
> + *     more accessible nor functional.
> + *
> + *     Workaround:
> + *     Don't use smart idle; use only force idle, hence HWMOD_SWSUP_SIDLE
> + */
> +
> +/*
> + *     Errata: USB host EHCI may stall when entering smart-standby mode
> + *     Id: i571
> + *
> + *     Description:
> + *     When the USBHOST module is set to smart-standby mode, and when it is
> + *     ready to enter the standby state (i.e. all ports are suspended and
> + *     all attached devices are in suspend mode), then it can wrongly assert
> + *     the Mstandby signal too early while there are still some residual OCP
> + *     transactions ongoing. If this condition occurs, the internal state
> + *     machine may go to an undefined state and the USB link may be stuck
> + *     upon the next resume.
> + *
> + *     Workaround:
> + *     Don't use smart standby; use only force standby,
> + *     hence HWMOD_SWSUP_MSTANDBY
> + */
> +
> +/*
> + *     During system boot; If the hwmod framework resets the module
> + *     the module will have smart idle settings; which can lead to deadlock
> + *     (above Errata Id:i660); so, dont reset the module during boot;
> + *     Use HWMOD_INIT_NO_RESET.
> + */
> +
> +       .flags          = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +                         HWMOD_INIT_NO_RESET,
> +};
> +
> +/*
> + * 'usb_tll_hs' class
> + * usb_tll_hs module is the adapter on the usb_host_hs ports
> + */
> +static struct omap_hwmod_class_sysconfig omap44xx_usb_tll_hs_sysc = {
> +       .rev_offs       = 0x0000,
> +       .sysc_offs      = 0x0010,
> +       .syss_offs      = 0x0014,
> +       .sysc_flags     = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
> +                          SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
> +                          SYSC_HAS_AUTOIDLE),
> +       .idlemodes      = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> +       .sysc_fields    = &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap44xx_usb_tll_hs_hwmod_class = {
> +       .name = "usb_tll_hs",
> +       .sysc = &omap44xx_usb_tll_hs_sysc,
> +};
> +
> +static struct omap_hwmod_irq_info omap44xx_usb_tll_hs_irqs[] = {
> +       { .name = "tll-irq", .irq = 78 + OMAP44XX_IRQ_GIC_START },
> +       { .irq = -1 }
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_usb_tll_hs_addrs[] = {
> +       {
> +               .name           = "tll",
> +               .pa_start       = 0x4a062000,
> +               .pa_end         = 0x4a063fff,
> +               .flags          = ADDR_TYPE_RT
> +       },
> +       {}
> +};
> +
> +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
> +       .master         = &omap44xx_l4_cfg_hwmod,
> +       .slave          = &omap44xx_usb_tll_hs_hwmod,
> +       .addr           = omap44xx_usb_tll_hs_addrs,
> +       .user           = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap44xx_usb_tll_hs_slaves[] = {
> +       &omap44xx_l4_cfg__usb_tll_hs,
> +};
> +
> +static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
> +       .name           = "usb_tll_hs",
> +       .class          = &omap44xx_usb_tll_hs_hwmod_class,
> +       .clkdm_name     = "l3_init_clkdm",
> +       .main_clk       = "usb_tll_hs_ick",
> +       .prcm = {
> +               .omap4 = {
> +                       .clkctrl_offs = OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET,
> +                       .context_offs = OMAP4_RM_L3INIT_USB_TLL_CONTEXT_OFFSET,
> +                       .modulemode   = MODULEMODE_HWCTRL,
> +               },
> +       },
> +       .mpu_irqs       = omap44xx_usb_tll_hs_irqs,
> +       .slaves         = omap44xx_usb_tll_hs_slaves,
> +       .slaves_cnt     = ARRAY_SIZE(omap44xx_usb_tll_hs_slaves),
> +};
> +
>  static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
>
>        /* dmm class */
> @@ -5393,13 +5594,16 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
>        &omap44xx_uart3_hwmod,
>        &omap44xx_uart4_hwmod,
>
> +       /* usb host class */
> +       &omap44xx_usb_host_hs_hwmod,
> +       &omap44xx_usb_tll_hs_hwmod,
> +
>        /* usb_otg_hs class */
>        &omap44xx_usb_otg_hs_hwmod,
>
>        /* wd_timer class */
>        &omap44xx_wd_timer2_hwmod,
>        &omap44xx_wd_timer3_hwmod,
> -
>        NULL,
>  };
>
> --
> 1.7.6.3
>
>

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

On Fri, 7 Oct 2011, Munegowda, Keshava wrote:

> Thanks Paul;
> yes, I can your changes in the patches.
> so, you don't need v14 from me right? please confirm.
> I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
> Thanks for guiding me and helping on the finalizing the hwmod configurations.

The first two patches of the series -- the OMAP3/4 hwmod data patches -- 
have been queued for 3.2 in the 'hwmod_devel_3.2' branch of 
git://git.pwsan.com/linux-2.6

So we don't need new versions of those two.

But we need to figure out what to do about the remaining three
patches.  I still think that the TLL and UHH hwmods should have
separate drivers.  Looks like Felipe has a question pending about that
but it's unlikely that I'll have time to dig into it for at least a
few days.  So I'd encourage you to try splitting those UHH and TLL
drivers in the meantime.


- Paul

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
>
>> Thanks Paul;
>> yes, I can your changes in the patches.
>> so, you don't need v14 from me right? please confirm.
>> I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
>> Thanks for guiding me and helping on the finalizing the hwmod configurations.
>
> The first two patches of the series -- the OMAP3/4 hwmod data patches --
> have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
> git://git.pwsan.com/linux-2.6
>
> So we don't need new versions of those two.
>
> But we need to figure out what to do about the remaining three
> patches.  I still think that the TLL and UHH hwmods should have
> separate drivers.  Looks like Felipe has a question pending about that
> but it's unlikely that I'll have time to dig into it for at least a
> few days.  So I'd encourage you to try splitting those UHH and TLL
> drivers in the meantime.

some time last week; I had a discussion with Felipe and he is ok to
have current design as it is
for now; But, he wants to redesign this driver with UHH and TLL as two
platform drivers.
I will have discussion with Felipe and Partha to redesign it soon.

regards
keshava

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley <paul@pwsan.com> wrote:
> On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
>
>> Thanks Paul;
>> yes, I can your changes in the patches.
>> so, you don't need v14 from me right? please confirm.
>> I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
>> Thanks for guiding me and helping on the finalizing the hwmod configurations.
>
> The first two patches of the series -- the OMAP3/4 hwmod data patches --
> have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
> git://git.pwsan.com/linux-2.6

Ok, then I will host a tree for remaining three patches and another
last patch for MFD tree.

regards
keshava



> So we don't need new versions of those two.
>
> But we need to figure out what to do about the remaining three
> patches.  I still think that the TLL and UHH hwmods should have
> separate drivers.  Looks like Felipe has a question pending about that
> but it's unlikely that I'll have time to dig into it for at least a
> few days.  So I'd encourage you to try splitting those UHH and TLL
> drivers in the meantime.
>
>
> - Paul
>

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Fri, Oct 7, 2011 at 4:13 PM, Munegowda, Keshava
<keshava_mgowda@ti.com> wrote:
> On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
>>
>>> Thanks Paul;
>>> yes, I can your changes in the patches.
>>> so, you don't need v14 from me right? please confirm.
>>> I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
>>> Thanks for guiding me and helping on the finalizing the hwmod configurations.
>>
>> The first two patches of the series -- the OMAP3/4 hwmod data patches --
>> have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
>> git://git.pwsan.com/linux-2.6
>
> Ok, then I will host a tree for remaining three patches and another
> last patch for MFD tree.

Hi Felipe and Sameo

The patches are available in the branch kmg-usbhs-pm of
git repository: git@gitorious.org:~kmg/mirrors/kmg-usbhs-pm.git

if you have review comment on v13 of these series; please let me know.
so I that I will make the changes in time.

 regards
 keshava


>
>> So we don't need new versions of those two.
>>
>> But we need to figure out what to do about the remaining three
>> patches.  I still think that the TLL and UHH hwmods should have
>> separate drivers.  Looks like Felipe has a question pending about that
>> but it's unlikely that I'll have time to dig into it for at least a
>> few days.  So I'd encourage you to try splitting those UHH and TLL
>> drivers in the meantime.
>>
>>
>> - Paul
>>
>

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Fri, Oct 7, 2011 at 4:03 PM, Munegowda, Keshava
<keshava_mgowda@ti.com> wrote:
> On Fri, Oct 7, 2011 at 3:05 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> On Fri, 7 Oct 2011, Munegowda, Keshava wrote:
>>
>>> Thanks Paul;
>>> yes, I can your changes in the patches.
>>> so, you don't need v14 from me right? please confirm.
>>> I am preparing/validating next version patches with  OCPIF_SWSUP_IDLE removed.
>>> Thanks for guiding me and helping on the finalizing the hwmod configurations.
>>
>> The first two patches of the series -- the OMAP3/4 hwmod data patches --
>> have been queued for 3.2 in the 'hwmod_devel_3.2' branch of
>> git://git.pwsan.com/linux-2.6
>>
>> So we don't need new versions of those two.
>>
>> But we need to figure out what to do about the remaining three
>> patches.  I still think that the TLL and UHH hwmods should have
>> separate drivers.  Looks like Felipe has a question pending about that
>> but it's unlikely that I'll have time to dig into it for at least a
>> few days.  So I'd encourage you to try splitting those UHH and TLL
>> drivers in the meantime.
>
> some time last week; I had a discussion with Felipe and he is ok to
> have current design as it is
> for now; But, he wants to redesign this driver with UHH and TLL as two
> platform drivers.
> I will have discussion with Felipe and Partha to redesign it soon.


Hi paul and Felipe

Here is the highlights of the change in the design of  USB Host which
we can do after kernel 3.2 release;

1. separate the TLL changes  from UHH
2. The TLL is be a new platform driver in ./drivers/mfd
3. the TLL platform driver will export apis  for enable/disable clocks
and settings.
3. the UHH drivers uses these APIS of TLL based on the port
configurations from board files
                                     you don't need the TLL clocks to
be on while all the ports are in phy mode.

please let me know your thoughts about it.


regards
keshava

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

Hi,

On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
> Hi paul and Felipe
> 
> Here is the highlights of the change in the design of  USB Host which
> we can do after kernel 3.2 release;
> 
> 1. separate the TLL changes  from UHH
> 2. The TLL is be a new platform driver in ./drivers/mfd
> 3. the TLL platform driver will export apis  for enable/disable clocks
> and settings.

TLL should control its clocks through pm_runtime APIs like anything
else. If you really must export APIs to be used by UHH, you need to have
an API so that you can claim/release a TLL channel and get/put for
increasing/decreasing PM counters.

I still think though, you should try to avoid exporting OMAP-specific
APIs all over the place. Ideally, we would be able to have some way of
saying that UHH and TLL are closely related... something like having the
ability to say e.g. two devices are sibblings of each other, so that we
could ask for a sibbling to wakeup/sleep depending if we need it or not.

Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
APIs is wise.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>> Hi paul and Felipe
>>
>> Here is the highlights of the change in the design of  USB Host which
>> we can do after kernel 3.2 release;
>>
>> 1. separate the TLL changes  from UHH
>> 2. The TLL is be a new platform driver in ./drivers/mfd
>> 3. the TLL platform driver will export apis  for enable/disable clocks
>> and settings.
>
> TLL should control its clocks through pm_runtime APIs like anything
> else. If you really must export APIs to be used by UHH, you need to have
> an API so that you can claim/release a TLL channel and get/put for
> increasing/decreasing PM counters.
>
> I still think though, you should try to avoid exporting OMAP-specific
> APIs all over the place. Ideally, we would be able to have some way of
> saying that UHH and TLL are closely related... something like having the
> ability to say e.g. two devices are sibblings of each other, so that we
> could ask for a sibbling to wakeup/sleep depending if we need it or not.

do we have sibling structures today? I dont think so.

>
> Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> APIs is wise.

so, it means , if we can have sibling structure, then we can
conditionally enable it right?

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
> On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
> >> Hi paul and Felipe
> >>
> >> Here is the highlights of the change in the design of  USB Host which
> >> we can do after kernel 3.2 release;
> >>
> >> 1. separate the TLL changes  from UHH
> >> 2. The TLL is be a new platform driver in ./drivers/mfd
> >> 3. the TLL platform driver will export apis  for enable/disable clocks
> >> and settings.
> >
> > TLL should control its clocks through pm_runtime APIs like anything
> > else. If you really must export APIs to be used by UHH, you need to have
> > an API so that you can claim/release a TLL channel and get/put for
> > increasing/decreasing PM counters.
> >
> > I still think though, you should try to avoid exporting OMAP-specific
> > APIs all over the place. Ideally, we would be able to have some way of
> > saying that UHH and TLL are closely related... something like having the
> > ability to say e.g. two devices are sibblings of each other, so that we
> > could ask for a sibbling to wakeup/sleep depending if we need it or not.
> 
> do we have sibling structures today? I dont think so.

no we don't.

> > Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> > APIs is wise.
> 
> so, it means , if we can have sibling structure, then we can
> conditionally enable it right?

the conditional would still lie in UHH driver, but at least it would be
made into a generic API. I mean, you could create a generic way of
defining sibbling devices, and a generic way to make them talk to each
other.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 6446 bytes --]

On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
> On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
> > On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
> > > Hi,
> > >
> > > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
> > >> Hi paul and Felipe
> > >>
> > >> Here is the highlights of the change in the design of  USB Host which
> > >> we can do after kernel 3.2 release;
> > >>
> > >> 1. separate the TLL changes  from UHH
> > >> 2. The TLL is be a new platform driver in ./drivers/mfd
> > >> 3. the TLL platform driver will export apis  for enable/disable clocks
> > >> and settings.
> > >
> > > TLL should control its clocks through pm_runtime APIs like anything
> > > else. If you really must export APIs to be used by UHH, you need to have
> > > an API so that you can claim/release a TLL channel and get/put for
> > > increasing/decreasing PM counters.
> > >
> > > I still think though, you should try to avoid exporting OMAP-specific
> > > APIs all over the place. Ideally, we would be able to have some way of
> > > saying that UHH and TLL are closely related... something like having the
> > > ability to say e.g. two devices are sibblings of each other, so that we
> > > could ask for a sibbling to wakeup/sleep depending if we need it or not.
> > 
> > do we have sibling structures today? I dont think so.
> 
> no we don't.

Ok, here's a first shot at it:

From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 10 Oct 2011 12:56:34 +0300
Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
Organization: Texas Instruments\n

It's possible that some devices, which share a
common parent, need to talk to each due to a
very close relationship between them.

Generally, one device will provide some sort of
resources to the other (e.g. clocks) while still
both sharing another common parent.

In such cases, it seems necessary to define those
two devices as siblings, rather than a virtual
parent relationship, and have means for one device
to ask the sibling device to e.g. turn on its clocks.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/base/core.c    |   41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/device.h |    7 +++++++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index bc8729d..3b7f2e5 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
 	dev->kobj.kset = devices_kset;
 	kobject_init(&dev->kobj, &device_ktype);
 	INIT_LIST_HEAD(&dev->dma_pools);
+	INIT_LIST_HEAD(&dev->siblings);
 	mutex_init(&dev->mutex);
 	lockdep_set_novalidate_class(&dev->mutex);
 	spin_lock_init(&dev->devres_lock);
@@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
  */
 int device_add(struct device *dev)
 {
+	struct device *sibling, *n;
 	struct device *parent = NULL;
 	struct class_interface *class_intf;
 	int error = -EINVAL;
@@ -923,6 +925,10 @@ int device_add(struct device *dev)
 	parent = get_device(dev->parent);
 	setup_parent(dev, parent);
 
+	/* setup siblings */
+	list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node)
+		get_device(sibling);
+
 	/* use parent numa_node */
 	if (parent)
 		set_dev_node(dev, dev_to_node(parent));
@@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
 }
 
 /**
+ * get_sibling_device_byname - finds a sibling device by its name
+ * @dev: device.
+ * @name: name for the sibling to find.
+ *
+ * This is here to help drivers which need to ask their siblings
+ * for something in particular (like ask sibling to turn clocks on)
+ * achieve that by first finding the correct device pointer for
+ * that sibling.
+ */
+struct device *get_sibling_device_byname(struct device *dev, const char *name)
+{
+	struct device	*sibling, *n;
+	struct device	*found = NULL;
+
+	list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
+		if (!strcmp(dev_name(sibling), name))
+			found = sibling;
+			goto found;
+	}
+
+found:
+	return found;
+}
+
+/**
  * device_del - delete device from system.
  * @dev: device.
  *
@@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
  */
 void device_del(struct device *dev)
 {
+	struct device *sibling, *n;
 	struct device *parent = dev->parent;
 	struct class_interface *class_intf;
 
@@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
 	device_remove_attrs(dev);
 	bus_remove_device(dev);
 
+	/* teardown siblings */
+	list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
+		/* siblings must have  the same parent */
+		WARN(sibling->parent != parent,
+				"siblings must have a common parent\n");
+
+		get_device(sibling);
+	}
+
 	/*
 	 * Some platform devices are driven without driver attached
 	 * and managed resources may have been acquired.  Make sure
diff --git a/include/linux/device.h b/include/linux/device.h
index c20dfbf..ae9cec9 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -551,6 +551,9 @@ struct device_dma_parameters {
 struct device {
 	struct device		*parent;
 
+	struct list_head	sibling_node;
+	struct list_head	siblings;
+
 	struct device_private	*p;
 
 	struct kobject kobj;
@@ -764,6 +767,10 @@ extern int (*platform_notify_remove)(struct device *dev);
 extern struct device *get_device(struct device *dev);
 extern void put_device(struct device *dev);
 
+/* finds a sibling struct device pointer */
+extern struct device *get_sibling_device_byname(struct device *dev,
+		const char *name);
+
 extern void wait_for_device_probe(void);
 
 #ifdef CONFIG_DEVTMPFS
-- 
1.7.6.396.ge0613

one way to use this would be to mark both hwmods has having the same
parent and pointing to each other as siblings. Then, from UHH you could:

if (port->mode == TLL) {
	tll = get_sibling_device_by_name(dev, "usbtll");
	if (!tll)
		error();

	pm_runtime_get_sync(tll);
}

or something similar. As of now, I'm not so sure this is a very good
idea, but decided to gather some comments anyway.

Does anybody see any change of this getting used in more cases ? Greg,
I'm adding you to this thread, if you have any comments to this, I'd
like to hear them.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Munegowda, Keshava]

On Mon, Oct 10, 2011 at 3:35 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Mon, Oct 10, 2011 at 12:26:15PM +0300, Felipe Balbi wrote:
>> On Mon, Oct 10, 2011 at 02:47:42PM +0530, Munegowda, Keshava wrote:
>> > On Mon, Oct 10, 2011 at 2:33 PM, Felipe Balbi <balbi@ti.com> wrote:
>> > > Hi,
>> > >
>> > > On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>> > >> Hi paul and Felipe
>> > >>
>> > >> Here is the highlights of the change in the design of  USB Host which
>> > >> we can do after kernel 3.2 release;
>> > >>
>> > >> 1. separate the TLL changes  from UHH
>> > >> 2. The TLL is be a new platform driver in ./drivers/mfd
>> > >> 3. the TLL platform driver will export apis  for enable/disable clocks
>> > >> and settings.
>> > >
>> > > TLL should control its clocks through pm_runtime APIs like anything
>> > > else. If you really must export APIs to be used by UHH, you need to have
>> > > an API so that you can claim/release a TLL channel and get/put for
>> > > increasing/decreasing PM counters.
>> > >
>> > > I still think though, you should try to avoid exporting OMAP-specific
>> > > APIs all over the place. Ideally, we would be able to have some way of
>> > > saying that UHH and TLL are closely related... something like having the
>> > > ability to say e.g. two devices are sibblings of each other, so that we
>> > > could ask for a sibbling to wakeup/sleep depending if we need it or not.
>> >
>> > do we have sibling structures today? I dont think so.
>>
>> no we don't.
>
> Ok, here's a first shot at it:
>
> From 600ae62f4b4a832d90a83d43227deb6f84b9def1 Mon Sep 17 00:00:00 2001
> From: Felipe Balbi <balbi@ti.com>
> Date: Mon, 10 Oct 2011 12:56:34 +0300
> Subject: [RFC/NOT-FOR-MERGING/PATCH] base: add the idea of sibling devices
> Organization: Texas Instruments\n
>
> It's possible that some devices, which share a
> common parent, need to talk to each due to a
> very close relationship between them.
>
> Generally, one device will provide some sort of
> resources to the other (e.g. clocks) while still
> both sharing another common parent.
>
> In such cases, it seems necessary to define those
> two devices as siblings, rather than a virtual
> parent relationship, and have means for one device
> to ask the sibling device to e.g. turn on its clocks.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>  drivers/base/core.c    |   41 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/device.h |    7 +++++++
>  2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index bc8729d..3b7f2e5 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -589,6 +589,7 @@ void device_initialize(struct device *dev)
>        dev->kobj.kset = devices_kset;
>        kobject_init(&dev->kobj, &device_ktype);
>        INIT_LIST_HEAD(&dev->dma_pools);
> +       INIT_LIST_HEAD(&dev->siblings);
>        mutex_init(&dev->mutex);
>        lockdep_set_novalidate_class(&dev->mutex);
>        spin_lock_init(&dev->devres_lock);
> @@ -889,6 +890,7 @@ int device_private_init(struct device *dev)
>  */
>  int device_add(struct device *dev)
>  {
> +       struct device *sibling, *n;
>        struct device *parent = NULL;
>        struct class_interface *class_intf;
>        int error = -EINVAL;
> @@ -923,6 +925,10 @@ int device_add(struct device *dev)
>        parent = get_device(dev->parent);
>        setup_parent(dev, parent);
>
> +       /* setup siblings */
> +       list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node)
> +               get_device(sibling);
> +
>        /* use parent numa_node */
>        if (parent)
>                set_dev_node(dev, dev_to_node(parent));
> @@ -1071,6 +1077,31 @@ void put_device(struct device *dev)
>  }
>
>  /**
> + * get_sibling_device_byname - finds a sibling device by its name
> + * @dev: device.
> + * @name: name for the sibling to find.
> + *
> + * This is here to help drivers which need to ask their siblings
> + * for something in particular (like ask sibling to turn clocks on)
> + * achieve that by first finding the correct device pointer for
> + * that sibling.
> + */
> +struct device *get_sibling_device_byname(struct device *dev, const char *name)
> +{
> +       struct device   *sibling, *n;
> +       struct device   *found = NULL;
> +
> +       list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
> +               if (!strcmp(dev_name(sibling), name))
> +                       found = sibling;
> +                       goto found;
> +       }
> +
> +found:
> +       return found;
> +}
> +
> +/**
>  * device_del - delete device from system.
>  * @dev: device.
>  *
> @@ -1085,6 +1116,7 @@ void put_device(struct device *dev)
>  */
>  void device_del(struct device *dev)
>  {
> +       struct device *sibling, *n;
>        struct device *parent = dev->parent;
>        struct class_interface *class_intf;
>
> @@ -1120,6 +1152,15 @@ void device_del(struct device *dev)
>        device_remove_attrs(dev);
>        bus_remove_device(dev);
>
> +       /* teardown siblings */
> +       list_for_each_entry_safe(sibling, n, &dev->siblings, sibling_node) {
> +               /* siblings must have  the same parent */
> +               WARN(sibling->parent != parent,
> +                               "siblings must have a common parent\n");
> +
> +               get_device(sibling);
> +       }
> +
>        /*
>         * Some platform devices are driven without driver attached
>         * and managed resources may have been acquired.  Make sure
> diff --git a/include/linux/device.h b/include/linux/device.h
> index c20dfbf..ae9cec9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -551,6 +551,9 @@ struct device_dma_parameters {
>  struct device {
>        struct device           *parent;
>
> +       struct list_head        sibling_node;
> +       struct list_head        siblings;
> +
>        struct device_private   *p;
>
>        struct kobject kobj;
> @@ -764,6 +767,10 @@ extern int (*platform_notify_remove)(struct device *dev);
>  extern struct device *get_device(struct device *dev);
>  extern void put_device(struct device *dev);
>
> +/* finds a sibling struct device pointer */
> +extern struct device *get_sibling_device_byname(struct device *dev,
> +               const char *name);
> +
>  extern void wait_for_device_probe(void);
>
>  #ifdef CONFIG_DEVTMPFS
> --
> 1.7.6.396.ge0613
>
> one way to use this would be to mark both hwmods has having the same
> parent and pointing to each other as siblings. Then, from UHH you could:
>
> if (port->mode == TLL) {
>        tll = get_sibling_device_by_name(dev, "usbtll");
>        if (!tll)
>                error();
>
>        pm_runtime_get_sync(tll);
> }
>
> or something similar. As of now, I'm not so sure this is a very good
> idea, but decided to gather some comments anyway.
>
> Does anybody see any change of this getting used in more cases ? Greg,
> I'm adding you to this thread, if you have any comments to this, I'd
> like to hear them.


This design looks good and perfectly suits our requirements.

Paul/Others
          please provide your thoughts..

regards
keshava

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Alan Stern]

On Mon, 10 Oct 2011, Felipe Balbi wrote:

> > > do we have sibling structures today? I dont think so.
> > 
> > no we don't.
> 
> Ok, here's a first shot at it:

In fact we do already have sibling lists.  They are maintained as part 
of the device_private structure.  What we are missing is a 
device_for_each_sibling() routine.  It could be added pretty easily; it 
would be similar to device_for_each_child().

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
> On Mon, 10 Oct 2011, Felipe Balbi wrote:
> 
> > > > do we have sibling structures today? I dont think so.
> > > 
> > > no we don't.
> > 
> > Ok, here's a first shot at it:
> 
> In fact we do already have sibling lists.  They are maintained as part 
> of the device_private structure.  What we are missing is a 
> device_for_each_sibling() routine.  It could be added pretty easily; it 
> would be similar to device_for_each_child().

care to point out where is ?

68 struct device_private {
69         struct klist klist_children;
70         struct klist_node knode_parent;
71         struct klist_node knode_driver;
72         struct klist_node knode_bus;
73         void *driver_data;
74         struct device *device;
75 };

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Alan Stern]

On Mon, 10 Oct 2011, Felipe Balbi wrote:

> On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
> > On Mon, 10 Oct 2011, Felipe Balbi wrote:
> > 
> > > > > do we have sibling structures today? I dont think so.
> > > > 
> > > > no we don't.
> > > 
> > > Ok, here's a first shot at it:
> > 
> > In fact we do already have sibling lists.  They are maintained as part 
> > of the device_private structure.  What we are missing is a 
> > device_for_each_sibling() routine.  It could be added pretty easily; it 
> > would be similar to device_for_each_child().
> 
> care to point out where is ?
> 
> 68 struct device_private {
> 69         struct klist klist_children;
> 70         struct klist_node knode_parent;
-------------^  Here.  The "parent" in the name refers to where the
                head of the list is stored.

> 71         struct klist_node knode_driver;
> 72         struct klist_node knode_bus;
> 73         void *driver_data;
> 74         struct device *device;
> 75 };

>From device_add():

	if (parent)
		klist_add_tail(&dev->p->knode_parent,
			       &parent->p->klist_children);

Alan Stern

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

Hi,

On Mon, Oct 10, 2011 at 03:55:30PM -0400, Alan Stern wrote:
> On Mon, 10 Oct 2011, Felipe Balbi wrote:
> 
> > On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
> > > On Mon, 10 Oct 2011, Felipe Balbi wrote:
> > > 
> > > > > > do we have sibling structures today? I dont think so.
> > > > > 
> > > > > no we don't.
> > > > 
> > > > Ok, here's a first shot at it:
> > > 
> > > In fact we do already have sibling lists.  They are maintained as part 
> > > of the device_private structure.  What we are missing is a 
> > > device_for_each_sibling() routine.  It could be added pretty easily; it 
> > > would be similar to device_for_each_child().
> > 
> > care to point out where is ?
> > 
> > 68 struct device_private {
> > 69         struct klist klist_children;
> > 70         struct klist_node knode_parent;
> -------------^  Here.  The "parent" in the name refers to where the
>                 head of the list is stored.
> 
> > 71         struct klist_node knode_driver;
> > 72         struct klist_node knode_bus;
> > 73         void *driver_data;
> > 74         struct device *device;
> > 75 };
> 
> From device_add():
> 
> 	if (parent)
> 		klist_add_tail(&dev->p->knode_parent,
> 			       &parent->p->klist_children);

that's a parent -> child relationship. What we have on this case is:

 --------------                ---------------
|              |              |               |          |\
|   UHH        |  clocks, etc |    USBTLL     |          | |
|              | <==========> |               | <======> | | <====> ports
|     -------  |              | (Transceiver- |          | |
|    |  EHCI | |              | less Link)    |          |/
|     -------  |              |               |         Port MUX
|              |              |               |
|     -------  |              |               |
|    |  OHCI | |              |               |
|     -------  |              |               |
|              |              |               |
 --------------                ---------------

It doesn't shown here, but the TLL link is completely optional. It's
mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
and OHCI will depend on a clock provided by the USBTLL block.

Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
blocks. We can, from a code perspective, make USBTLL into a parent of
UHH to make things simpler, but this will mean that calling
pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
add some nasty hacks to allow TLL know if *HCI port is in TLL mode.

That's why I decided for making TLL and UHH siblings, because that's a
closer relationship than parent-child.

Can you see the problem now ?

ps: the best picture is on TI's OMAP4430 TRM (it's publicly available
from TI's website). So, if you want a better rendering of the
integration model, take a look at chapter 23.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

On Mon, 10 Oct 2011, Munegowda, Keshava wrote:

> Here is the highlights of the change in the design of  USB Host which
> we can do after kernel 3.2 release;
> 
> 1. separate the TLL changes  from UHH
> 2. The TLL is be a new platform driver in ./drivers/mfd
> 3. the TLL platform driver will export apis  for enable/disable clocks
> and settings.
> 3. the UHH drivers uses these APIS of TLL based on the port
> configurations from board files
>                                      you don't need the TLL clocks to
> be on while all the ports are in phy mode.
> 
> please let me know your thoughts about it.

The TLL driver shouldn't be in drivers/mfd, since it's not an MFD device. 
The TLL driver should go somewhere under drivers/usb.

Basically, the existing OMAP USB subsystem MFD driver should create a TLL 
device.  Then the existing Linux driver probing system can associate the 
TLL driver with the TLL device.


- Paul

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi
On Mon, 10 Oct 2011, Felipe Balbi wrote:

> On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>
> > Here is the highlights of the change in the design of  USB Host which
> > we can do after kernel 3.2 release;
> > 
> > 1. separate the TLL changes  from UHH
> > 2. The TLL is be a new platform driver in ./drivers/mfd
> > 3. the TLL platform driver will export apis  for enable/disable clocks
> > and settings.
> 
> TLL should control its clocks through pm_runtime APIs like anything
> else. If you really must export APIs to be used by UHH, you need to have
> an API so that you can claim/release a TLL channel and get/put for
> increasing/decreasing PM counters.
> 
> I still think though, you should try to avoid exporting OMAP-specific
> APIs all over the place. Ideally, we would be able to have some way of
> saying that UHH and TLL are closely related... something like having the
> ability to say e.g. two devices are sibblings of each other, so that we
> could ask for a sibbling to wakeup/sleep depending if we need it or not.
> 
> Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> APIs is wise.

I'm not an USBHOST expert, but I don't think any special sibling 
relationships or OMAP subarchitecture-specific APIs are needed.  The OMAP 
EHCI/OHCI drivers just need to call a couple of functions in the OMAP TLL 
driver.  Linux already handles function call dependencies between 
loadable modules transparently (see "man 8 depmod" and EXPORT_SYMBOL).

Looks to me like the TLL IP block is only needed for OHCI and some EHCI 
port modes[1].  The TLL doesn't seem to need much care and feeding.  
Currently it's programmed during init[2] and then you just enable it when 
the port is in use[3] and disable it when it is no longer in use[4].  
Looks to me like the TLL init function could be rolled into the enable 
function.

So then you'd just create a TLL driver with something like these two 
symbols exported:

omap_usbhost_tll_enable_port();
omap_usbhost_tll_disable_port(); 

The first function would be called from drivers/usb/host/ehci-omap.c or 
drivers/usb/host/ohci-omap3.c during omap_usbhs_enable().  It would take 
the TLL configuration for that port and would reserve it while it is in 
use.  It would call pm_runtime_get_sync() to ensure its clocks were on, 
etc.

The second function would be called from drivers/usb/host/ehci-omap.c or
drivers/usb/host/ohci-omap3.c during omap_usbhs_disable().  It would 
release an already in-use TLL port and would call pm_runtime_put_sync() to 
allow its clocks to be cut, etc.

So it doesn't seem like any extraordinary Linux support is needed to 
handle this cleanly.  But maybe I'm missing something?


- Paul

All references are as of Linux v3.1-rc9.

1. drivers/mfd/omap-usb-host.c:887,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l887

2. drivers/mfd/omap-usb-host.c:894,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l894

3. drivers/mfd/omap-usb-host.c:845,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l845

4. drivers/mfd/omap-usb-host.c:999,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l999

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

On Mon, 10 Oct 2011, Paul Walmsley wrote:

> So then you'd just create a TLL driver with something like these two 
> symbols exported:
> 
> omap_usbhost_tll_enable_port();
> omap_usbhost_tll_disable_port(); 

N.B., since I don't think Linux has any formal support to map USB ports to 
TLL ports, you'll probably need to create a couple of functions in your 
drivers/mfd/omap-usb-host.c that your EHCI/OHCI drivers could call during 
init/exit to get and put the TLL struct device, to pass to those above 
functions.  Since the MFD driver is what creates the TLL struct devices, 
the MFD driver will have the TLL struct device pointers.  Something like 
omap_usbhost_get_tll_device() and omap_usbhost_put_tll_device().

One other thing.  Not sure what the correct generic name prefix for these 
functions should be, since I don't know the provenance of the USBHOST IP 
block; but maybe the function prefix should be something like 'ti_usbhost' 
instead, to indicate that it isn't OMAP-specific?  You would know better 
than I.


- Paul

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Alan Stern]

On Mon, 10 Oct 2011, Felipe Balbi wrote:

> > > > In fact we do already have sibling lists.  They are maintained as part 
> > > > of the device_private structure.  What we are missing is a 
> > > > device_for_each_sibling() routine.  It could be added pretty easily; it 
> > > > would be similar to device_for_each_child().
> > > 
> > > care to point out where is ?
> > > 
> > > 68 struct device_private {
> > > 69         struct klist klist_children;
> > > 70         struct klist_node knode_parent;
> > -------------^  Here.  The "parent" in the name refers to where the
> >                 head of the list is stored.
> > 
> > > 71         struct klist_node knode_driver;
> > > 72         struct klist_node knode_bus;
> > > 73         void *driver_data;
> > > 74         struct device *device;
> > > 75 };
> > 
> > From device_add():
> > 
> > 	if (parent)
> > 		klist_add_tail(&dev->p->knode_parent,
> > 			       &parent->p->klist_children);
> 
> that's a parent -> child relationship. What we have on this case is:
> 
>  --------------                ---------------
> |              |              |               |          |\
> |   UHH        |  clocks, etc |    USBTLL     |          | |
> |              | <==========> |               | <======> | | <====> ports
> |     -------  |              | (Transceiver- |          | |
> |    |  EHCI | |              | less Link)    |          |/
> |     -------  |              |               |         Port MUX
> |              |              |               |
> |     -------  |              |               |
> |    |  OHCI | |              |               |
> |     -------  |              |               |
> |              |              |               |
>  --------------                ---------------
> 
> It doesn't shown here, but the TLL link is completely optional. It's
> mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
> and OHCI will depend on a clock provided by the USBTLL block.
> 
> Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
> blocks. We can, from a code perspective, make USBTLL into a parent of
> UHH to make things simpler, but this will mean that calling
> pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
> add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
> 
> That's why I decided for making TLL and UHH siblings, because that's a
> closer relationship than parent-child.
> 
> Can you see the problem now ?

Okay, now I understand better.  The word "sibling" implies that the two 
objects have the same parent, so a different word would describe this 
relationship better.  Something like "friend" or "associate".

Or maybe, following Paul's suggestion, the driver core doesn't have to 
be changed at all.

Alan Stern

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

and some comments on this one ...

On Thu, 6 Oct 2011, Keshava Munegowda wrote:

> From: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
> 
> Following 2 hwmod structures are added
> 1. usb_host_hs
>      The hwmod of usbhs with uhh, ehci and ohci base addresses
>      functional clock and ehci, ohci irqs
> 
> 2. usb_tll_hs
>       hwmod of usbhs with the TLL base address and irq.
> 
> Signed-off-by: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org>
> 
> - rebased to kernel version 3.0
> - Workarounds for hardware issues
> 
> Signed-off-by: Keshava Munegowda <keshava_mgowda-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Partha Basak <parthab-PpE0FKYn9XJWk0Htik3J/w@public.gmane.org>
> ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  206 +++++++++++++++++++++++++++-
>  1 files changed, 205 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 6201422..e404fd6 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c

...

> +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
> +	.master		= &omap44xx_l4_cfg_hwmod,
> +	.slave		= &omap44xx_usb_tll_hs_hwmod,
> +	.addr		= omap44xx_usb_tll_hs_addrs,
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};

This one has the .master pointing to something reasonable, but is missing 
a .clk entry.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

On Mon, 10 Oct 2011, Paul Walmsley wrote:

> Basically, the existing OMAP USB subsystem MFD driver should create a TLL 
> device.  Then the existing Linux driver probing system can associate the 
> TLL driver with the TLL device.

This part isn't right.  After staring at the OMAP34xx TRM, it looks like 
the TLL modules have a separate interconnect port.  See for example the 
OMAP34xx TRM Rev. ZR Table 2-3 "L4-Core Memory Space Mapping".

So then the TLL device should be created by the code in 
arch/arm/mach-omap2/usb-host.c, as one of Keshava's patches does.  And 
indeed we have separate hwmods for the TLL IP blocks -- although both the 
OMAP3 and OMAP4 hwmod data that was posted are missing important fields.

So drivers/omap-usb-host.c shouldn't create a new TLL device.  You just 
need to pull all of the TLL code and data out of that MFD driver into a 
new TLL driver under drivers/usb somewhere.

Then you'll need some way for the EHCI/OHCI code to figure out which 
USBTLL device handles each port.  I'd suggest that, unless there is some 
explicit Linux USB core support for associating a TLL port with a host 
controller port, that the code in arch/arm/mach-omap2/usb-host.c register 
the USBTLL device first (the opposite of what it does now), then pass 
the pointer to the USBTLL's struct device via platform_data to 
drivers/mfd/omap-usb-host.c.  Then that can either be passed via 
platform_data to the EHCI/OHCI drivers, or the EHCI/OHCI drivers can call 
a drivers/mfd/omap-usb-host.c function to retrieve that struct device 
pointer.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Cousson, Benoit]

Hi Paul,

On 10/11/2011 2:40 AM, Paul Walmsley wrote:
> Hi
>
> and some comments on this one ...
>
> On Thu, 6 Oct 2011, Keshava Munegowda wrote:

[...]

>> +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_tll_hs = {
>> +	.master		=&omap44xx_l4_cfg_hwmod,
>> +	.slave		=&omap44xx_usb_tll_hs_hwmod,
>> +	.addr		= omap44xx_usb_tll_hs_addrs,
>> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>> +};
>
> This one has the .master pointing to something reasonable, but is missing
> a .clk entry.

In that case, there is only an interface clock and a couple of optional 
clocks, that why I did not populate the main_clk.

IIRC, we decided to not duplicate the iclk into the main_clk in case of 
module that are using only the interface clock as their functional clock.

Regards,
Benoit

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

Hi,

On Mon, Oct 10, 2011 at 08:15:29PM -0400, Alan Stern wrote:
> > > > > In fact we do already have sibling lists.  They are maintained as part 
> > > > > of the device_private structure.  What we are missing is a 
> > > > > device_for_each_sibling() routine.  It could be added pretty easily; it 
> > > > > would be similar to device_for_each_child().
> > > > 
> > > > care to point out where is ?
> > > > 
> > > > 68 struct device_private {
> > > > 69         struct klist klist_children;
> > > > 70         struct klist_node knode_parent;
> > > -------------^  Here.  The "parent" in the name refers to where the
> > >                 head of the list is stored.
> > > 
> > > > 71         struct klist_node knode_driver;
> > > > 72         struct klist_node knode_bus;
> > > > 73         void *driver_data;
> > > > 74         struct device *device;
> > > > 75 };
> > > 
> > > From device_add():
> > > 
> > > 	if (parent)
> > > 		klist_add_tail(&dev->p->knode_parent,
> > > 			       &parent->p->klist_children);
> > 
> > that's a parent -> child relationship. What we have on this case is:
> > 
> >  --------------                ---------------
> > |              |              |               |          |\
> > |   UHH        |  clocks, etc |    USBTLL     |          | |
> > |              | <==========> |               | <======> | | <====> ports
> > |     -------  |              | (Transceiver- |          | |
> > |    |  EHCI | |              | less Link)    |          |/
> > |     -------  |              |               |         Port MUX
> > |              |              |               |
> > |     -------  |              |               |
> > |    |  OHCI | |              |               |
> > |     -------  |              |               |
> > |              |              |               |
> >  --------------                ---------------
> > 
> > It doesn't shown here, but the TLL link is completely optional. It's
> > mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
> > and OHCI will depend on a clock provided by the USBTLL block.
> > 
> > Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
> > blocks. We can, from a code perspective, make USBTLL into a parent of
> > UHH to make things simpler, but this will mean that calling
> > pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
> > add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
> > 
> > That's why I decided for making TLL and UHH siblings, because that's a
> > closer relationship than parent-child.
> > 
> > Can you see the problem now ?
> 
> Okay, now I understand better.  The word "sibling" implies that the two 
> objects have the same parent, so a different word would describe this 
> relationship better.  Something like "friend" or "associate".
> 
> Or maybe, following Paul's suggestion, the driver core doesn't have to 
> be changed at all.

I see... I just thought that if there are other similar cases, it might
make sense to have a more generic way to make those two devices talk to
each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough,
then it's ok ;-)

thanks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Alan Stern]

On Tue, 11 Oct 2011, Felipe Balbi wrote:

> > > It doesn't shown here, but the TLL link is completely optional. It's
> > > mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
> > > and OHCI will depend on a clock provided by the USBTLL block.
> > > 
> > > Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
> > > blocks. We can, from a code perspective, make USBTLL into a parent of
> > > UHH to make things simpler, but this will mean that calling
> > > pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
> > > add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
> > > 
> > > That's why I decided for making TLL and UHH siblings, because that's a
> > > closer relationship than parent-child.
> > > 
> > > Can you see the problem now ?
> > 
> > Okay, now I understand better.  The word "sibling" implies that the two 
> > objects have the same parent, so a different word would describe this 
> > relationship better.  Something like "friend" or "associate".
> > 
> > Or maybe, following Paul's suggestion, the driver core doesn't have to 
> > be changed at all.
> 
> I see... I just thought that if there are other similar cases, it might
> make sense to have a more generic way to make those two devices talk to
> each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough,
> then it's ok ;-)

At the moment, I can't see any way to set up a more generic mechanism 
that wouldn't be more complicated and have higher overhead than a 
simple EXPORT_SYMBOL_GPL.

Can this be handled by adding another resource to a platform_device?  
That at least would make use of an already-existing mechanism.

Alan Stern

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

Hi,

On Tue, Oct 11, 2011 at 10:04:28AM -0400, Alan Stern wrote:
> On Tue, 11 Oct 2011, Felipe Balbi wrote:
> 
> > > > It doesn't shown here, but the TLL link is completely optional. It's
> > > > mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
> > > > and OHCI will depend on a clock provided by the USBTLL block.
> > > > 
> > > > Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
> > > > blocks. We can, from a code perspective, make USBTLL into a parent of
> > > > UHH to make things simpler, but this will mean that calling
> > > > pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
> > > > add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
> > > > 
> > > > That's why I decided for making TLL and UHH siblings, because that's a
> > > > closer relationship than parent-child.
> > > > 
> > > > Can you see the problem now ?
> > > 
> > > Okay, now I understand better.  The word "sibling" implies that the two 
> > > objects have the same parent, so a different word would describe this 
> > > relationship better.  Something like "friend" or "associate".
> > > 
> > > Or maybe, following Paul's suggestion, the driver core doesn't have to 
> > > be changed at all.
> > 
> > I see... I just thought that if there are other similar cases, it might
> > make sense to have a more generic way to make those two devices talk to
> > each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough,
> > then it's ok ;-)
> 
> At the moment, I can't see any way to set up a more generic mechanism 
> that wouldn't be more complicated and have higher overhead than a 
> simple EXPORT_SYMBOL_GPL.
> 
> Can this be handled by adding another resource to a platform_device?  
> That at least would make use of an already-existing mechanism.

maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that
this IP comes from synopsys, and I'm not really keen on adding
OMAP-specific, integration-related knowledge on a driver which was
supposed to be reusable ;-)

But at least for the time being, I guess that's what we need to do ;-)

tks

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi Felipe

On Tue, 11 Oct 2011, Felipe Balbi wrote:

> maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that
> this IP comes from synopsys, and I'm not really keen on adding
> OMAP-specific, integration-related knowledge on a driver which was
> supposed to be reusable ;-)
>
> But at least for the time being, I guess that's what we need to do ;-)

Which IP is coming from Synopsys - the TLL ?  The EXPORT_SYMBOL approach 
shouldn't add anything OMAP-specific to the TLL driver.  So the exported 
symbols should still be usable by drivers on other SoCs.  But perhaps I am 
misunderstanding your point?

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Tue, Oct 11, 2011 at 12:52:05PM -0600, Paul Walmsley wrote:
> Hi Felipe
> 
> On Tue, 11 Oct 2011, Felipe Balbi wrote:
> 
> > maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that
> > this IP comes from synopsys, and I'm not really keen on adding
> > OMAP-specific, integration-related knowledge on a driver which was
> > supposed to be reusable ;-)
> >
> > But at least for the time being, I guess that's what we need to do ;-)
> 
> Which IP is coming from Synopsys - the TLL ?  The EXPORT_SYMBOL approach 

TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for
all I know.

> shouldn't add anything OMAP-specific to the TLL driver.  So the exported 
> symbols should still be usable by drivers on other SoCs.  But perhaps I am 
> misunderstanding your point?

A bit :-)

EHCI/OHCI will need to ask TLL to enable TLL clock, because it's
EHCI/OHCI who configure the port. Unless I misunderstood what Keshava
did (and no, I didn't just read the code, too lazy :-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Paul Walmsley]

Hi

On Tue, 11 Oct 2011, Felipe Balbi wrote:

> On Tue, Oct 11, 2011 at 12:52:05PM -0600, Paul Walmsley wrote:
>
> > On Tue, 11 Oct 2011, Felipe Balbi wrote:
> > 
> > > maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that
> > > this IP comes from synopsys, and I'm not really keen on adding
> > > OMAP-specific, integration-related knowledge on a driver which was
> > > supposed to be reusable ;-)
> > >
> > > But at least for the time being, I guess that's what we need to do ;-)
> > 
> > Which IP is coming from Synopsys - the TLL ?  The EXPORT_SYMBOL approach 
> 
> TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for
> all I know.

Ah, I see.

> > shouldn't add anything OMAP-specific to the TLL driver.  So the exported 
> > symbols should still be usable by drivers on other SoCs.  But perhaps I am 
> > misunderstanding your point?
> 
> A bit :-)
> 
> EHCI/OHCI will need to ask TLL to enable TLL clock, because it's
> EHCI/OHCI who configure the port. Unless I misunderstood what Keshava
> did (and no, I didn't just read the code, too lazy :-)

The calls to the TLL driver only need to go into the OMAP-specific 
ehci-omap.c and ohci-omap3.c wrappers, as far as I can see.  So I don't 
think there's a need to modify the generic OHCI/EHCI drivers...


- Paul

Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

Hi,

On Tue, Oct 11, 2011 at 01:17:03PM -0600, Paul Walmsley wrote:
> > > On Tue, 11 Oct 2011, Felipe Balbi wrote:
> > > 
> > > > maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that
> > > > this IP comes from synopsys, and I'm not really keen on adding
> > > > OMAP-specific, integration-related knowledge on a driver which was
> > > > supposed to be reusable ;-)
> > > >
> > > > But at least for the time being, I guess that's what we need to do ;-)
> > > 
> > > Which IP is coming from Synopsys - the TLL ?  The EXPORT_SYMBOL approach 
> > 
> > TLL and UHH are OMAP-only wrappers. EHCI and OHCI are Synopsys IPs for
> > all I know.
> 
> Ah, I see.
> 
> > > shouldn't add anything OMAP-specific to the TLL driver.  So the exported 
> > > symbols should still be usable by drivers on other SoCs.  But perhaps I am 
> > > misunderstanding your point?
> > 
> > A bit :-)
> > 
> > EHCI/OHCI will need to ask TLL to enable TLL clock, because it's
> > EHCI/OHCI who configure the port. Unless I misunderstood what Keshava
> > did (and no, I didn't just read the code, too lazy :-)
> 
> The calls to the TLL driver only need to go into the OMAP-specific 
> ehci-omap.c and ohci-omap3.c wrappers, as far as I can see.  So I don't 
> think there's a need to modify the generic OHCI/EHCI drivers...

those where the ones I was talking about. That ehci-omap.c and
ohci-omap3.c refer to Synopsys IPs, so (in theory at least) that same
file can be used by any other SoC who uses a Synopsys IP.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]