linux-next: manual merge of the usb tree with the omap tree

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-omap2/clock3xxx_data.c and
arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap
tree and various commits from the usb tree.

I did a quick fix (which may be completely wrong - see below).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/clock3xxx_data.c
index 9ab817e,0579604..0000000
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@@ -3275,17 -3267,18 +3275,18 @@@ static struct omap_clk omap3xxx_clks[] 
  	CLK(NULL,	"gfx_l3_ick",	&gfx_l3_ick,	CK_3430ES1),
  	CLK(NULL,	"gfx_cg1_ck",	&gfx_cg1_ck,	CK_3430ES1),
  	CLK(NULL,	"gfx_cg2_ck",	&gfx_cg2_ck,	CK_3430ES1),
 -	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2 | CK_3517),
 -	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2 | CK_3517),
 +	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
 +	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
  	CLK(NULL,	"d2d_26m_fck",	&d2d_26m_fck,	CK_3430ES1),
 -	CLK(NULL,	"modem_fck",	&modem_fck,	CK_343X),
 -	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_343X),
 -	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_343X),
 +	CLK(NULL,	"modem_fck",	&modem_fck,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_34XX | CK_36XX),
  	CLK(NULL,	"gpt10_fck",	&gpt10_fck,	CK_3XXX),
  	CLK(NULL,	"gpt11_fck",	&gpt11_fck,	CK_3XXX),
 -	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),
 +	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 +	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 +	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("ehci-omap.0",	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),
  	CLK("omap-mcbsp.1",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
  	CLK("omap-mcbsp.5",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
  	CLK(NULL,	"core_96m_fck",	&core_96m_fck,	CK_3XXX),
@@@ -3309,26 -3302,27 +3310,27 @@@
  	CLK(NULL,	"core_12m_fck",	&core_12m_fck,	CK_3XXX),
  	CLK("omap_hdq.0", "fck",	&hdq_fck,	CK_3XXX),
  	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es1,	CK_3430ES1),
 -	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2),
 +	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
  	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es1,	CK_3430ES1),
 -	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2),
 +	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
  	CLK(NULL,	"core_l3_ick",	&core_l3_ick,	CK_3XXX),
- 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
- 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
+ 	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
 -	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2),
++	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
  	CLK(NULL,	"sdrc_ick",	&sdrc_ick,	CK_3XXX),
  	CLK(NULL,	"gpmc_fck",	&gpmc_fck,	CK_3XXX),
 -	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_343X),
 -	CLK(NULL,	"pka_ick",	&pka_ick,	CK_343X),
 +	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_34XX | CK_36XX),
 +	CLK(NULL,	"pka_ick",	&pka_ick,	CK_34XX | CK_36XX),
  	CLK(NULL,	"core_l4_ick",	&core_l4_ick,	CK_3XXX),
 -	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),
 +	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("ehci-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),
 -	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"icr_ick",	&icr_ick,	CK_343X),
 -	CLK("omap-aes",	"ick",	&aes2_ick,	CK_343X),
 -	CLK("omap-sham",	"ick",	&sha12_ick,	CK_343X),
 -	CLK(NULL,	"des2_ick",	&des2_ick,	CK_343X),
 +	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 +	CLK(NULL,	"icr_ick",	&icr_ick,	CK_34XX | CK_36XX),
 +	CLK("omap-aes",	"ick",	&aes2_ick,	CK_34XX | CK_36XX),
 +	CLK("omap-sham",	"ick",	&sha12_ick,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"des2_ick",	&des2_ick,	CK_34XX | CK_36XX),
  	CLK("mmci-omap-hs.1",	"ick",	&mmchs2_ick,	CK_3XXX),
  	CLK("mmci-omap-hs.0",	"ick",	&mmchs1_ick,	CK_3XXX),
 -	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_343X),
 +	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_34XX | CK_36XX),
  	CLK("omap_hdq.0", "ick",	&hdq_ick,	CK_3XXX),
  	CLK("omap2_mcspi.4", "ick",	&mcspi4_ick,	CK_3XXX),
  	CLK("omap2_mcspi.3", "ick",	&mcspi3_ick,	CK_3XXX),
@@@ -3361,14 -3355,17 +3363,17 @@@
  	CLK("omapdss",	"video_fck",	&dss_96m_fck,	CK_3XXX),
  	CLK("omapdss",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
  	CLK("omapdss",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
 -	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_343X),
 -	CLK(NULL,	"cam_ick",	&cam_ick,	CK_343X),
 -	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_343X),
 -	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
 +	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 +	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"cam_ick",	&cam_ick,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_34XX | CK_36XX),
 +	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("ehci-omap.0",	"hs_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
 +	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("ehci-omap.0",	"fs_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),
 +	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("ehci-omap.0",	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),
 -	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2),
 +	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2PLUS | CK_36XX),
  	CLK(NULL,	"gpt1_fck",	&gpt1_fck,	CK_3XXX),
  	CLK(NULL,	"wkup_32k_fck",	&wkup_32k_fck,	CK_3XXX),
  	CLK(NULL,	"gpio1_dbck",	&gpio1_dbck,	CK_3XXX),
diff --cc arch/arm/mach-omap2/clock44xx_data.c
index c426adc,bfcd19f..0000000
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@@ -3198,6 -2937,10 +3198,7 @@@ static struct omap_clk omap44xx_clks[] 
  	CLK(NULL,	"uart3_fck",			&uart3_fck,	CK_443X),
  	CLK(NULL,	"uart4_fck",			&uart4_fck,	CK_443X),
  	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck,	CK_443X),
+ 	CLK("ehci-omap.0",	"fs_fck",		&usb_host_fs_fck,	CK_443X),
 -	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk,	CK_443X),
 -	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk,	CK_443X),
 -	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk,	CK_443X),
  	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk,	CK_443X),
  	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk,	CK_443X),
  	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk,	CK_443X),

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

Hi Tony,

On Thu, Dec 23, 2010 at 05:18:59PM +1100, Stephen Rothwell wrote:
>Today's linux-next merge of the usb tree got a conflict in
>arch/arm/mach-omap2/clock3xxx_data.c and
>arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap
>tree and various commits from the usb tree.
>
>I did a quick fix (which may be completely wrong - see below).

could you check if the below fix is good enough. The musb part seems to
be fine.

>diff --cc arch/arm/mach-omap2/clock3xxx_data.c
>index 9ab817e,0579604..0000000
>--- a/arch/arm/mach-omap2/clock3xxx_data.c
>+++ b/arch/arm/mach-omap2/clock3xxx_data.c
>@@@ -3275,17 -3267,18 +3275,18 @@@ static struct omap_clk omap3xxx_clks[]
>  	CLK(NULL,	"gfx_l3_ick",	&gfx_l3_ick,	CK_3430ES1),
>  	CLK(NULL,	"gfx_cg1_ck",	&gfx_cg1_ck,	CK_3430ES1),
>  	CLK(NULL,	"gfx_cg2_ck",	&gfx_cg2_ck,	CK_3430ES1),
> -	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2 | CK_3517),
> -	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2 | CK_3517),
> +	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
> +	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
>  	CLK(NULL,	"d2d_26m_fck",	&d2d_26m_fck,	CK_3430ES1),
> -	CLK(NULL,	"modem_fck",	&modem_fck,	CK_343X),
> -	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_343X),
> -	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_343X),
> +	CLK(NULL,	"modem_fck",	&modem_fck,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_34XX | CK_36XX),
>  	CLK(NULL,	"gpt10_fck",	&gpt10_fck,	CK_3XXX),
>  	CLK(NULL,	"gpt11_fck",	&gpt11_fck,	CK_3XXX),
> -	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),
> +	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> +	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> +	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>+ 	CLK("ehci-omap.0",	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),
>  	CLK("omap-mcbsp.1",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
>  	CLK("omap-mcbsp.5",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
>  	CLK(NULL,	"core_96m_fck",	&core_96m_fck,	CK_3XXX),
>@@@ -3309,26 -3302,27 +3310,27 @@@
>  	CLK(NULL,	"core_12m_fck",	&core_12m_fck,	CK_3XXX),
>  	CLK("omap_hdq.0", "fck",	&hdq_fck,	CK_3XXX),
>  	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es1,	CK_3430ES1),
> -	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2),
> +	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
>  	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es1,	CK_3430ES1),
> -	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2),
> +	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
>  	CLK(NULL,	"core_l3_ick",	&core_l3_ick,	CK_3XXX),
>- 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
>- 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
>+ 	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
> -	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2),
>++	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
>  	CLK(NULL,	"sdrc_ick",	&sdrc_ick,	CK_3XXX),
>  	CLK(NULL,	"gpmc_fck",	&gpmc_fck,	CK_3XXX),
> -	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_343X),
> -	CLK(NULL,	"pka_ick",	&pka_ick,	CK_343X),
> +	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_34XX | CK_36XX),
> +	CLK(NULL,	"pka_ick",	&pka_ick,	CK_34XX | CK_36XX),
>  	CLK(NULL,	"core_l4_ick",	&core_l4_ick,	CK_3XXX),
> -	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),
> +	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>+ 	CLK("ehci-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),
> -	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"icr_ick",	&icr_ick,	CK_343X),
> -	CLK("omap-aes",	"ick",	&aes2_ick,	CK_343X),
> -	CLK("omap-sham",	"ick",	&sha12_ick,	CK_343X),
> -	CLK(NULL,	"des2_ick",	&des2_ick,	CK_343X),
> +	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> +	CLK(NULL,	"icr_ick",	&icr_ick,	CK_34XX | CK_36XX),
> +	CLK("omap-aes",	"ick",	&aes2_ick,	CK_34XX | CK_36XX),
> +	CLK("omap-sham",	"ick",	&sha12_ick,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"des2_ick",	&des2_ick,	CK_34XX | CK_36XX),
>  	CLK("mmci-omap-hs.1",	"ick",	&mmchs2_ick,	CK_3XXX),
>  	CLK("mmci-omap-hs.0",	"ick",	&mmchs1_ick,	CK_3XXX),
> -	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_343X),
> +	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_34XX | CK_36XX),
>  	CLK("omap_hdq.0", "ick",	&hdq_ick,	CK_3XXX),
>  	CLK("omap2_mcspi.4", "ick",	&mcspi4_ick,	CK_3XXX),
>  	CLK("omap2_mcspi.3", "ick",	&mcspi3_ick,	CK_3XXX),
>@@@ -3361,14 -3355,17 +3363,17 @@@
>  	CLK("omapdss",	"video_fck",	&dss_96m_fck,	CK_3XXX),
>  	CLK("omapdss",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
>  	CLK("omapdss",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
> -	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_343X),
> -	CLK(NULL,	"cam_ick",	&cam_ick,	CK_343X),
> -	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_343X),
> -	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
> +	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> +	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"cam_ick",	&cam_ick,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_34XX | CK_36XX),
> +	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>+ 	CLK("ehci-omap.0",	"hs_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
> +	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>+ 	CLK("ehci-omap.0",	"fs_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),
> +	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>+ 	CLK("ehci-omap.0",	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),
> -	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2),
> +	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2PLUS | CK_36XX),
>  	CLK(NULL,	"gpt1_fck",	&gpt1_fck,	CK_3XXX),
>  	CLK(NULL,	"wkup_32k_fck",	&wkup_32k_fck,	CK_3XXX),
>  	CLK(NULL,	"gpio1_dbck",	&gpio1_dbck,	CK_3XXX),
>diff --cc arch/arm/mach-omap2/clock44xx_data.c
>index c426adc,bfcd19f..0000000
>--- a/arch/arm/mach-omap2/clock44xx_data.c
>+++ b/arch/arm/mach-omap2/clock44xx_data.c
>@@@ -3198,6 -2937,10 +3198,7 @@@ static struct omap_clk omap44xx_clks[]
>  	CLK(NULL,	"uart3_fck",			&uart3_fck,	CK_443X),
>  	CLK(NULL,	"uart4_fck",			&uart4_fck,	CK_443X),
>  	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck,	CK_443X),
>+ 	CLK("ehci-omap.0",	"fs_fck",		&usb_host_fs_fck,	CK_443X),
> -	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk,	CK_443X),
> -	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk,	CK_443X),
> -	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk,	CK_443X),
>  	CLK(NULL,	"utmi_p1_gfclk",		&utmi_p1_gfclk,	CK_443X),
>  	CLK(NULL,	"usb_host_hs_utmi_p1_clk",	&usb_host_hs_utmi_p1_clk,	CK_443X),
>  	CLK(NULL,	"utmi_p2_gfclk",		&utmi_p2_gfclk,	CK_443X),

