The V2 patchset is based off the V1 patchset submitted below: http://patchwork.ozlabs.org/patch/257607/ http://patchwork.ozlabs.org/patch/257606/ http://patchwork.ozlabs.org/patch/257604/
There was a request to break the patches out into logical incremental patches which is what is done below.
All comments should have been addressed with v2 but I cannot give direct 1 to 1 history from V1 to V2 since the patchsets have been broken out.
Change the board name for the sys info to 5432 uEVM
Signed-off-by: Dan Murphy dmurphy@ti.com --- board/ti/omap5_uevm/evm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c index 90046e8..00bd72d 100644 --- a/board/ti/omap5_uevm/evm.c +++ b/board/ti/omap5_uevm/evm.c @@ -32,7 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = { - "Board: OMAP5430 EVM\n" + "Board: OMAP5432 uEVM\n" };
/**
On 07/10/2013 03:05 PM, Dan Murphy wrote:
Change the board name for the sys info to 5432 uEVM
Signed-off-by: Dan Murphy dmurphy@ti.com
board/ti/omap5_uevm/evm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c index 90046e8..00bd72d 100644 --- a/board/ti/omap5_uevm/evm.c +++ b/board/ti/omap5_uevm/evm.c @@ -32,7 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = {
- "Board: OMAP5430 EVM\n"
"Board: OMAP5432 uEVM\n" };
/**
Acked-by: Nishanth Menon nm@ti.com
Add an interface to the palmas driver to enable the LDO9 power supply for the USB hub IC.
Signed-off-by: Dan Murphy dmurphy@ti.com --- drivers/power/palmas.c | 34 ++++++++++++++++++++++++++++++++++ include/palmas.h | 1 + 2 files changed, 35 insertions(+)
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c index 2d275a7..b800dd4 100644 --- a/drivers/power/palmas.c +++ b/drivers/power/palmas.c @@ -143,6 +143,40 @@ int twl603x_audio_power(u8 on) } #endif
+#ifdef CONFIG_PALMAS_USBPWR +int palmas_usb_poweron_ldo(void) +{ + u8 val = 0; + int err; + + /* TURN ON LDO's needed */ + val = RSC_STAT_ON | RSC_MODE_SLEEP | RSC_MODE_ACTIVE; + err = palmas_i2c_write_u8(TWL603X_CHIP_P1, SYSEN2_CTRL, val); + if (err) { + printf("palmas: could not turn 3v3 %s: err = %d\n", + val ? "on" : "off", err); + return err; + } + + /* set to 3.3V */ + val = LDO9_BYPASS; + err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDOUSB_VOLTAGE, val); + if (err) { + printf("palmas: could not set 3v3 %s: err = %d\n", + val ? "on" : "off", err); + return err; + } + + /* enable LDO USB */ + err = palmas_i2c_write_u8(TWL603X_CHIP_P1, LDOUSB_CTRL, val); + if (err) { + printf("palmas: could not enable 3v3 %s: err = %d\n", + val ? "on" : "off", err); + return err; + } +} +#endif + /* * Enable/disable back-up battery (or super cap) charging on TWL6035/37. * Please use defined BB_xxx values. diff --git a/include/palmas.h b/include/palmas.h index aff48b5..43887c2 100644 --- a/include/palmas.h +++ b/include/palmas.h @@ -130,5 +130,6 @@ int palmas_mmc1_poweron_ldo(void); int twl603x_mmc1_set_ldo9(u8 vsel); int twl603x_audio_power(u8 on); int twl603x_enable_bb_charge(u8 bb_fields); +int palmas_usb_poweron_ldo(void);
#endif /* PALMAS_H */
Dan,
On 07/10/2013 11:05 PM, Dan Murphy wrote:
Add an interface to the palmas driver to enable the LDO9 power supply for the USB hub IC.
As per rev.C1 uEVM schematics, LDO9 is for SDIO card and not for USB hub.
USB hub seems to be powered by DC_5V directly.
Which version are you referring to?
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/power/palmas.c | 34 ++++++++++++++++++++++++++++++++++ include/palmas.h | 1 + 2 files changed, 35 insertions(+)
cheers, -roger
On 07/11/2013 02:56 AM, Roger Quadros wrote:
Dan,
On 07/10/2013 11:05 PM, Dan Murphy wrote:
Add an interface to the palmas driver to enable the LDO9 power supply for the USB hub IC.
As per rev.C1 uEVM schematics, LDO9 is for SDIO card and not for USB hub.
USB hub seems to be powered by DC_5V directly.
Which version are you referring to?
You are correct I will remove this patch.
It is not needed
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/power/palmas.c | 34 ++++++++++++++++++++++++++++++++++ include/palmas.h | 1 + 2 files changed, 35 insertions(+)
cheers, -roger
* Enable the OMAP5 EHCI host clocks * Add OMAP5 EHCI register definitions * Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl, + (*prcm)->cm_clksel_usb_60mhz, + (*prcm)->cm_l3init_hsusbtll_clkctrl, 0 };
@@ -423,6 +425,7 @@ void enable_basic_clocks(void) (*prcm)->cm_wkup_wdtimer2_clkctrl, (*prcm)->cm_l4per_uart3_clkctrl, (*prcm)->cm_l4per_i2c1_clkctrl, + (*prcm)->cm_l3init_hsusbhost_clkctrl, 0 };
@@ -446,6 +449,16 @@ void enable_basic_clocks(void) setbits_le32((*prcm)->cm_wkup_gptimer1_clkctrl, GPTIMER1_CLKCTRL_CLKSEL_MASK);
+#ifdef CONFIG_USB_EHCI + /* Enable port 2 and 3 clocks*/ + setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl, + USB_HOST_HS_CLKCTRL_MASK); + + /* Enable all 3 usb host ports tll clocks*/ + setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl, + USB_TLL_HS_CLKCTRL_MASK); +#endif + do_enable_clocks(clk_domains_essential, clk_modules_hw_auto_essential, clk_modules_explicit_en_essential, diff --git a/arch/arm/include/asm/arch-omap5/clock.h b/arch/arm/include/asm/arch-omap5/clock.h index 4d2765d..3a58337 100644 --- a/arch/arm/include/asm/arch-omap5/clock.h +++ b/arch/arm/include/asm/arch-omap5/clock.h @@ -165,6 +165,12 @@ /* CM_L3INIT_USBPHY_CLKCTRL */ #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK 8
+/* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_HOST_HS_CLKCTRL_MASK 0x56C0 + +/* CM_L3INIT_USB_TLL_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK 0x700 + /* CM_MPU_MPU_CLKCTRL */ #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT 24 #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK (3 << 24) diff --git a/arch/arm/include/asm/arch-omap5/ehci.h b/arch/arm/include/asm/arch-omap5/ehci.h new file mode 100644 index 0000000..3921e4a --- /dev/null +++ b/arch/arm/include/asm/arch-omap5/ehci.h @@ -0,0 +1,43 @@ +/* + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com* + * Author: Govindraj R govindraj.raja@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef _EHCI_H +#define _EHCI_H + +#define OMAP_EHCI_BASE (OMAP54XX_L4_CORE_BASE + 0x64C00) +#define OMAP_UHH_BASE (OMAP54XX_L4_CORE_BASE + 0x64000) +#define OMAP_USBTLL_BASE (OMAP54XX_L4_CORE_BASE + 0x62000) + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 + +#define OMAP_UHH_SYSCONFIG_SOFTRESET 1 +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) +#define OMAP_UHH_SYSCONFIG_NOIDLE (1 << 2) +#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 << 4) + +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \ + OMAP_UHH_SYSCONFIG_NOSTDBY) + +#endif /* _EHCI_H */ diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h index 77e8170..0b09e9d 100644 --- a/arch/arm/include/asm/ehci-omap.h +++ b/arch/arm/include/asm/ehci-omap.h @@ -42,6 +42,7 @@ enum usbhs_omap_port_mode { /* Values of UHH_REVISION - Note: these are not given in the TRM */ #define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ #define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ +#define OMAP_USBHS_REV2_1 0x50700101 /* OMAP5 */
/* UHH Register Set */ #define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 086c697..17f2214 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -208,7 +208,7 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata, clrbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS); else setbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS); - } else if (rev == OMAP_USBHS_REV2) { + } else if ((rev == OMAP_USBHS_REV2) || (rev == OMAP_USBHS_REV2_1)) { clrsetbits_le32(®, (OMAP_P1_MODE_CLEAR | OMAP_P2_MODE_CLEAR), OMAP4_UHH_HOSTCONFIG_APP_START_CLK);
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,
guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
0};
@@ -423,6 +425,7 @@ void enable_basic_clocks(void) (*prcm)->cm_wkup_wdtimer2_clkctrl, (*prcm)->cm_l4per_uart3_clkctrl, (*prcm)->cm_l4per_i2c1_clkctrl,
(*prcm)->cm_l3init_hsusbhost_clkctrl,
same here...
Thanks, Lokesh
0};
@@ -446,6 +449,16 @@ void enable_basic_clocks(void) setbits_le32((*prcm)->cm_wkup_gptimer1_clkctrl, GPTIMER1_CLKCTRL_CLKSEL_MASK);
+#ifdef CONFIG_USB_EHCI
- /* Enable port 2 and 3 clocks*/
- setbits_le32((*prcm)->cm_l3init_hsusbhost_clkctrl,
USB_HOST_HS_CLKCTRL_MASK);- /* Enable all 3 usb host ports tll clocks*/
- setbits_le32((*prcm)->cm_l3init_hsusbtll_clkctrl,
USB_TLL_HS_CLKCTRL_MASK);+#endif
- do_enable_clocks(clk_domains_essential, clk_modules_hw_auto_essential, clk_modules_explicit_en_essential,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h b/arch/arm/include/asm/arch-omap5/clock.h index 4d2765d..3a58337 100644 --- a/arch/arm/include/asm/arch-omap5/clock.h +++ b/arch/arm/include/asm/arch-omap5/clock.h @@ -165,6 +165,12 @@ /* CM_L3INIT_USBPHY_CLKCTRL */ #define USBPHY_CLKCTRL_OPTFCLKEN_PHY_48M_MASK 8
+/* CM_L3INIT_USB_HOST_HS_CLKCTRL */ +#define USB_HOST_HS_CLKCTRL_MASK 0x56C0
+/* CM_L3INIT_USB_TLL_HS_CLKCTRL */ +#define USB_TLL_HS_CLKCTRL_MASK 0x700
/* CM_MPU_MPU_CLKCTRL */ #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_SHIFT 24 #define MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK (3 << 24) diff --git a/arch/arm/include/asm/arch-omap5/ehci.h b/arch/arm/include/asm/arch-omap5/ehci.h new file mode 100644 index 0000000..3921e4a --- /dev/null +++ b/arch/arm/include/asm/arch-omap5/ehci.h @@ -0,0 +1,43 @@ +/*
- Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com*
- Author: Govindraj R govindraj.raja@ti.com
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- */
+#ifndef _EHCI_H +#define _EHCI_H
+#define OMAP_EHCI_BASE (OMAP54XX_L4_CORE_BASE + 0x64C00) +#define OMAP_UHH_BASE (OMAP54XX_L4_CORE_BASE + 0x64000) +#define OMAP_USBTLL_BASE (OMAP54XX_L4_CORE_BASE + 0x62000)
+/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1
+#define OMAP_UHH_SYSCONFIG_SOFTRESET 1 +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) +#define OMAP_UHH_SYSCONFIG_NOIDLE (1 << 2) +#define OMAP_UHH_SYSCONFIG_NOSTDBY (1 << 4)
+#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_NOIDLE | \
OMAP_UHH_SYSCONFIG_NOSTDBY)+#endif /* _EHCI_H */ diff --git a/arch/arm/include/asm/ehci-omap.h b/arch/arm/include/asm/ehci-omap.h index 77e8170..0b09e9d 100644 --- a/arch/arm/include/asm/ehci-omap.h +++ b/arch/arm/include/asm/ehci-omap.h @@ -42,6 +42,7 @@ enum usbhs_omap_port_mode { /* Values of UHH_REVISION - Note: these are not given in the TRM */ #define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ #define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ +#define OMAP_USBHS_REV2_1 0x50700101 /* OMAP5 */
/* UHH Register Set */ #define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 086c697..17f2214 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -208,7 +208,7 @@ int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata, clrbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS); else setbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS);
- } else if (rev == OMAP_USBHS_REV2) {
- } else if ((rev == OMAP_USBHS_REV2) || (rev == OMAP_USBHS_REV2_1)) { clrsetbits_le32(®, (OMAP_P1_MODE_CLEAR | OMAP_P2_MODE_CLEAR), OMAP4_UHH_HOSTCONFIG_APP_START_CLK);
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
0};
cheers, -roger
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all.
Regards, Sricharan
0};
cheers, -roger
On 07/11/2013 11:35 AM, Sricharan R wrote:
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all.
If there is no directory, it could be created I suppose. IMHO it would become ugly soon if it doesn't have its own hw_data.
cheers, -roger
On Thursday 11 July 2013 02:25 PM, Roger Quadros wrote:
On 07/11/2013 11:35 AM, Sricharan R wrote:
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all.
If there is no directory, it could be created I suppose. IMHO it would become ugly soon if it doesn't have its own hw_data.
I am not much against it, it might look clean but would result in some code duplication. I feel we should do it if we add another DRA variant.
Regards, Sricharan
On 07/11/2013 04:31 AM, Sricharan R wrote:
On Thursday 11 July 2013 02:25 PM, Roger Quadros wrote:
On 07/11/2013 11:35 AM, Sricharan R wrote:
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all.
If there is no directory, it could be created I suppose. IMHO it would become ugly soon if it doesn't have its own hw_data.
I am not much against it, it might look clean but would result in some code duplication. I feel we should do it if we add another DRA variant.
Regards, Sricharan
For now I will wrap it in CONFIG_USB_EHCI_OMAP until the dra7xx is figured out.
+1 to a separate SoC directory for dra7xx
Dan
On Thu, Jul 11, 2013 at 11:55:59AM +0300, Roger Quadros wrote:
On 07/11/2013 11:35 AM, Sricharan R wrote:
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
- Enable the OMAP5 EHCI host clocks
- Add OMAP5 EHCI register definitions
- Add OMAP5 ES2 host revision
Signed-off-by: Dan Murphy dmurphy@ti.com
arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++++++++++ arch/arm/include/asm/arch-omap5/clock.h | 6 +++++ arch/arm/include/asm/arch-omap5/ehci.h | 43 +++++++++++++++++++++++++++++++ arch/arm/include/asm/ehci-omap.h | 1 + drivers/usb/host/ehci-omap.c | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)->cm_l4per_gpio4_clkctrl, (*prcm)->cm_l4per_gpio5_clkctrl, (*prcm)->cm_l4per_gpio6_clkctrl,
(*prcm)->cm_clksel_usb_60mhz,(*prcm)->cm_l3init_hsusbtll_clkctrl,guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards.
why is DRA7xx using omap5/hw_data.c?
doesn't it qualify for its own SoC directory?
We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all.
If there is no directory, it could be created I suppose. IMHO it would become ugly soon if it doesn't have its own hw_data.
Lets wait and see how it goes, and if we can't use some of the other tools in our toolbox to clean things up or at least avoid the duplication.
Fix the linker error for missing ulpi_reset when ulpi is not defined in the board config.
Signed-off-by: Dan Murphy dmurphy@ti.com --- drivers/usb/host/ehci-omap.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 17f2214..bd7191c 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -90,6 +90,7 @@ static void omap_usbhs_hsic_init(int port) writel(reg, &usbtll->channel_conf + port); }
+#ifdef CONFIG_USB_ULPI static void omap_ehci_soft_phy_reset(int port) { struct ulpi_viewport ulpi_vp; @@ -99,6 +100,12 @@ static void omap_ehci_soft_phy_reset(int port)
ulpi_reset(&ulpi_vp); } +#else +static void omap_ehci_soft_phy_reset(int port) +{ + return; +} +#endif
inline int __board_usb_init(void) {
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com --- drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; }
+__weak void ehci_reset_attached_devices(int port) +{ + return; +} + int ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, int length, struct devrequest *req) @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PP; ehci_writel(status_reg, reg); } + ehci_reset_attached_devices(port); break; case USB_PORT_FEAT_RESET: if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS && @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PR; reg &= ~EHCI_PS_PE; ehci_writel(status_reg, reg); + /* * caller must wait, then call GetPortStatus * usb 2.0 specification say 50 ms resets on
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; }
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Can the reset not happen elsewhere?
int ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, int length, struct devrequest *req) @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PP; ehci_writel(status_reg, reg); }
ehci_reset_attached_devices(port); break;@@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PR; reg &= ~EHCI_PS_PE; ehci_writel(status_reg, reg);
NAK
/* * caller must wait, then call GetPortStatus * usb 2.0 specification say 50 ms resets on
Best regards, Marek Vasut
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; }
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
int ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, int length, struct devrequest *req) @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PP; ehci_writel(status_reg, reg); }
ehci_reset_attached_devices(port); break;@@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PR; reg &= ~EHCI_PS_PE; ehci_writel(status_reg, reg);
NAK
DOH!
/* * caller must wait, then call GetPortStatus * usb 2.0 specification say 50 ms resets onBest regards, Marek Vasut
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; }
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point). - start USB controller - wait a few ms - release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
cheers, -roger
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
}
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
Best regards, Marek Vasut
Hi Marek,
On 07/11/2013 03:35 PM, Marek Vasut wrote:
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
}
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
OK.
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init().
cheers, -roger
Roger On 07/11/2013 09:23 AM, Roger Quadros wrote:
Hi Marek,
On 07/11/2013 03:35 PM, Marek Vasut wrote:
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
}
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
OK.
I can move the API to the usb-hub to call this after the FEAT_POWER is completed
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
This has nothing to do with the 3503A this is the LAN9730. The 3503 works just fine without the additional reset.
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init().
cheers, -roger
I moved the reset to the usb_lowlevel_init and it did not work. I tried holding the 9730 in reset until after ehci hcd init is complete and pulled it out of reset once the hcd is initialized but still no enumeration.
Dan
Dear Dan Murphy,
Roger
On 07/11/2013 09:23 AM, Roger Quadros wrote:
Hi Marek,
On 07/11/2013 03:35 PM, Marek Vasut wrote:
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
> Add a __weak function that can be overridden to reset devices > attached to an ehci devices after the FEAT_POWER has been submitted > > Signed-off-by: Dan Murphy dmurphy@ti.com > --- > > drivers/usb/host/ehci-hcd.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/host/ehci-hcd.c > b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -616,6 +616,11 @@ __weak uint32_t > *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return > (uint32_t *)&hcor->or_portsc[port]; > > } > > +__weak void ehci_reset_attached_devices(int port) > +{ > + return; > +}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
OK.
I can move the API to the usb-hub to call this after the FEAT_POWER is completed
> +
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
This has nothing to do with the 3503A this is the LAN9730. The 3503 works just fine without the additional reset.
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init().
cheers, -roger
I moved the reset to the usb_lowlevel_init and it did not work. I tried holding the 9730 in reset until after ehci hcd init is complete and pulled it out of reset once the hcd is initialized but still no enumeration.
Can you try waiting a little after negating the reset ? It might be that the device takes some time to come back to life.
Best regards, Marek Vasut
Marek On 07/14/2013 10:19 PM, Marek Vasut wrote:
Dear Dan Murphy,
Roger
On 07/11/2013 09:23 AM, Roger Quadros wrote:
Hi Marek,
On 07/11/2013 03:35 PM, Marek Vasut wrote:
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote: > Dear Dan Murphy, > >> Add a __weak function that can be overridden to reset devices >> attached to an ehci devices after the FEAT_POWER has been submitted >> >> Signed-off-by: Dan Murphy dmurphy@ti.com >> --- >> >> drivers/usb/host/ehci-hcd.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/usb/host/ehci-hcd.c >> b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -616,6 +616,11 @@ __weak uint32_t >> *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return >> (uint32_t *)&hcor->or_portsc[port]; >> >> } >> >> +__weak void ehci_reset_attached_devices(int port) >> +{ >> + return; >> +}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
OK.
I can move the API to the usb-hub to call this after the FEAT_POWER is completed
>> + > Can the reset not happen elsewhere? I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
This has nothing to do with the 3503A this is the LAN9730. The 3503 works just fine without the additional reset.
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init().
cheers, -roger
I moved the reset to the usb_lowlevel_init and it did not work. I tried holding the 9730 in reset until after ehci hcd init is complete and pulled it out of reset once the hcd is initialized but still no enumeration.
Can you try waiting a little after negating the reset ? It might be that the device takes some time to come back to life.
Best regards, Marek Vasut
I have tried that.
I have a more general less invasive patch set I am going to submit.
It will place the last two patches that in in disagreement at the end of the set so at least we can get the initial ones in.
Dan
Dear Roger Quadros,
Hi Marek,
On 07/11/2013 03:35 PM, Marek Vasut wrote:
Dear Roger Quadros,
On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
Dear Dan Murphy,
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted
Signed-off-by: Dan Murphy dmurphy@ti.com
drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
}
+__weak void ehci_reset_attached_devices(int port) +{
- return;
+}
Does this function need to be ehci specific? Other USB controllers might also need such a function.
You'd need to implement this for each of the xHCIs
OK.
Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly.
I did not see any information in the data sheet eluding to a timing issue.
This is the information I had received earlier from SMSC about USB3503A hub
"You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues."
Please make sure the following sequence is done.
- power up hub (RESET is active at this point).
- start USB controller
- wait a few ms
- release hub RESET.
giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
Then it would also work in usb_lowlevel_init() ?
It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init().
Can you maybe use any of the hooks efikamx uses ? board/genesi/mx51_efikamx/efikamx-usb.c
Best regards, Marek Vasut
Add the USB ehci support for the OMAP5 uEVM.
Configure the uEVM mux data Add the flags to build the appropriate modules Add the usb call backs to initialize the EHCI controller
Signed-off-by: Dan Murphy dmurphy@ti.com --- board/ti/omap5_uevm/evm.c | 58 ++++++++++++++++++++++++++++++++++++++++ board/ti/omap5_uevm/mux_data.h | 4 ++- include/configs/omap5_common.h | 2 -- include/configs/omap5_uevm.h | 24 +++++++++++++++++ 4 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c index 00bd72d..6c6b320 100644 --- a/board/ti/omap5_uevm/evm.c +++ b/board/ti/omap5_uevm/evm.c @@ -26,9 +26,16 @@ #include <palmas.h> #include <asm/arch/sys_proto.h> #include <asm/arch/mmc_host_def.h> +#include <asm/gpio.h>
#include "mux_data.h"
+#ifdef CONFIG_USB_EHCI +#include <usb.h> +#include <asm/arch/ehci.h> +#include <asm/ehci-omap.h> +#endif + DECLARE_GLOBAL_DATA_PTR;
const struct omap_sysinfo sysinfo = { @@ -103,3 +110,54 @@ int board_mmc_init(bd_t *bis) return 0; } #endif + +#ifdef CONFIG_USB_EHCI +static struct omap_usbhs_board_data usbhs_bdata = { + .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED, + .port_mode[1] = OMAP_EHCI_PORT_MODE_HSIC, + .port_mode[2] = OMAP_EHCI_PORT_MODE_HSIC, +}; + +int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) +{ + int ret; + int auxclk; + +#ifdef CONFIG_PALMAS_POWER +#ifdef CONFIG_PALMAS_USBPWR + palmas_usb_poweron_ldo(); +#endif +#endif + + auxclk = readl((*prcm)->scrm_auxclk1); + /* Request auxilary clock */ + auxclk |= AUXCLK_ENABLE_MASK; + writel(auxclk, (*prcm)->scrm_auxclk1); + + ret = omap_ehci_hcd_init(&usbhs_bdata, hccr, hcor); + if (ret < 0) { + printf("Failed to initialize ehci\n"); + return ret; + } + + return 0; +} + +int ehci_hcd_stop(void) +{ + int ret; + + ret = omap_ehci_hcd_stop(); + return ret; +} + +void ehci_reset_attached_devices(int port) +{ + /* The LAN9730 needs to be reset after the port power has been set. */ + if (port == 3) { + gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 0); + udelay(10); + gpio_direction_output(CONFIG_OMAP_EHCI_PHY1_RESET_GPIO, 1); + } +} +#endif diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h index a82795d..17de7f5 100644 --- a/board/ti/omap5_uevm/mux_data.h +++ b/board/ti/omap5_uevm/mux_data.h @@ -56,7 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = { {USBD0_HS_DP, (IEN | M0)}, /* USBD0_HS_DP */ {USBD0_HS_DM, (IEN | M0)}, /* USBD0_HS_DM */ {USBD0_SS_RX, (IEN | M0)}, /* USBD0_SS_RX */ - + {HSI2_ACWAKE, (PTU | M6)}, /* HSI2_ACWAKE */ + {HSI2_CAFLAG, (PTU | M6)}, /* HSI2_CAFLAG */ };
const struct pad_conf_entry wkup_padconf_array_essential[] = { @@ -64,6 +65,7 @@ const struct pad_conf_entry wkup_padconf_array_essential[] = { {SR_PMIC_SCL, (PTU | IEN | M0)}, /* SR_PMIC_SCL */ {SR_PMIC_SDA, (PTU | IEN | M0)}, /* SR_PMIC_SDA */ {SYS_32K, (IEN | M0)}, /* SYS_32K */ + {FREF_CLK1_OUT, (PTD | IEN | M0)}, /* FREF_CLK1_OUT */
};
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index b87ee42..32f053d 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -113,8 +113,6 @@ #define CONFIG_CMD_MMC /* MMC support */
/* Disabled commands */ -#undef CONFIG_CMD_NET -#undef CONFIG_CMD_NFS #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ #undef CONFIG_CMD_IMLS /* List all found images */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index 46dacc2..b79ea59 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -53,6 +53,30 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART
+/* USB UHH support options */ +#define CONFIG_CMD_USB +#define CONFIG_USB_HOST +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_OMAP +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET + +#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 79 +#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80 + +#define CONFIG_PALMAS_USBPWR + +/* Enabled commands */ +#define CONFIG_NET_MULTI +#define CONFIG_CMD_DHCP /* DHCP Support */ +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot */ +#define CONFIG_CMD_NFS /* NFS support */ + +/* USB Networking options */ +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX + #define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "
#define CONSOLEDEV "ttyO2"
On Wed, Jul 10, 2013 at 03:05:09PM -0500, Dan Murphy wrote:
Add the USB ehci support for the OMAP5 uEVM.
Configure the uEVM mux data Add the flags to build the appropriate modules Add the usb call backs to initialize the EHCI controller
Signed-off-by: Dan Murphy dmurphy@ti.com
[snip]
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index b87ee42..32f053d 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -113,8 +113,6 @@ #define CONFIG_CMD_MMC /* MMC support */
/* Disabled commands */ -#undef CONFIG_CMD_NET -#undef CONFIG_CMD_NFS #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ #undef CONFIG_CMD_IMLS /* List all found images */
Leave this, since O5 doesn't have networking in the SoC.
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index 46dacc2..b79ea59 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -53,6 +53,30 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART
+/* USB UHH support options */ +#define CONFIG_CMD_USB +#define CONFIG_USB_HOST +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_OMAP +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
+#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 79 +#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80
+#define CONFIG_PALMAS_USBPWR
+/* Enabled commands */ +#define CONFIG_NET_MULTI +#define CONFIG_CMD_DHCP /* DHCP Support */ +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot */ +#define CONFIG_CMD_NFS /* NFS support */
+/* USB Networking options */ +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX
#define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "
#define CONSOLEDEV "ttyO2"
And then this hunk is fine.
participants (7)
-
Dan Murphy -
Lokesh Vutla -
Marek Vasut -
Nishanth Menon -
Roger Quadros -
Sricharan R -
Tom Rini