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

2011-03-03 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-03-03 Thread 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 gadi...@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 gadi...@ti.com
Cc: Keshava Munegowda keshava_mgo...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Felipe Balbi ba...@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_ON48
 #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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-03-03 Thread 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 gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-03-03 Thread Felipe Balbi 
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 gadi...@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
From 076bfacd5bba0f2e419474488c8f8c060c7799d8 Mon Sep 17 00:00:00 2001
From: Anand Gadiyar gadi...@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 gadi...@ti.com
Cc: Keshava Munegowda keshava_mgo...@ti.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Felipe Balbi ba...@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

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

2011-03-02 Thread 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 ba...@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 ba...@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

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

2011-03-02 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-10 Thread Ming Lei 
Hi,

2011/1/7 Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-10 Thread Anand Gadiyar 
On 1/10/2011 7:23 PM, Ming Lei wrote:
 Hi,
 
 2011/1/7 Anand Gadiyar gadi...@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

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

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

2011-01-07 Thread Anand Gadiyar 
On 1/6/2011 9:20 PM, Ming Lei wrote:
 Hi,
 
 2011/1/6 Ming Lei tom.leim...@gmail.com:
 Hi,

 2011/1/6 Anand Gadiyar gadi...@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

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

2011-01-07 Thread Ming Lei 
Hi Anand,

2011/1/7 Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-07 Thread Anand Gadiyar 
Ming Lei wrote:
 2011/1/7 Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-07 Thread Anand Gadiyar 
Ming Lei wrote:
 Ming Lei wrote:
  2011/1/7 Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-07 Thread Gadiyar, Anand 
On Fri, Jan 7, 2011 at 8:50 PM, Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-07 Thread 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 gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Ming Lei 
Hi,

2010/12/24 Cousson, Benoit b-cous...@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..000
 --- 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,  

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

2011-01-06 Thread Anand Gadiyar 
Ming Lei wrote:

 Hi,

 2010/12/24 Cousson, Benoit b-cous...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Ming Lei 
Hi,

2011/1/6 Anand Gadiyar gadi...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread 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

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

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

2011-01-06 Thread 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.--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Kevin Hilman 
Koen Kooi k...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Nishanth Menon 

Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:

Koen Kooi k...@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
From c03fd107da409806ec15d508db6c7c352244a1f4 Mon Sep 17 00:00:00 2001
From: Koen Kooi k...@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.

[...@ti.com: helped split up]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Koen Kooi k...@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

From d34971b71d61f3fc20e724a48dbdfe347aa53802 Mon Sep 17 00:00:00 2001
From: Koen Kooi k...@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 n...@ti.com
Signed-off-by: Koen Kooi k...@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

2011-01-06 Thread Paul Walmsley 
On Thu, 6 Jan 2011, Kevin Hilman wrote:

 Koen Kooi k...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Kevin Hilman 
Nishanth Menon n...@ti.com writes:

 Kevin Hilman had written, on 01/06/2011 12:15 PM, the following:
 Koen Kooi k...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread 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-omapm=129434370207879w=2

[..]

--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2011-01-06 Thread Kevin Hilman 
Nishanth Menon n...@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-omapm=129434370207879w=2

Thanks, and this is even more mergable. :)

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2010-12-23 Thread 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..000
 --- 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:

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

2009-11-11 Thread Tony Lindgren 
* Stephen Rothwell s...@canb.auug.org.au [09 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2009-11-11 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [09 11:12]:
 * Stephen Rothwell s...@canb.auug.org.au [09 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
From 83f75a0c0eca8cdfc41d9a136c57c65e8fd546af Mon Sep 17 00:00:00 2001
From: Felipe Balbi felipe.ba...@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.gu...@ti.com
and Anand Gadiyar gadi...@ti.com.

Overo support added by Olof Johansson o...@lixom.net
Beagle support added by Koen Kooi k...@beagleboard.org
CM-T32 support added by Mike Rapoport m...@compulab.co.il

Signed-off-by: Signed-off-by: Olof Johansson o...@lixom.net
Acked-by: Steve Sakoman st...@sakoman.com
Signed-off-by: Koen Kooi k...@beagleboard.org
Signed-off-by: Mike Rapoport m...@compulab.co.il
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@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,
+

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

2009-11-11 Thread Stephen Rothwell 
Hi Tony,

On Wed, 11 Nov 2009 11:20:59 -0800 Tony Lindgren t...@atomide.com wrote:

 * Tony Lindgren t...@atomide.com [09 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 Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpttxZabKZBE.pgp
Description: PGP signature