-- 
balbi

Re: linux-next: manual merge of the usb tree with the omap tree

[Cousson, Benoit]

+ Paul "the omap clock guru".

At first glance, that seems almost good. 
Except for a couple of nodes that seems to lose their 3630 support.

I'm just wondering why the original usb clock node is 
kept after the introduction of the "ehci-omap.0" clock
node. But this is anyway harmless.

What commits are generating this conflict?

On 12/23/2010 7:18 AM, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the usb tree got a conflict in
> arch/arm/mach-omap2/clock3xxx_data.c and
> arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap
> tree and various commits from the usb tree.
> 
> I did a quick fix (which may be completely wrong - see below).

> diff --cc arch/arm/mach-omap2/clock3xxx_data.c
> index 9ab817e,0579604..0000000
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@@ -3275,17 -3267,18 +3275,18 @@@ static struct omap_clk omap3xxx_clks[] 
>   	CLK(NULL,	"gfx_l3_ick",	&gfx_l3_ick,	CK_3430ES1),
>   	CLK(NULL,	"gfx_cg1_ck",	&gfx_cg1_ck,	CK_3430ES1),
>   	CLK(NULL,	"gfx_cg2_ck",	&gfx_cg2_ck,	CK_3430ES1),
>  -	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2 | CK_3517),
>  -	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2 | CK_3517),
>  +	CLK(NULL,	"sgx_fck",	&sgx_fck,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
>  +	CLK(NULL,	"sgx_ick",	&sgx_ick,	CK_3430ES2PLUS | CK_3517 | CK_36XX),
>   	CLK(NULL,	"d2d_26m_fck",	&d2d_26m_fck,	CK_3430ES1),
>  -	CLK(NULL,	"modem_fck",	&modem_fck,	CK_343X),
>  -	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_343X),
>  -	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_343X),
>  +	CLK(NULL,	"modem_fck",	&modem_fck,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"sad2d_ick",	&sad2d_ick,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"mad2d_ick",	&mad2d_ick,	CK_34XX | CK_36XX),
>   	CLK(NULL,	"gpt10_fck",	&gpt10_fck,	CK_3XXX),
>   	CLK(NULL,	"gpt11_fck",	&gpt11_fck,	CK_3XXX),
>  -	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2 | CK_AM35XX),
>  -	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2 | CK_AM35XX),
>  -	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),
>  +	CLK(NULL,	"cpefuse_fck",	&cpefuse_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>  +	CLK(NULL,	"ts_fck",	&ts_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>  +	CLK(NULL,	"usbtll_fck",	&usbtll_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),

That one could be removed after the introduction of the following one if the
clk_get(dev, "usbtll_fck") API is used.

> + 	CLK("ehci-omap.0",	"usbtll_fck",	&usbtll_fck,	CK_3430ES2 | CK_AM35XX),

If only that one is kept it should be: 
+ 	CLK("ehci-omap.0",	"usbtll_fck",	&usbtll_fck,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),

Assuming that one of the conflicting commits was trying to add the 3630 support.

>   	CLK("omap-mcbsp.1",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
>   	CLK("omap-mcbsp.5",	"prcm_fck",	&core_96m_fck,	CK_3XXX),
>   	CLK(NULL,	"core_96m_fck",	&core_96m_fck,	CK_3XXX),
> @@@ -3309,26 -3302,27 +3310,27 @@@
>   	CLK(NULL,	"core_12m_fck",	&core_12m_fck,	CK_3XXX),
>   	CLK("omap_hdq.0", "fck",	&hdq_fck,	CK_3XXX),
>   	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es1,	CK_3430ES1),
>  -	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2),
>  +	CLK(NULL,	"ssi_ssr_fck",	&ssi_ssr_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
>   	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es1,	CK_3430ES1),
>  -	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2),
>  +	CLK(NULL,	"ssi_sst_fck",	&ssi_sst_fck_3430es2,	CK_3430ES2PLUS | CK_36XX),
>   	CLK(NULL,	"core_l3_ick",	&core_l3_ick,	CK_3XXX),
> - 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
> - 	CLK("musb_hdrc",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
> + 	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es1,	CK_3430ES1),
>  -	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2),
> ++	CLK("musb-omap2430",	"ick",	&hsotgusb_ick_3430es2,	CK_3430ES2PLUS | CK_36XX),
>   	CLK(NULL,	"sdrc_ick",	&sdrc_ick,	CK_3XXX),
>   	CLK(NULL,	"gpmc_fck",	&gpmc_fck,	CK_3XXX),
>  -	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_343X),
>  -	CLK(NULL,	"pka_ick",	&pka_ick,	CK_343X),
>  +	CLK(NULL,	"security_l3_ick", &security_l3_ick, CK_34XX | CK_36XX),
>  +	CLK(NULL,	"pka_ick",	&pka_ick,	CK_34XX | CK_36XX),
>   	CLK(NULL,	"core_l4_ick",	&core_l4_ick,	CK_3XXX),
>  -	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),
>  +	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> + 	CLK("ehci-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2 | CK_AM35XX),

ditto, should probably be: 
 + 	CLK("ehci-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),

>  -	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2 | CK_AM35XX),
>  -	CLK(NULL,	"icr_ick",	&icr_ick,	CK_343X),
>  -	CLK("omap-aes",	"ick",	&aes2_ick,	CK_343X),
>  -	CLK("omap-sham",	"ick",	&sha12_ick,	CK_343X),
>  -	CLK(NULL,	"des2_ick",	&des2_ick,	CK_343X),
>  +	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>  +	CLK(NULL,	"icr_ick",	&icr_ick,	CK_34XX | CK_36XX),
>  +	CLK("omap-aes",	"ick",	&aes2_ick,	CK_34XX | CK_36XX),
>  +	CLK("omap-sham",	"ick",	&sha12_ick,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"des2_ick",	&des2_ick,	CK_34XX | CK_36XX),
>   	CLK("mmci-omap-hs.1",	"ick",	&mmchs2_ick,	CK_3XXX),
>   	CLK("mmci-omap-hs.0",	"ick",	&mmchs1_ick,	CK_3XXX),
>  -	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_343X),
>  +	CLK(NULL,	"mspro_ick",	&mspro_ick,	CK_34XX | CK_36XX),
>   	CLK("omap_hdq.0", "ick",	&hdq_ick,	CK_3XXX),
>   	CLK("omap2_mcspi.4", "ick",	&mcspi4_ick,	CK_3XXX),
>   	CLK("omap2_mcspi.3", "ick",	&mcspi3_ick,	CK_3XXX),
> @@@ -3361,14 -3355,17 +3363,17 @@@
>   	CLK("omapdss",	"video_fck",	&dss_96m_fck,	CK_3XXX),
>   	CLK("omapdss",	"dss2_fck",	&dss2_alwon_fck, CK_3XXX),
>   	CLK("omapdss",	"ick",		&dss_ick_3430es1,	CK_3430ES1),
>  -	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2 | CK_AM35XX),
>  -	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_343X),
>  -	CLK(NULL,	"cam_ick",	&cam_ick,	CK_343X),
>  -	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_343X),
>  -	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
>  +	CLK("omapdss",	"ick",		&dss_ick_3430es2,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>  +	CLK(NULL,	"cam_mclk",	&cam_mclk,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"cam_ick",	&cam_ick,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"csi2_96m_fck",	&csi2_96m_fck,	CK_34XX | CK_36XX),
>  +	CLK(NULL,	"usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> + 	CLK("ehci-omap.0",	"hs_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),

ditto

>  -	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
>  +	CLK(NULL,	"usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> + 	CLK("ehci-omap.0",	"fs_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),

ditto

>  -	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),
>  +	CLK(NULL,	"usbhost_ick",	&usbhost_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> + 	CLK("ehci-omap.0",	"usbhost_ick",	&usbhost_ick,	CK_3430ES2 | CK_AM35XX),

ditto

>  -	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2),
>  +	CLK(NULL,	"usim_fck",	&usim_fck,	CK_3430ES2PLUS | CK_36XX),
>   	CLK(NULL,	"gpt1_fck",	&gpt1_fck,	CK_3XXX),
>   	CLK(NULL,	"wkup_32k_fck",	&wkup_32k_fck,	CK_3XXX),
>   	CLK(NULL,	"gpio1_dbck",	&gpio1_dbck,	CK_3XXX),
> diff --cc arch/arm/mach-omap2/clock44xx_data.c
> index c426adc,bfcd19f..0000000
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@@ -3198,6 -2937,10 +3198,7 @@@ static struct omap_clk omap44xx_clks[] 
>   	CLK(NULL,	"uart3_fck",			&uart3_fck,	CK_443X),
>   	CLK(NULL,	"uart4_fck",			&uart4_fck,	CK_443X),
>   	CLK(NULL,	"usb_host_fs_fck",		&usb_host_fs_fck,	CK_443X),
> + 	CLK("ehci-omap.0",	"fs_fck",		&usb_host_fs_fck,	CK_443X),
>  -	CLK(NULL,	"usb_host_hs_utmi_p3_clk",	&usb_host_hs_utmi_p3_clk,	CK_443X),
>  -	CLK(NULL,	"usb_host_hs_hsic60m_p1_clk",	&usb_host_hs_hsic60m_p1_clk,	CK_443X),
>  -	CLK(NULL,	"usb_host_hs_hsic60m_p2_clk",	&usb_host_hs_hsic60m_p2_clk,	CK_443X),

I'm not sure these 3 nodes should be removed. AFAIR, they were just slightly moved in lo branch.

Regards,
Benoit

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

Hi,

2010/12/24 Cousson, Benoit <b-cousson@ti.com>:
> + Paul "the omap clock guru".
>
> At first glance, that seems almost good.
> Except for a couple of nodes that seems to lose their 3630 support.
>
> I'm just wondering why the original usb clock node is
> kept after the introduction of the "ehci-omap.0" clock
> node. But this is anyway harmless.
>
> What commits are generating this conflict?
>
> On 12/23/2010 7:18 AM, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the usb tree got a conflict in
>> arch/arm/mach-omap2/clock3xxx_data.c and
>> arch/arm/mach-omap2/clock44xx_data.c between various commits from the omap
>> tree and various commits from the usb tree.
>>
>> I did a quick fix (which may be completely wrong - see below).
>
>> diff --cc arch/arm/mach-omap2/clock3xxx_data.c
>> index 9ab817e,0579604..0000000
>> --- a/arch/arm/mach-omap2/clock3xxx_data.c
>> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
>> @@@ -3275,17 -3267,18 +3275,18 @@@ static struct omap_clk omap3xxx_clks[]
>>       CLK(NULL,       "gfx_l3_ick",   &gfx_l3_ick,    CK_3430ES1),
>>       CLK(NULL,       "gfx_cg1_ck",   &gfx_cg1_ck,    CK_3430ES1),
>>       CLK(NULL,       "gfx_cg2_ck",   &gfx_cg2_ck,    CK_3430ES1),
>>  -    CLK(NULL,       "sgx_fck",      &sgx_fck,       CK_3430ES2 | CK_3517),
>>  -    CLK(NULL,       "sgx_ick",      &sgx_ick,       CK_3430ES2 | CK_3517),
>>  +    CLK(NULL,       "sgx_fck",      &sgx_fck,       CK_3430ES2PLUS | CK_3517 | CK_36XX),
>>  +    CLK(NULL,       "sgx_ick",      &sgx_ick,       CK_3430ES2PLUS | CK_3517 | CK_36XX),
>>       CLK(NULL,       "d2d_26m_fck",  &d2d_26m_fck,   CK_3430ES1),
>>  -    CLK(NULL,       "modem_fck",    &modem_fck,     CK_343X),
>>  -    CLK(NULL,       "sad2d_ick",    &sad2d_ick,     CK_343X),
>>  -    CLK(NULL,       "mad2d_ick",    &mad2d_ick,     CK_343X),
>>  +    CLK(NULL,       "modem_fck",    &modem_fck,     CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "sad2d_ick",    &sad2d_ick,     CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "mad2d_ick",    &mad2d_ick,     CK_34XX | CK_36XX),
>>       CLK(NULL,       "gpt10_fck",    &gpt10_fck,     CK_3XXX),
>>       CLK(NULL,       "gpt11_fck",    &gpt11_fck,     CK_3XXX),
>>  -    CLK(NULL,       "cpefuse_fck",  &cpefuse_fck,   CK_3430ES2 | CK_AM35XX),
>>  -    CLK(NULL,       "ts_fck",       &ts_fck,        CK_3430ES2 | CK_AM35XX),
>>  -    CLK(NULL,       "usbtll_fck",   &usbtll_fck,    CK_3430ES2 | CK_AM35XX),
>>  +    CLK(NULL,       "cpefuse_fck",  &cpefuse_fck,   CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>>  +    CLK(NULL,       "ts_fck",       &ts_fck,        CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>>  +    CLK(NULL,       "usbtll_fck",   &usbtll_fck,    CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>
> That one could be removed after the introduction of the following one if the
> clk_get(dev, "usbtll_fck") API is used.
>
>> +     CLK("ehci-omap.0",      "usbtll_fck",   &usbtll_fck,    CK_3430ES2 | CK_AM35XX),
>
> If only that one is kept it should be:
> +       CLK("ehci-omap.0",      "usbtll_fck",   &usbtll_fck,    CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>
> Assuming that one of the conflicting commits was trying to add the 3630 support.
>
>>       CLK("omap-mcbsp.1",     "prcm_fck",     &core_96m_fck,  CK_3XXX),
>>       CLK("omap-mcbsp.5",     "prcm_fck",     &core_96m_fck,  CK_3XXX),
>>       CLK(NULL,       "core_96m_fck", &core_96m_fck,  CK_3XXX),
>> @@@ -3309,26 -3302,27 +3310,27 @@@
>>       CLK(NULL,       "core_12m_fck", &core_12m_fck,  CK_3XXX),
>>       CLK("omap_hdq.0", "fck",        &hdq_fck,       CK_3XXX),
>>       CLK(NULL,       "ssi_ssr_fck",  &ssi_ssr_fck_3430es1,   CK_3430ES1),
>>  -    CLK(NULL,       "ssi_ssr_fck",  &ssi_ssr_fck_3430es2,   CK_3430ES2),
>>  +    CLK(NULL,       "ssi_ssr_fck",  &ssi_ssr_fck_3430es2,   CK_3430ES2PLUS | CK_36XX),
>>       CLK(NULL,       "ssi_sst_fck",  &ssi_sst_fck_3430es1,   CK_3430ES1),
>>  -    CLK(NULL,       "ssi_sst_fck",  &ssi_sst_fck_3430es2,   CK_3430ES2),
>>  +    CLK(NULL,       "ssi_sst_fck",  &ssi_sst_fck_3430es2,   CK_3430ES2PLUS | CK_36XX),
>>       CLK(NULL,       "core_l3_ick",  &core_l3_ick,   CK_3XXX),
>> -     CLK("musb_hdrc",        "ick",  &hsotgusb_ick_3430es1,  CK_3430ES1),
>> -     CLK("musb_hdrc",        "ick",  &hsotgusb_ick_3430es2,  CK_3430ES2PLUS | CK_36XX),
>> +     CLK("musb-omap2430",    "ick",  &hsotgusb_ick_3430es1,  CK_3430ES1),
>>  -    CLK("musb-omap2430",    "ick",  &hsotgusb_ick_3430es2,  CK_3430ES2),
>> ++    CLK("musb-omap2430",    "ick",  &hsotgusb_ick_3430es2,  CK_3430ES2PLUS | CK_36XX),
>>       CLK(NULL,       "sdrc_ick",     &sdrc_ick,      CK_3XXX),
>>       CLK(NULL,       "gpmc_fck",     &gpmc_fck,      CK_3XXX),
>>  -    CLK(NULL,       "security_l3_ick", &security_l3_ick, CK_343X),
>>  -    CLK(NULL,       "pka_ick",      &pka_ick,       CK_343X),
>>  +    CLK(NULL,       "security_l3_ick", &security_l3_ick, CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "pka_ick",      &pka_ick,       CK_34XX | CK_36XX),
>>       CLK(NULL,       "core_l4_ick",  &core_l4_ick,   CK_3XXX),
>>  -    CLK(NULL,       "usbtll_ick",   &usbtll_ick,    CK_3430ES2 | CK_AM35XX),
>>  +    CLK(NULL,       "usbtll_ick",   &usbtll_ick,    CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>> +     CLK("ehci-omap.0",      "usbtll_ick",   &usbtll_ick,    CK_3430ES2 | CK_AM35XX),
>
> ditto, should probably be:
>  +      CLK("ehci-omap.0",      "usbtll_ick",   &usbtll_ick,    CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>
>>  -    CLK("mmci-omap-hs.2",   "ick",  &mmchs3_ick,    CK_3430ES2 | CK_AM35XX),
>>  -    CLK(NULL,       "icr_ick",      &icr_ick,       CK_343X),
>>  -    CLK("omap-aes", "ick",  &aes2_ick,      CK_343X),
>>  -    CLK("omap-sham",        "ick",  &sha12_ick,     CK_343X),
>>  -    CLK(NULL,       "des2_ick",     &des2_ick,      CK_343X),
>>  +    CLK("mmci-omap-hs.2",   "ick",  &mmchs3_ick,    CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>>  +    CLK(NULL,       "icr_ick",      &icr_ick,       CK_34XX | CK_36XX),
>>  +    CLK("omap-aes", "ick",  &aes2_ick,      CK_34XX | CK_36XX),
>>  +    CLK("omap-sham",        "ick",  &sha12_ick,     CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "des2_ick",     &des2_ick,      CK_34XX | CK_36XX),
>>       CLK("mmci-omap-hs.1",   "ick",  &mmchs2_ick,    CK_3XXX),
>>       CLK("mmci-omap-hs.0",   "ick",  &mmchs1_ick,    CK_3XXX),
>>  -    CLK(NULL,       "mspro_ick",    &mspro_ick,     CK_343X),
>>  +    CLK(NULL,       "mspro_ick",    &mspro_ick,     CK_34XX | CK_36XX),
>>       CLK("omap_hdq.0", "ick",        &hdq_ick,       CK_3XXX),
>>       CLK("omap2_mcspi.4", "ick",     &mcspi4_ick,    CK_3XXX),
>>       CLK("omap2_mcspi.3", "ick",     &mcspi3_ick,    CK_3XXX),
>> @@@ -3361,14 -3355,17 +3363,17 @@@
>>       CLK("omapdss",  "video_fck",    &dss_96m_fck,   CK_3XXX),
>>       CLK("omapdss",  "dss2_fck",     &dss2_alwon_fck, CK_3XXX),
>>       CLK("omapdss",  "ick",          &dss_ick_3430es1,       CK_3430ES1),
>>  -    CLK("omapdss",  "ick",          &dss_ick_3430es2,       CK_3430ES2 | CK_AM35XX),
>>  -    CLK(NULL,       "cam_mclk",     &cam_mclk,      CK_343X),
>>  -    CLK(NULL,       "cam_ick",      &cam_ick,       CK_343X),
>>  -    CLK(NULL,       "csi2_96m_fck", &csi2_96m_fck,  CK_343X),
>>  -    CLK(NULL,       "usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
>>  +    CLK("omapdss",  "ick",          &dss_ick_3430es2,       CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>>  +    CLK(NULL,       "cam_mclk",     &cam_mclk,      CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "cam_ick",      &cam_ick,       CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "csi2_96m_fck", &csi2_96m_fck,  CK_34XX | CK_36XX),
>>  +    CLK(NULL,       "usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>> +     CLK("ehci-omap.0",      "hs_fck", &usbhost_120m_fck, CK_3430ES2 | CK_AM35XX),
>
> ditto
>
>>  -    CLK(NULL,       "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
>>  +    CLK(NULL,       "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>> +     CLK("ehci-omap.0",      "fs_fck", &usbhost_48m_fck, CK_3430ES2 | CK_AM35XX),
>
> ditto
>
>>  -    CLK(NULL,       "usbhost_ick",  &usbhost_ick,   CK_3430ES2 | CK_AM35XX),
>>  +    CLK(NULL,       "usbhost_ick",  &usbhost_ick,   CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
>> +     CLK("ehci-omap.0",      "usbhost_ick",  &usbhost_ick,   CK_3430ES2 | CK_AM35XX),
>
> ditto
>
>>  -    CLK(NULL,       "usim_fck",     &usim_fck,      CK_3430ES2),
>>  +    CLK(NULL,       "usim_fck",     &usim_fck,      CK_3430ES2PLUS | CK_36XX),
>>       CLK(NULL,       "gpt1_fck",     &gpt1_fck,      CK_3XXX),
>>       CLK(NULL,       "wkup_32k_fck", &wkup_32k_fck,  CK_3XXX),
>>       CLK(NULL,       "gpio1_dbck",   &gpio1_dbck,    CK_3XXX),
>> diff --cc arch/arm/mach-omap2/clock44xx_data.c
>> index c426adc,bfcd19f..0000000
>> --- a/arch/arm/mach-omap2/clock44xx_data.c
>> +++ b/arch/arm/mach-omap2/clock44xx_data.c
>> @@@ -3198,6 -2937,10 +3198,7 @@@ static struct omap_clk omap44xx_clks[]
>>       CLK(NULL,       "uart3_fck",                    &uart3_fck,     CK_443X),
>>       CLK(NULL,       "uart4_fck",                    &uart4_fck,     CK_443X),
>>       CLK(NULL,       "usb_host_fs_fck",              &usb_host_fs_fck,       CK_443X),
>> +     CLK("ehci-omap.0",      "fs_fck",               &usb_host_fs_fck,       CK_443X),
>>  -    CLK(NULL,       "usb_host_hs_utmi_p3_clk",      &usb_host_hs_utmi_p3_clk,       CK_443X),
>>  -    CLK(NULL,       "usb_host_hs_hsic60m_p1_clk",   &usb_host_hs_hsic60m_p1_clk,    CK_443X),
>>  -    CLK(NULL,       "usb_host_hs_hsic60m_p2_clk",   &usb_host_hs_hsic60m_p2_clk,    CK_443X),
>
> I'm not sure these 3 nodes should be removed. AFAIR, they were just slightly moved in lo branch.

Even with the fixes above, ehci on my beagle xM/Panda still doesn't work
with 2.6.37-next-20110106+, follows the failure messages:

[   57.918182] bus: 'platform': really_probe: probing driver ehci-omap
with device ehci-omap.0
[   57.918243] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
[   57.918273] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
[   57.918304] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
[   57.918457] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x10
[   57.918487] ehci-omap ehci-omap.0: TLL RESET DONE
[   57.918487] ehci-omap ehci-omap.0: OMAP3 ES version > ES2.1
[   57.918518] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=31c
[   58.922302] ehci-omap ehci-omap.0: phy reset operation timed out
[   59.930114] ehci-omap ehci-omap.0: phy reset operation timed out
[   59.930145] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
cc=1 pcc=3 ordered ports=3
[   59.930175] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1
uframes 256/512/1024 park
[   59.930206] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[   59.936218] drivers/usb/core/inode.c: creating file 'devices'
[   59.936279] drivers/usb/core/inode.c: creating file '001'

Any ideas?

thanks,
-- 
Lei Ming

RE: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

Ming Lei wrote:

> Hi,
>
> 2010/12/24 Cousson, Benoit <b-cousson@ti.com>:
> > + Paul "the omap clock guru".
> >
> > At first glance, that seems almost good.
> > Except for a couple of nodes that seems to lose their 3630 support.
> >
> > I'm just wondering why the original usb clock node is
> > kept after the introduction of the "ehci-omap.0" clock
> > node. But this is anyway harmless.
> >
> > What commits are generating this conflict?
> >
> > On 12/23/2010 7:18 AM, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the usb tree got a conflict in
> >> arch/arm/mach-omap2/clock3xxx_data.c and
> >> arch/arm/mach-omap2/clock44xx_data.c between various commits from the
omap
> >> tree and various commits from the usb tree.
> >>
> >> I did a quick fix (which may be completely wrong - see below).
> >

<snip>

> > I'm not sure these 3 nodes should be removed. AFAIR, they
> were just slightly moved in lo branch.
>
> Even with the fixes above, ehci on my beagle xM/Panda still
> doesn't work
> with 2.6.37-next-20110106+, follows the failure messages:
>
> [   57.918182] bus: 'platform': really_probe: probing driver
ehci-omapwith device ehci-omap.0
> [   57.918243] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
> [   57.918273] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
> [   57.918304] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
> [   57.918457] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x10
> [   57.918487] ehci-omap ehci-omap.0: TLL RESET DONE
> [   57.918487] ehci-omap ehci-omap.0: OMAP3 ES version > ES2.1
> [   57.918518] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=31c
> [   58.922302] ehci-omap ehci-omap.0: phy reset operation timed out
> [   59.930114] ehci-omap ehci-omap.0: phy reset operation timed out
> [   59.930145] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1
pcc=3 ordered ports=3
> [   59.930175] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1
uframes 256/512/1024 park
> [   59.930206] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [   59.936218] drivers/usb/core/inode.c: creating file 'devices'
> [   59.936279] drivers/usb/core/inode.c: creating file '001'
>
> Any ideas?
>

I'll take a look in a short while. I don't have an XM to
test, so you'll have to help me out here.

- Anand

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

Hi,

2011/1/6 Anand Gadiyar <gadiyar@ti.com>:

> I'll take a look in a short while. I don't have an XM to
> test, so you'll have to help me out here.

No problem for me, :-)

thanks,
-- 
Lei Ming

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

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

Hi,

2011/1/6 Ming Lei <tom.leiming@gmail.com>:
> Hi,
>
> 2011/1/6 Anand Gadiyar <gadiyar@ti.com>:
>
>> I'll take a look in a short while. I don't have an XM to
>> test, so you'll have to help me out here.
>
> No problem for me, :-)

I see why the beagle xM does not work, the attachment patch is
needed to make it working.

But the ehci on panda(omap4430) still does not work with
2.6.37-next-20110106+, and follows the failure messages:

[   46.572601] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   46.580017] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
[   46.580078] bus: 'platform': add driver ehci-omap
[   46.580139] bus: 'platform': driver_probe_device: matched device
ehci-omap.0 with driver ehci-omap
[   46.580169] bus: 'platform': really_probe: probing driver ehci-omap
with device ehci-omap.0
[   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
[   46.580200] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
[   46.580291] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x50700100
[   46.580352] ehci-omap ehci-omap.0: TLL RESET DONE
[   46.580352] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=1c
[   46.580383] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
cc=1 pcc=3 ordered ports=3
[   46.580383] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1
uframes 256/512/1024 park LPM
[   46.580383] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[   46.588592] drivers/usb/core/inode.c: creating file 'devices'
[   46.588623] drivers/usb/core/inode.c: creating file '001'
[   46.588684] device: 'usbmon1': device_add
[   46.588867] PM: Adding info for No Bus:usbmon1
[   46.590026] ehci-omap ehci-omap.0: new USB bus registered, assigned
bus number 1
[   46.645721] ehci-omap ehci-omap.0: park 0
[   46.645721] ehci-omap ehci-omap.0: support lpm
[   46.645751] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00
[   46.651763] ehci-omap ehci-omap.0: reset command 0080b02  park=3
ithresh=8 period=1024 Reset HALT
[   46.651763] ehci-omap ehci-omap.0: init command 0010005 (park)=0
ithresh=1 period=512 RUN
[   46.661254] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[   46.667297] usb usb1: rpm_resume flags 0x0
[   46.667297] usb usb1: rpm_resume returns 1
[   46.667358] usb usb1: default language 0x0409
[   46.667358] usb usb1: udev 1, busnum 1, minor = 0
[   46.667388] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   46.675476] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[   46.683288] usb usb1: Product: OMAP-EHCI Host Controller
[   46.689086] usb usb1: Manufacturer: Linux 2.6.37-next-20110106+ ehci_hcd
[   46.696350] usb usb1: SerialNumber: ehci-omap.0
[   46.701354] device: 'usb1': device_add
[   46.701568] bus: 'usb': add device usb1
[   46.701629] PM: Adding info for usb:usb1
[   46.702758] bus: 'usb': driver_probe_device: matched device usb1
with driver usb
[   46.702758] bus: 'usb': really_probe: probing driver usb with device usb1
[   46.702819] usb usb1: usb_probe_device
[   46.702819] usb usb1: configuration #1 chosen from 1 choice
[   46.702850] usb usb1: rpm_resume flags 0x4
[   46.702850] usb usb1: rpm_resume returns 1
[   46.702911] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[   46.702911] device: '1-0:1.0': device_add
[   46.702941] bus: 'usb': add device 1-0:1.0
[   46.703002] PM: Adding info for usb:1-0:1.0
[   46.703430] bus: 'usb': driver_probe_device: matched device 1-0:1.0
with driver hub
[   46.703460] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0
[   46.703460] hub 1-0:1.0: usb_probe_interface
[   46.703491] hub 1-0:1.0: usb_probe_interface - got id
[   46.703491] usb usb1: rpm_resume flags 0x4
[   46.703491] usb usb1: rpm_resume returns 1
[   46.703521] hub 1-0:1.0: USB hub found
[   46.707427] hub 1-0:1.0: 3 ports detected
[   46.715698] hub 1-0:1.0: standalone hub
[   46.715698] hub 1-0:1.0: individual port power switching
[   46.715728] hub 1-0:1.0: individual port over-current protection
[   46.715728] hub 1-0:1.0: power on to power good time: 20ms
[   46.715759] hub 1-0:1.0: local power source is good
[   46.715759] hub 1-0:1.0: enabling power on all ports
[   46.715820] driver: '1-0:1.0': driver_bound: bound to device 'hub'
[   46.715820] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
[   46.715850] device: 'ep_81': device_add
[   46.717468] PM: Adding info for No Bus:ep_81
[   46.717498] device: 'usbdev1.1': device_add
[   46.717590] PM: Adding info for No Bus:usbdev1.1
[   46.717773] drivers/usb/core/inode.c: creating file '001'
[   46.717803] driver: 'usb1': driver_bound: bound to device 'usb'
[   46.717803] bus: 'usb': really_probe: bound device usb1 to driver usb
[   46.717834] device: 'ep_00': device_add
[   46.717895] PM: Adding info for No Bus:ep_00
[   46.717895] usb usb1: rpm_suspend flags 0xc
[   46.717926] usb usb1: rpm_suspend returns -16
[   46.717926] ehci-omap ehci-omap.0: ...powerup ports...
[   46.747161] driver: 'ehci-omap.0': driver_bound: bound to device 'ehci-omap'
[   46.747192] bus: 'platform': really_probe: bound device ehci-omap.0
to driver ehci-omap
[   46.809661] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0
 ACK POWER sig=j CSC CONNECT
[   46.809692] hub 1-0:1.0: port 1: status 0501 change 0001
[   46.911193] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 0000
[   46.911193] hub 1-0:1.0: rpm_resume flags 0x4
[   46.911193] hub 1-0:1.0: rpm_resume returns 1
[   46.911224] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
[   46.973907] ehci-omap ehci-omap.0: port 1 high speed
[   46.973907] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0
 ACK POWER sig=se0 PE CONNECT
[   47.036102] usb 1-1: new high speed USB device using ehci-omap and address 2
[   47.044036] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 1
[   47.044158] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2
[   47.044281] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3
[   47.044403] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 4
[   47.044525] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5
[   47.044647] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 6
[   47.044799] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 7
[   47.044921] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 8
......

Anand, could you help to check it?

thanks,
-- 
Lei Ming

[-- Attachment #2: fix_ehci_gpio_beagle_xm.patch --]
[-- Type: text/x-patch, Size: 777 bytes --]

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index f1a8ede..3e130ae 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -299,7 +299,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
 
 	/* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
 	gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
-	gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+	if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+		gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+	else
+		gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
 
 	/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
 	gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-- 
1.7.3

Re: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

On 1/6/2011 9:20 PM, Ming Lei wrote:
> Hi,
> 
> 2011/1/6 Ming Lei <tom.leiming@gmail.com>:
>> Hi,
>>
>> 2011/1/6 Anand Gadiyar <gadiyar@ti.com>:
>>
>>> I'll take a look in a short while. I don't have an XM to
>>> test, so you'll have to help me out here.
>>
>> No problem for me, :-)
> 
> I see why the beagle xM does not work, the attachment patch is
> needed to make it working.
> 
> But the ehci on panda(omap4430) still does not work with
> 2.6.37-next-20110106+, and follows the failure messages:
> 
> [   46.572601] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [   46.580017] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
> [   46.580078] bus: 'platform': add driver ehci-omap
> [   46.580139] bus: 'platform': driver_probe_device: matched device ehci-omap.0 with driver ehci-omap
> [   46.580169] bus: 'platform': really_probe: probing driver ehci-omap with device ehci-omap.0
> [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
> [   46.580200] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
> [   46.580291] ehci-omap ehci-omap.0: OMAP UHH_REVISION 0x50700100
> [   46.580352] ehci-omap ehci-omap.0: TLL RESET DONE
> [   46.580352] ehci-omap ehci-omap.0: UHH setup done, uhh_hostconfig=1c
> [   46.580383] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3
> [   46.580383] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1 uframes 256/512/1024 park LPM
> [   46.580383] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [   46.588592] drivers/usb/core/inode.c: creating file 'devices'
> [   46.588623] drivers/usb/core/inode.c: creating file '001'
> [   46.588684] device: 'usbmon1': device_add
> [   46.588867] PM: Adding info for No Bus:usbmon1
> [   46.590026] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
> [   46.645721] ehci-omap ehci-omap.0: park 0
> [   46.645721] ehci-omap ehci-omap.0: support lpm
> [   46.645751] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00
> [   46.651763] ehci-omap ehci-omap.0: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
> [   46.651763] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [   46.661254] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> [   46.667297] usb usb1: rpm_resume flags 0x0
> [   46.667297] usb usb1: rpm_resume returns 1
> [   46.667358] usb usb1: default language 0x0409
> [   46.667358] usb usb1: udev 1, busnum 1, minor = 0
> [   46.667388] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [   46.675476] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [   46.683288] usb usb1: Product: OMAP-EHCI Host Controller
> [   46.689086] usb usb1: Manufacturer: Linux 2.6.37-next-20110106+ ehci_hcd
> [   46.696350] usb usb1: SerialNumber: ehci-omap.0
> [   46.701354] device: 'usb1': device_add
> [   46.701568] bus: 'usb': add device usb1
> [   46.701629] PM: Adding info for usb:usb1
> [   46.702758] bus: 'usb': driver_probe_device: matched device usb1 with driver usb
> [   46.702758] bus: 'usb': really_probe: probing driver usb with device usb1
> [   46.702819] usb usb1: usb_probe_device
> [   46.702819] usb usb1: configuration #1 chosen from 1 choice
> [   46.702850] usb usb1: rpm_resume flags 0x4
> [   46.702850] usb usb1: rpm_resume returns 1
> [   46.702911] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [   46.702911] device: '1-0:1.0': device_add
> [   46.702941] bus: 'usb': add device 1-0:1.0
> [   46.703002] PM: Adding info for usb:1-0:1.0
> [   46.703430] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with driver hub
> [   46.703460] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0
> [   46.703460] hub 1-0:1.0: usb_probe_interface
> [   46.703491] hub 1-0:1.0: usb_probe_interface - got id
> [   46.703491] usb usb1: rpm_resume flags 0x4
> [   46.703491] usb usb1: rpm_resume returns 1
> [   46.703521] hub 1-0:1.0: USB hub found
> [   46.707427] hub 1-0:1.0: 3 ports detected
> [   46.715698] hub 1-0:1.0: standalone hub
> [   46.715698] hub 1-0:1.0: individual port power switching
> [   46.715728] hub 1-0:1.0: individual port over-current protection
> [   46.715728] hub 1-0:1.0: power on to power good time: 20ms
> [   46.715759] hub 1-0:1.0: local power source is good
> [   46.715759] hub 1-0:1.0: enabling power on all ports
> [   46.715820] driver: '1-0:1.0': driver_bound: bound to device 'hub'
> [   46.715820] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
> [   46.715850] device: 'ep_81': device_add
> [   46.717468] PM: Adding info for No Bus:ep_81
> [   46.717498] device: 'usbdev1.1': device_add
> [   46.717590] PM: Adding info for No Bus:usbdev1.1
> [   46.717773] drivers/usb/core/inode.c: creating file '001'
> [   46.717803] driver: 'usb1': driver_bound: bound to device 'usb'
> [   46.717803] bus: 'usb': really_probe: bound device usb1 to driver usb
> [   46.717834] device: 'ep_00': device_add
> [   46.717895] PM: Adding info for No Bus:ep_00
> [   46.717895] usb usb1: rpm_suspend flags 0xc
> [   46.717926] usb usb1: rpm_suspend returns -16
> [   46.717926] ehci-omap ehci-omap.0: ...powerup ports...
> [   46.747161] driver: 'ehci-omap.0': driver_bound: bound to device 'ehci-omap'
> [   46.747192] bus: 'platform': really_probe: bound device ehci-omap.0 to driver ehci-omap
> [   46.809661] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT
> [   46.809692] hub 1-0:1.0: port 1: status 0501 change 0001
> [   46.911193] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 0000
> [   46.911193] hub 1-0:1.0: rpm_resume flags 0x4
> [   46.911193] hub 1-0:1.0: rpm_resume returns 1
> [   46.911224] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
> [   46.973907] ehci-omap ehci-omap.0: port 1 high speed
> [   46.973907] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
> [   47.036102] usb 1-1: new high speed USB device using ehci-omap and address 2
> [   47.044036] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 1
> [   47.044158] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 2
> [   47.044281] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 3
> [   47.044403] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 4
> [   47.044525] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 5
> [   47.044647] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 6
> [   47.044799] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 7
> [   47.044921] ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 8
> ......
> 
> Anand, could you help to check it?
> 

Hi Ming Lei,

I'm able to reproduce this on my panda, and I have it working as of
linux-next-20101221 (the last version I tested last year) and failing
on linux-next-20101227 (which was the very next linux-next release).

Not sure why, but my Panda manages to get the VID:PID of the hub as
well, while yours does not even get there.

I may need a few more hours to debug this, unless someone beats me
to it. ;)

- Anand

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

Hi Anand,

2011/1/7 Anand Gadiyar <gadiyar@ti.com>:
> Hi Ming Lei,
>
> I'm able to reproduce this on my panda, and I have it working as of
> linux-next-20101221 (the last version I tested last year) and failing
> on linux-next-20101227 (which was the very next linux-next release).
>
> Not sure why, but my Panda manages to get the VID:PID of the hub as
> well, while yours does not even get there.
>
> I may need a few more hours to debug this, unless someone beats me
> to it. ;)

Is it caused by the below?

[   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator

thanks,
-- 
Lei Ming

RE: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

Ming Lei wrote:
> 2011/1/7 Anand Gadiyar <gadiyar@ti.com>:
> > Hi Ming Lei,
> >
> > I'm able to reproduce this on my panda, and I have it working as of
> > linux-next-20101221 (the last version I tested last year) and failing
> > on linux-next-20101227 (which was the very next linux-next release).
> >
> > Not sure why, but my Panda manages to get the VID:PID of the hub as
> > well, while yours does not even get there.
> >
> > I may need a few more hours to debug this, unless someone beats me
> > to it. ;)
>
> Is it caused by the below?
>
> [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
>

Nope. We don't set up any regulators for the PHY on Panda (at least not
yet).

And the working case (next-20101221) has the same log.

I suspect the PHY doesn't get reset for the proper duration; I'm looking
for something in that area. (Another option is to bisect between the two
versions, but I'm not sure if that's any easier).

- Anand

RE: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

Ming Lei wrote:
> Ming Lei wrote:
> > 2011/1/7 Anand Gadiyar <gadiyar@ti.com>:
> > > Hi Ming Lei,
> > >
> > > I'm able to reproduce this on my panda, and I have it working as of
> > > linux-next-20101221 (the last version I tested last year) and
failing
> > > on linux-next-20101227 (which was the very next linux-next release).
> > >
> > > Not sure why, but my Panda manages to get the VID:PID of the hub as
> > > well, while yours does not even get there.
> > >
> > > I may need a few more hours to debug this, unless someone beats me
> > > to it. ;)
> >
> > Is it caused by the below?
> >
> > [   46.580200] ehci-omap ehci-omap.0: failed to get ehci port0
regulator
> >
>
> Nope. We don't set up any regulators for the PHY on Panda (at least not
> yet).
>
> And the working case (next-20101221) has the same log.
>
> I suspect the PHY doesn't get reset for the proper duration; I'm looking
> for something in that area. (Another option is to bisect between the two
> versions, but I'm not sure if that's any easier).
>

Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
connected devices enumerate just fine. Could you try this out on
your board as well?

I'll look deeper and see if there are some required clocks that are
accidentally getting turned off.

- Anand

Re: linux-next: manual merge of the usb tree with the omap tree

[Gadiyar, Anand]

On Fri, Jan 7, 2011 at 8:50 PM, Anand Gadiyar <gadiyar@ti.com> wrote:
> Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
> connected devices enumerate just fine. Could you try this out on
> your board as well?
>
> I'll look deeper and see if there are some required clocks that are
> accidentally getting turned off.
>

A final update from today: It appears that disabling auxclk3_ck causes
EHCI to fail. I'm not sure what this clock feeds, and will need to look it
up. Keeping this clock alive is sufficient to get the hub to enumerate.

I would've looked it up, but got booted out by a fire alarm drill. I'll
take a look tomorrow and cook up a fix.

- Anand

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

On Sat, Jan 08, 2011 at 12:24:24AM +0530, Gadiyar, Anand wrote:
> On Fri, Jan 7, 2011 at 8:50 PM, Anand Gadiyar <gadiyar@ti.com> wrote:
> > Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
> > connected devices enumerate just fine. Could you try this out on
> > your board as well?
> >
> > I'll look deeper and see if there are some required clocks that are
> > accidentally getting turned off.
> >
> 
> A final update from today: It appears that disabling auxclk3_ck causes
> EHCI to fail. I'm not sure what this clock feeds, and will need to look it
> up. Keeping this clock alive is sufficient to get the hub to enumerate.
> 
> I would've looked it up, but got booted out by a fire alarm drill. I'll
> take a look tomorrow and cook up a fix.

Good finding :-) Thanks a lot :-)

-- 
balbi

Re: linux-next: manual merge of the usb tree with the omap tree

[Ming Lei]

Hi,

2011/1/7 Anand Gadiyar <gadiyar@ti.com>:

> Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
> connected devices enumerate just fine. Could you try this out on
> your board as well?

Yes, it does work for me if CONFIG_OMAP_RESET_CLOCKS is disabled.

thanks,
-- 
Lei Ming

Re: linux-next: manual merge of the usb tree with the omap tree

[Anand Gadiyar]

On 1/10/2011 7:23 PM, Ming Lei wrote:
> Hi,
> 
> 2011/1/7 Anand Gadiyar <gadiyar@ti.com>:
> 
>> Update: I disabled CONFIG_OMAP_RESET_CLOCKS and the PHY and other
>> connected devices enumerate just fine. Could you try this out on
>> your board as well?
> 
> Yes, it does work for me if CONFIG_OMAP_RESET_CLOCKS is disabled.
> 
> thanks,

Great, patch coming up in a few minutes.

I figured out why we need auxclk3 - the PHY's reference clock
is provided by it.

- Anand

Re: linux-next: manual merge of the usb tree with the omap tree

[Brad Parker]

It's probably expected, but I can't get the EHCI USB port  to work
on a beagle board XM (36xx) using the current omap tree.

It this most likely due to these clock issues?

the (very old) angstrom 2.6.32 kernel works fine, as a comparison.

-brad

Re: linux-next: manual merge of the usb tree with the omap tree

[Koen Kooi]

Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:

> It's probably expected, but I can't get the EHCI USB port  to work
> on a beagle board XM (36xx) using the current omap tree.
> 
> It this most likely due to these clock issues?

You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/

I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.

Re: linux-next: manual merge of the usb tree with the omap tree

[Nishanth Menon]

Koen Kooi had written, on 01/06/2011 10:59 AM, the following:
> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
> 
>> It's probably expected, but I can't get the EHCI USB port  to work
>> on a beagle board XM (36xx) using the current omap tree.
>>
>> It this most likely due to these clock issues?
> 
> You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> 
> I'm currently too lazy to split it up like Nishant wants as I don't see the point splitting for the sake of splitting.--
Alrite, if it is ok with you and Tony, I will help post the split up - 
this will help multiple things:
a) prevents the patch being held off because of multiline comments and 
the link
b) git bisect can isolate to a specific change.
c) A patch should do a single logical thing for helping (b).

-- 
Regards,
Nishanth Menon

Re: linux-next: manual merge of the usb tree with the omap tree

[Kevin Hilman]

Koen Kooi <koen@dominion.thruhere.net> writes:

> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
>
>> It's probably expected, but I can't get the EHCI USB port  to work
>> on a beagle board XM (36xx) using the current omap tree.
>> 
>> It this most likely due to these clock issues?
>
> You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
>
> I'm currently too lazy to split it up like Nishant wants as I don't
> see the point splitting for the sake of splitting.--

IMO, it doesn't need to be split up.

But it does have to fix the other comments I made on the same thread[1]

1) add a descriptive changelog, and
2) Cc linux-arm-kernel

Kevin

[1] http://article.gmane.org/gmane.linux.ports.arm.omap/48920

Re: linux-next: manual merge of the usb tree with the omap tree

[Nishanth Menon]

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

Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
> Koen Kooi <koen@dominion.thruhere.net> writes:
> 
>> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
>>
>>> It's probably expected, but I can't get the EHCI USB port  to work
>>> on a beagle board XM (36xx) using the current omap tree.
>>>
>>> It this most likely due to these clock issues?
>> You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
>>
>> I'm currently too lazy to split it up like Nishant wants as I don't
>> see the point splitting for the sake of splitting.--
> 
> IMO, it doesn't need to be split up.
> 
> But it does have to fix the other comments I made on the same thread[1]
> 
> 1) add a descriptive changelog, and
> 2) Cc linux-arm-kernel

Kevin,
there are four things being done in the patch:
a) fix GPIO number for EHCI power on
b) fix GPIO number for DVI reset line
c) switch on DVI
d) switch on Camera

I have split the first 2 up. I just splitting the (c) up when I noticed 
the code is confusing - I will reply in thread to the original patch.

I apologize, but I disagree - as far as I see it, these are separate 
changes being done.

-- 
Regards,
Nishanth Menon

[-- Attachment #2: 0001-omap3-beaglexm-fix-EHCI-power-up-GPIO-dir.patch --]
[-- Type: text/x-patch, Size: 1541 bytes --]

>From c03fd107da409806ec15d508db6c7c352244a1f4 Mon Sep 17 00:00:00 2001
From: Koen Kooi <koen@beagleboard.org>
Date: Thu, 6 Jan 2011 12:08:15 -0600
Subject: [PATCH 1/2] omap3: beaglexm: fix EHCI power up GPIO dir

EHCI enable power pin is inverted (active high) in comparison
to vanilla beagle which is active low. Handle this case conditionally.

[nm@ti.com: helped split up]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..1b5aa7a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
 	gpio_request(gpio + 1, "EHCI_nOC");
 	gpio_direction_input(gpio + 1);
 
-	/* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+	/*
+	 * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+	 * high / others active low)
+	 */
 	gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
 	gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+	if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+		gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+	else
+		gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
 
 	/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
 	gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-- 
1.6.3.3


[-- Attachment #3: 0002-omap3-beaglexm-fix-DVI-reset-GPIO.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]

>From d34971b71d61f3fc20e724a48dbdfe347aa53802 Mon Sep 17 00:00:00 2001
From: Koen Kooi <koen@beagleboard.org>
Date: Thu, 6 Jan 2011 12:14:00 -0600
Subject: [PATCH 2/2] omap3: beaglexm: fix DVI reset GPIO

GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 1b5aa7a..d628f5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
 	.name = "dvi",
 	.driver_name = "generic_panel",
 	.phy.dpi.data_lines = 24,
-	.reset_gpio = 170,
+	.reset_gpio = -EINVAL,
 	.platform_enable = beagle_enable_dvi,
 	.platform_disable = beagle_disable_dvi,
 };
@@ -308,6 +308,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
 	else
 		gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
 
+	/* DVI reset GPIO is different between beagle revisions */
+	if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+		beagle_dvi_device.reset_gpio = 129;
+	else
+		beagle_dvi_device.reset_gpio = 170;
+
 	/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
 	gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
 
-- 
1.6.3.3

Re: linux-next: manual merge of the usb tree with the omap tree

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
>> Koen Kooi <koen@dominion.thruhere.net> writes:
>>
>>> Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
>>>
>>>> It's probably expected, but I can't get the EHCI USB port  to work
>>>> on a beagle board XM (36xx) using the current omap tree.
>>>>
>>>> It this most likely due to these clock issues?
>>> You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
>>>
>>> I'm currently too lazy to split it up like Nishant wants as I don't
>>> see the point splitting for the sake of splitting.--
>>
>> IMO, it doesn't need to be split up.
>>
>> But it does have to fix the other comments I made on the same thread[1]
>>
>> 1) add a descriptive changelog, and
>> 2) Cc linux-arm-kernel
>
> Kevin,
> there are four things being done in the patch:
> a) fix GPIO number for EHCI power on
> b) fix GPIO number for DVI reset line
> c) switch on DVI
> d) switch on Camera
>
> I have split the first 2 up. I just splitting the (c) up when I
> noticed the code is confusing - I will reply in thread to the original
> patch.
>
> I apologize, but I disagree - as far as I see it, these are separate
> changes being done.

Sure, but there are all tiny and isolated.  For me, what's missing is
just a changlog describing all the changes.

Feel free to break it up if you prefer, but IMO it would be mergable as
a single patch if there was a descriptive changelog actually mentioning 
all the changes made (as you just did above.)

Kevin

Re: linux-next: manual merge of the usb tree with the omap tree

[Nishanth Menon]

Kevin Hilman had written, on 01/06/2011 12:38 PM, the following:
[..]
> Feel free to break it up if you prefer, but IMO it would be mergable as
just for the record, posted the same here:
http://marc.info/?l=linux-omap&m=129434370207879&w=2

[..]

-- 
Regards,
Nishanth Menon

Re: linux-next: manual merge of the usb tree with the omap tree

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Kevin Hilman had written, on 01/06/2011 12:38 PM, the following:
> [..]
>> Feel free to break it up if you prefer, but IMO it would be mergable as
> just for the record, posted the same here:
> http://marc.info/?l=linux-omap&m=129434370207879&w=2

Thanks, and this is even more mergable. :)

Kevin

Re: linux-next: manual merge of the usb tree with the omap tree

[Paul Walmsley]

On Thu, 6 Jan 2011, Kevin Hilman wrote:

> Koen Kooi <koen@dominion.thruhere.net> writes:
> 
> > Op 6 jan 2011, om 16:43 heeft Brad Parker het volgende geschreven:
> >
> >> It's probably expected, but I can't get the EHCI USB port  to work
> >> on a beagle board XM (36xx) using the current omap tree.
> >> 
> >> It this most likely due to these clock issues?
> >
> > You need this patch: http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> >
> > I'm currently too lazy to split it up like Nishant wants as I don't
> > see the point splitting for the sake of splitting.--
> 
> IMO, it doesn't need to be split up.
> 
> But it does have to fix the other comments I made on the same thread[1]
> 
> 1) add a descriptive changelog, and
> 2) Cc linux-arm-kernel

and glancing at the patch

3) Fix the multiline comments to conform to Documentation/CodingStyle

as I think Nishanth mentioned.


- Paul

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-omap2/usb-musb.c between commit
18a26892d62d2786c2b259ba4605ee10bba0ba13 ("OMAP2+: musb: hwmod adaptation
for musb registration") from the omap tree and commit
fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power
down the PHY during board init") from the usb tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.

Interestingly, the patch in the usb tree looks as though it would have
been broken as the "dev" variable passed to omap4430_phy_init() does not
exist in the version of that file in the usb tree.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/usb-musb.c
index a9d4d14,241fc94..0000000
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@@ -132,35 -212,12 +132,39 @@@ void __init usb_musb_init(struct omap_m
  	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);
+ 
+ 	if (cpu_is_omap44xx())
+ 		omap4430_phy_init(dev);
+ 
  }
  
  #else

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-omap2/clock3xxx_data.c between commit
0005ae73cfe44ee42d0be12a12cc82bf982f518e ("OMAP: hsmmc: Rename the device
and driver") from the omap tree and commit
53689ac1b677532be666a779e24b0ac9bd266354 ("arm: omap: usb: clock entries
for omap3 and omap4") from the usb tree.

Just context changes.  I have fixed it up (see below) and can carry the
fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/mach-omap2/clock3xxx_data.c
index f43e7ec,fbb1e30..0000000
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@@ -3322,8 -3322,8 +3322,8 @@@ static struct omap_clk omap3xxx_clks[] 
  	CLK(NULL,	"pka_ick",	&pka_ick,	CK_34XX | CK_36XX),
  	CLK(NULL,	"core_l4_ick",	&core_l4_ick,	CK_3XXX),
  	CLK(NULL,	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
- 	CLK("ehci-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ 	CLK("usbhs-omap.0",	"usbtll_ick",	&usbtll_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 -	CLK("mmci-omap-hs.2",	"ick",	&mmchs3_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
 +	CLK("omap_hsmmc.2",	"ick",	&mmchs3_ick,	CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
  	CLK(NULL,	"icr_ick",	&icr_ick,	CK_34XX | CK_36XX),
  	CLK("omap-aes",	"ick",	&aes2_ick,	CK_34XX | CK_36XX),
  	CLK("omap-sham",	"ick",	&sha12_ick,	CK_34XX | CK_36XX),

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
arch/arm/mach-omap2/board-4430sdp.c between commit
1dbea0f5e23b6c647db72fa4a048cb7140625e13 ("arm: omap4: 4430sdp: drop ehci
support") from the omap tree and commit
181b250cf53233a7a7c6d7e1e9df402506712e93 ("arm: omap: usb: create common
enums and structures for ehci and ohci") from the usb tree.

The former removed the code modified by the latter, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

On Wed, Mar 02, 2011 at 04:57:55PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the usb tree got a conflict in
> arch/arm/mach-omap2/board-4430sdp.c between commit
> 1dbea0f5e23b6c647db72fa4a048cb7140625e13 ("arm: omap4: 4430sdp: drop ehci
> support") from the omap tree and commit
> 181b250cf53233a7a7c6d7e1e9df402506712e93 ("arm: omap: usb: create common
> enums and structures for ehci and ohci") from the usb tree.
> 
> The former removed the code modified by the latter, so I did that.

This can be fixed if Greg applies this patch:

commit 076bfacd5bba0f2e419474488c8f8c060c7799d8
Author: Anand Gadiyar <gadiyar@ti.com>
Date:   Wed Feb 16 16:47:19 2011 +0530

    arm: omap4: 4430sdp: drop ehci support
    
    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>

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 1230121..f603f3b 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 usbhs_omap_board_data usbhs_bdata __initconst = {
-	.port_mode[0]	= OMAP_EHCI_PORT_MODE_PHY,
-	.port_mode[1]	= OMAP_USBHS_PORT_MODE_UNUSED,
-	.port_mode[2]	= OMAP_USBHS_PORT_MODE_UNUSED,
-	.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,
@@ -577,14 +566,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);
-
-	usbhs_init(&usbhs_bdata);
 	usb_musb_init(&musb_board_data);
 
 	status = omap_ethernet_init();

-- 
balbi

Re: linux-next: manual merge of the usb tree with the omap tree

[Greg KH]

On Thu, Mar 03, 2011 at 10:48:29AM +0200, Felipe Balbi wrote:
> On Wed, Mar 02, 2011 at 04:57:55PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the usb tree got a conflict in
> > arch/arm/mach-omap2/board-4430sdp.c between commit
> > 1dbea0f5e23b6c647db72fa4a048cb7140625e13 ("arm: omap4: 4430sdp: drop ehci
> > support") from the omap tree and commit
> > 181b250cf53233a7a7c6d7e1e9df402506712e93 ("arm: omap: usb: create common
> > enums and structures for ehci and ohci") from the usb tree.
> > 
> > The former removed the code modified by the latter, so I did that.
> 
> This can be fixed if Greg applies this patch:
> 
> commit 076bfacd5bba0f2e419474488c8f8c060c7799d8
> Author: Anand Gadiyar <gadiyar@ti.com>
> Date:   Wed Feb 16 16:47:19 2011 +0530

Care to provide it to me in a format that I can apply it?  :)

thanks,

greg k-h

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

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

On Thu, Mar 03, 2011 at 08:02:09AM -0800, Greg KH wrote:
> On Thu, Mar 03, 2011 at 10:48:29AM +0200, Felipe Balbi wrote:
> > On Wed, Mar 02, 2011 at 04:57:55PM +1100, Stephen Rothwell wrote:
> > > Hi Greg,
> > > 
> > > Today's linux-next merge of the usb tree got a conflict in
> > > arch/arm/mach-omap2/board-4430sdp.c between commit
> > > 1dbea0f5e23b6c647db72fa4a048cb7140625e13 ("arm: omap4: 4430sdp: drop ehci
> > > support") from the omap tree and commit
> > > 181b250cf53233a7a7c6d7e1e9df402506712e93 ("arm: omap: usb: create common
> > > enums and structures for ehci and ohci") from the usb tree.
> > > 
> > > The former removed the code modified by the latter, so I did that.
> > 
> > This can be fixed if Greg applies this patch:
> > 
> > commit 076bfacd5bba0f2e419474488c8f8c060c7799d8
> > Author: Anand Gadiyar <gadiyar@ti.com>
> > Date:   Wed Feb 16 16:47:19 2011 +0530
> 
> Care to provide it to me in a format that I can apply it?  :)

heh, my bad. It's attached.

-- 
balbi

[-- Attachment #2: 0001-arm-omap4-4430sdp-drop-ehci-support.diff --]
[-- Type: text/x-diff, Size: 2776 bytes --]

>From 076bfacd5bba0f2e419474488c8f8c060c7799d8 Mon Sep 17 00:00:00 2001
From: Anand Gadiyar <gadiyar@ti.com>
Date: Wed, 16 Feb 2011 16:47:19 +0530
Subject: [PATCH] arm: omap4: 4430sdp: drop ehci support
Organization: Texas Instruments\n

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 1230121..f603f3b 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 usbhs_omap_board_data usbhs_bdata __initconst = {
-	.port_mode[0]	= OMAP_EHCI_PORT_MODE_PHY,
-	.port_mode[1]	= OMAP_USBHS_PORT_MODE_UNUSED,
-	.port_mode[2]	= OMAP_USBHS_PORT_MODE_UNUSED,
-	.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,
@@ -577,14 +566,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);
-
-	usbhs_init(&usbhs_bdata);
 	usb_musb_init(&musb_board_data);
 
 	status = omap_ethernet_init();
-- 
1.7.4.rc2

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/musb/musb_core.h between commit
59b479e0985f0b795d68331d6443a7f89c47768d ("omap: Start using
CONFIG_SOC_OMAP") from the omap tree and commit
da68ccec210c45eb99e461ad31b499b4e7043c41 ("usb: musb: Remove platform
context save/restore API") from the usb tree.

The latter removed the code modified by the former, so I did that.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

On Wed, Mar 02, 2011 at 04:57:46PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/musb/musb_core.h between commit
> 59b479e0985f0b795d68331d6443a7f89c47768d ("omap: Start using
> CONFIG_SOC_OMAP") from the omap tree and commit
> da68ccec210c45eb99e461ad31b499b4e7043c41 ("usb: musb: Remove platform
> context save/restore API") from the usb tree.
> 
> The latter removed the code modified by the former, so I did that.

Yeah, I was about to send a resolution to Tony. Here's what I came up
with (too big though):

commit d12f1cd19b7e79087df1ea197ffe81b0b67f2bc3
Merge: abba63e 53689ac
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Mar 1 17:14:26 2011 +0200

    Merge branch 'for-next' into tst
    
    Conflicts:
    	arch/arm/mach-omap2/board-4430sdp.c
    	arch/arm/mach-omap2/board-omap3evm.c
    	arch/arm/mach-omap2/usb-musb.c
    	arch/arm/plat-omap/include/plat/usb.h
    	drivers/usb/musb/musb_core.h
    
    Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --cc arch/arm/mach-omap2/board-3430sdp.c
index 8950ecc,7542ba5..d7aa25f
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@@ -801,10 -813,10 +801,10 @@@ static void __init omap_3430sdp_init(vo
  	omap_serial_init();
  	usb_musb_init(&musb_board_data);
  	board_smc91x_init();
 -	board_flash_init(sdp_flash_partitions, chip_sel_3430);
 +	board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
  	sdp3430_display_init();
  	enable_board_wakeup_source();
- 	usb_ehci_init(&ehci_pdata);
+ 	usbhs_init(&usbhs_bdata);
  }
  
  MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
diff --cc arch/arm/mach-omap2/board-3630sdp.c
index 8d1c435,deed2db..d474697
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@@ -209,9 -209,9 +209,9 @@@ static void __init omap_sdp_init(void
  	zoom_peripherals_init();
  	zoom_display_init();
  	board_smc91x_init();
 -	board_flash_init(sdp_flash_partitions, chip_sel_sdp);
 +	board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
  	enable_board_wakeup_source();
- 	usb_ehci_init(&ehci_pdata);
+ 	usbhs_init(&usbhs_bdata);
  }
  
  MACHINE_START(OMAP_3630SDP, "OMAP 3630SDP board")
diff --cc arch/arm/mach-omap2/board-am3517crane.c
index ae3a83d,e3a194f..36bff55
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@@ -56,12 -56,13 +56,12 @@@ static void __init am3517_crane_init_ea
  
  	omap2_init_common_infrastructure();
  	omap2_init_common_devices(NULL, NULL);
 -	omap_init_irq();
  }
  
- static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
- 	.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
- 	.port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- 	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
+ 	.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ 	.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
+ 	.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
  
  	.phy_reset  = true,
  	.reset_gpio_port[0]  = GPIO_USB_NRESET,
diff --cc arch/arm/mach-omap2/board-igep0020.c
index 54e6318,f9f5344..0d3b0ad
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@@ -685,10 -697,9 +685,10 @@@ static void __init igep2_init(void
  	/* Register I2C busses and drivers */
  	igep2_i2c_init();
  	platform_add_devices(igep2_devices, ARRAY_SIZE(igep2_devices));
 +	omap_display_init(&igep2_dss_data);
  	omap_serial_init();
  	usb_musb_init(&musb_board_data);
- 	usb_ehci_init(&ehci_pdata);
+ 	usbhs_init(&usbhs_bdata);
  
  	igep2_flash_init();
  	igep2_leds_init();
diff --cc arch/arm/mach-omap2/board-omap3evm.c
index 7341f96,38a2d91..e307fa4
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@@ -733,13 -631,18 +733,13 @@@ static void __init omap3_evm_init_early
  	omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
  	omap2_init_common_infrastructure();
  	omap2_init_common_devices(mt46h32m32lf6_sdrc_params, NULL);
 -	omap_init_irq();
  }
  
- static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
 -static struct platform_device *omap3_evm_devices[] __initdata = {
 -	&omap3_evm_dss_device,
 -};
 -
+ static struct usbhs_omap_board_data usbhs_bdata __initdata = {
  
- 	.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
- 	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
- 	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ 	.port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
+ 	.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
+ 	.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
  
  	.phy_reset  = true,
  	/* PHY reset GPIO will be runtime programmed based on EVM version */
diff --cc arch/arm/mach-omap2/board-omap4panda.c
index 3dd241b,ed61c1f..a7d89da
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@@ -84,12 -80,13 +84,12 @@@ static void __init omap4_panda_init_ear
  {
  	omap2_init_common_infrastructure();
  	omap2_init_common_devices(NULL, NULL);
 -	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,
+ static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
+ 	.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
+ 	.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
+ 	.port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
  	.phy_reset  = false,
  	.reset_gpio_port[0]  = -EINVAL,
  	.reset_gpio_port[1]  = -EINVAL,
diff --cc arch/arm/mach-omap2/board-zoom.c
index 7e3f159,1dd195a..15c8806
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@@ -122,11 -123,11 +122,11 @@@ static void __init omap_zoom_init(void
  	} else if (machine_is_omap_zoom3()) {
  		omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
  		omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
- 		usb_ehci_init(&ehci_pdata);
+ 		usbhs_init(&usbhs_bdata);
  	}
  
 -	board_nand_init(zoom_nand_partitions,
 -			ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS);
 +	board_nand_init(zoom_nand_partitions, ARRAY_SIZE(zoom_nand_partitions),
 +						ZOOM_NAND_CS, NAND_BUSWIDTH_16);
  	zoom_debugboard_init();
  	zoom_peripherals_init();
  	zoom_display_init();
diff --cc arch/arm/mach-omap2/usb-musb.c
index a9d4d14,241fc94..77071a6
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@@ -132,35 -212,12 +132,38 @@@ void __init usb_musb_init(struct omap_m
  	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";
 +	}
  
+ 	if (cpu_is_omap44xx())
+ 		omap4430_phy_init(dev);
+ 
 +	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
diff --cc arch/arm/plat-omap/include/plat/usb.h
index 0771927,fe449f1..e4f61c8
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@@ -88,14 -107,9 +107,13 @@@ extern int omap4430_phy_power(struct de
  extern int omap4430_phy_set_clk(struct device *dev, int on);
  extern int omap4430_phy_init(struct device *dev);
  extern int omap4430_phy_exit(struct device *dev);
- 
+ extern int omap4430_phy_suspend(struct device *dev, int suspend);
  #endif
  
 +extern void am35x_musb_reset(void);
 +extern void am35x_musb_phy_power(u8 on);
 +extern void am35x_musb_clear_irq(void);
 +extern void am35x_musb_set_mode(u8 musb_mode);
- 
  /*
   * FIXME correct answer depends on hmc_mode,
   * as does (on omap1) any nonzero value for config->otg port number

-- 
balbi

Re: linux-next: manual merge of the usb tree with the omap tree

[Greg KH]

On Wed, Mar 02, 2011 at 04:57:46PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/musb/musb_core.h between commit
> 59b479e0985f0b795d68331d6443a7f89c47768d ("omap: Start using
> CONFIG_SOC_OMAP") from the omap tree and commit
> da68ccec210c45eb99e461ad31b499b4e7043c41 ("usb: musb: Remove platform
> context save/restore API") from the usb tree.
> 
> The latter removed the code modified by the former, so I did that.

Thanks.  I'll let Felipe handle all of these omap merge issues, as I
thought the reason I was going to take these patches from him was to
prevent issues like this from happening :)

greg k-h

Re: linux-next: manual merge of the usb tree with the omap tree

[Felipe Balbi]

On Wed, Mar 02, 2011 at 09:23:22AM -0500, Greg KH wrote:
> On Wed, Mar 02, 2011 at 04:57:46PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the usb tree got a conflict in
> > drivers/usb/musb/musb_core.h between commit
> > 59b479e0985f0b795d68331d6443a7f89c47768d ("omap: Start using
> > CONFIG_SOC_OMAP") from the omap tree and commit
> > da68ccec210c45eb99e461ad31b499b4e7043c41 ("usb: musb: Remove platform
> > context save/restore API") from the usb tree.
> > 
> > The latter removed the code modified by the former, so I did that.
> 
> Thanks.  I'll let Felipe handle all of these omap merge issues, as I
> thought the reason I was going to take these patches from him was to
> prevent issues like this from happening :)

Fixing, will send patches to Tony to avoid the conflict.

-- 
balbi

linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/ehci-omap.c between commit
7cb07f72711d3e10763ca7d7a9fcd7ac788aabf4 ("omap: ehci: Add platform init
code") from the omap tree and commit
9e92239693d7010d2e710a445f46d6a738b09171 ("USB: host: ehci: introduce
omap ehci-hcd driver") from the usb tree.

Both commits create this file but I used the omap tree version because
commit ce491cf85466c3377228c5a852ea627ec5136956 ("omap: headers: Move
remaining headers from include/mach to include/plat") from the omap tree
moved one included header file (mach/usb.h -> plat/usb.h).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the usb tree with the omap tree

[Tony Lindgren]

* Stephen Rothwell <sfr@canb.auug.org.au> [091111 00:29]:
> Hi Greg,
> 
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/host/ehci-omap.c between commit
> 7cb07f72711d3e10763ca7d7a9fcd7ac788aabf4 ("omap: ehci: Add platform init
> code") from the omap tree and commit
> 9e92239693d7010d2e710a445f46d6a738b09171 ("USB: host: ehci: introduce
> omap ehci-hcd driver") from the usb tree.
> 
> Both commits create this file but I used the omap tree version because
> commit ce491cf85466c3377228c5a852ea627ec5136956 ("omap: headers: Move
> remaining headers from include/mach to include/plat") from the omap tree
> moved one included header file (mach/usb.h -> plat/usb.h).

Oops, sorry. Looks like I accidentally included also drivers/usb/host/ehci-omap.c
as we were testing it in the linux-omap tree.

I'll drop the drivers/usb/host/ehci-omap.c part from my queue, it should get
integrated via Greg's queue. I'll just merge the platform init code.

Regards,

Tony

Re: linux-next: manual merge of the usb tree with the omap tree

[Tony Lindgren]

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

* Tony Lindgren <tony@atomide.com> [091111 11:12]:
> * Stephen Rothwell <sfr@canb.auug.org.au> [091111 00:29]:
> > Hi Greg,
> > 
> > Today's linux-next merge of the usb tree got a conflict in
> > drivers/usb/host/ehci-omap.c between commit
> > 7cb07f72711d3e10763ca7d7a9fcd7ac788aabf4 ("omap: ehci: Add platform init
> > code") from the omap tree and commit
> > 9e92239693d7010d2e710a445f46d6a738b09171 ("USB: host: ehci: introduce
> > omap ehci-hcd driver") from the usb tree.
> > 
> > Both commits create this file but I used the omap tree version because
> > commit ce491cf85466c3377228c5a852ea627ec5136956 ("omap: headers: Move
> > remaining headers from include/mach to include/plat") from the omap tree
> > moved one included header file (mach/usb.h -> plat/usb.h).
> 
> Oops, sorry. Looks like I accidentally included also drivers/usb/host/ehci-omap.c
> as we were testing it in the linux-omap tree.
> 
> I'll drop the drivers/usb/host/ehci-omap.c part from my queue, it should get
> integrated via Greg's queue. I'll just merge the platform init code.

Dropped anything touching drivers/usb from my patch. So no need for Greg
to do anything, the updated version of the patch below for reference.

Regards,

Tony

[-- Attachment #2: ehci-platform-init.patch --]
[-- Type: text/x-diff, Size: 8518 bytes --]

>From 83f75a0c0eca8cdfc41d9a136c57c65e8fd546af Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi@nokia.com>
Date: Tue, 10 Nov 2009 18:24:39 -0800
Subject: [PATCH] omap: Add platform init code for EHCI driver

Add platform init code for EHCI driver.

Various fixes to the original patch by Ajay Kumar Gupta <ajay.gupta@ti.com>
and Anand Gadiyar <gadiyar@ti.com>.

Overo support added by Olof Johansson <olof@lixom.net>
Beagle support added by Koen Kooi <koen@beagleboard.org>
CM-T32 support added by Mike Rapoport <mike@compulab.co.il>

Signed-off-by: Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7468505..03cb4fc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_MACH_OMAP_4430SDP)		+= board-4430sdp.o
 # Platform specific device init code
 obj-y					+= usb-musb.o
 obj-$(CONFIG_MACH_OMAP2_TUSB6010)	+= usb-tusb6010.o
+obj-y					+= usb-ehci.o
 
 onenand-$(CONFIG_MTD_ONENAND_OMAP2)	:= gpmc-onenand.o
 obj-y					+= $(onenand-m) $(onenand-y)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index a2abac9..a3c1271 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -484,6 +484,18 @@ static void enable_board_wakeup_source(void)
 	omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
 }
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset  = true,
+	.reset_gpio_port[0]  = 57,
+	.reset_gpio_port[1]  = 61,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
 static void __init omap_3430sdp_init(void)
 {
 	omap3430_i2c_init();
@@ -500,6 +512,7 @@ static void __init omap_3430sdp_init(void)
 	usb_musb_init();
 	board_smc91x_init();
 	enable_board_wakeup_source();
+	usb_ehci_init(&ehci_pdata);
 }
 
 static void __init omap_3430sdp_map_io(void)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index e7a29e4..0a39513 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -352,6 +352,17 @@ static struct twl4030_hsmmc_info mmc[] = {
 	{}	/* Terminator */
 };
 
+static struct ehci_hcd_omap_platform_data ehci_pdata = {
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset  = true,
+	.reset_gpio_port[0]  = -EINVAL,
+	.reset_gpio_port[1]  = -EINVAL,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
 static int cm_t35_twl_gpio_setup(struct device *dev, unsigned gpio,
 				 unsigned ngpio)
 {
@@ -377,6 +388,12 @@ static int cm_t35_twl_gpio_setup(struct device *dev, unsigned gpio,
 	cm_t35_vmmc1_supply.dev = mmc[0].dev;
 	cm_t35_vsim_supply.dev = mmc[0].dev;
 
+	/* setup USB with proper PHY reset GPIOs */
+	ehci_pdata.reset_gpio_port[0] = gpio + 6;
+	ehci_pdata.reset_gpio_port[1] = gpio + 7;
+
+	usb_ehci_init(&ehci_pdata);
+
 	return 0;
 }
 
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 71a3528..6cb99f6 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -400,6 +400,18 @@ static void __init omap3beagle_flash_init(void)
 	}
 }
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset  = true,
+	.reset_gpio_port[0]  = -EINVAL,
+	.reset_gpio_port[1]  = 147,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
 static void __init omap3_beagle_init(void)
 {
 	omap3_beagle_i2c_init();
@@ -413,6 +425,7 @@ static void __init omap3_beagle_init(void)
 	gpio_direction_output(170, true);
 
 	usb_musb_init();
+	usb_ehci_init(&ehci_pdata);
 	omap3beagle_flash_init();
 
 	/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 660ef8c..b9b0f4c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -343,6 +343,18 @@ static struct platform_device *omap3_evm_devices[] __initdata = {
 	&omap3evm_smc911x_device,
 };
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset  = true,
+	.reset_gpio_port[0]  = -EINVAL,
+	.reset_gpio_port[1]  = 135,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
 static void __init omap3_evm_init(void)
 {
 	omap3_evm_i2c_init();
@@ -358,6 +370,9 @@ static void __init omap3_evm_init(void)
 	usb_nop_xceiv_register();
 #endif
 	usb_musb_init();
+	/* Setup EHCI phy reset padconfig */
+	omap_cfg_reg(AF4_34XX_GPIO135_OUT);
+	usb_ehci_init(&ehci_pdata);
 	ads7846_dev_init();
 }
 
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 5a38494..581a18d 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -387,6 +387,18 @@ static struct platform_device *omap3pandora_devices[] __initdata = {
 	&pandora_keys_gpio,
 };
 
+static 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  = true,
+	.reset_gpio_port[0]  = 16,
+	.reset_gpio_port[1]  = -EINVAL,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
 static void __init omap3pandora_init(void)
 {
 	omap3pandora_i2c_init();
@@ -396,6 +408,7 @@ static void __init omap3pandora_init(void)
 	spi_register_board_info(omap3pandora_spi_board_info,
 			ARRAY_SIZE(omap3pandora_spi_board_info));
 	omap3pandora_ads7846_init();
+	usb_ehci_init(&ehci_pdata);
 	pandora_keys_gpio_init();
 	usb_musb_init();
 
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 461522c..92f3f3a 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -384,6 +384,18 @@ static struct platform_device *overo_devices[] __initdata = {
 	&overo_lcd_device,
 };
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset  = true,
+	.reset_gpio_port[0]  = -EINVAL,
+	.reset_gpio_port[1]  = OVERO_GPIO_USBH_NRESET,
+	.reset_gpio_port[2]  = -EINVAL
+};
+
+
 static void __init overo_init(void)
 {
 	overo_i2c_init();
@@ -391,6 +403,7 @@ static void __init overo_init(void)
 	omap_serial_init();
 	overo_flash_init();
 	usb_musb_init();
+	usb_ehci_init(&ehci_pdata);
 	overo_ads7846_init();
 	overo_init_smsc911x();
 
@@ -433,14 +446,6 @@ static void __init overo_init(void)
 	else
 		printk(KERN_ERR "could not obtain gpio for "
 					"OVERO_GPIO_USBH_CPEN\n");
-
-	if ((gpio_request(OVERO_GPIO_USBH_NRESET,
-			  "OVERO_GPIO_USBH_NRESET") == 0) &&
-	    (gpio_direction_output(OVERO_GPIO_USBH_NRESET, 1) == 0))
-		gpio_export(OVERO_GPIO_USBH_NRESET, 0);
-	else
-		printk(KERN_ERR "could not obtain gpio for "
-					"OVERO_GPIO_USBH_NRESET\n");
 }
 
 static void __init overo_map_io(void)
diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h
index f8d186a..4655707 100644
--- a/arch/arm/plat-omap/include/plat/omap34xx.h
+++ b/arch/arm/plat-omap/include/plat/omap34xx.h
@@ -74,8 +74,12 @@
 
 #define OMAP34XX_IVA_INTC_BASE	0x40000000
 #define OMAP34XX_HSUSB_OTG_BASE	(L4_34XX_BASE + 0xAB000)
-#define OMAP34XX_HSUSB_HOST_BASE	(L4_34XX_BASE + 0x64000)
 #define OMAP34XX_USBTLL_BASE	(L4_34XX_BASE + 0x62000)
+#define OMAP34XX_UHH_CONFIG_BASE	(L4_34XX_BASE + 0x64000)
+#define OMAP34XX_OHCI_BASE	(L4_34XX_BASE + 0x64400)
+#define OMAP34XX_EHCI_BASE	(L4_34XX_BASE + 0x64800)
+#define OMAP34XX_SR1_BASE	0x480C9000
+#define OMAP34XX_SR2_BASE	0x480CB000
 
 #define OMAP34XX_MAILBOX_BASE		(L4_34XX_BASE + 0x94000)
 

Re: linux-next: manual merge of the usb tree with the omap tree

[Stephen Rothwell]

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

Hi Tony,

On Wed, 11 Nov 2009 11:20:59 -0800 Tony Lindgren <tony@atomide.com> wrote:
>
> * Tony Lindgren <tony@atomide.com> [091111 11:12]:
> > 
> > Oops, sorry. Looks like I accidentally included also drivers/usb/host/ehci-omap.c
> > as we were testing it in the linux-omap tree.
> > 
> > I'll drop the drivers/usb/host/ehci-omap.c part from my queue, it should get
> > integrated via Greg's queue. I'll just merge the platform init code.
> 
> Dropped anything touching drivers/usb from my patch. So no need for Greg
> to do anything, the updated version of the patch below for reference.

OK, thanks.  Just as long as we don't forget the necessary updates when
these are all integrated into Linus' tree.  Some conflicts in linux-next
are not a bad thing for that reason.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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