* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs
@ 2012-01-06 9:03 Govindraj.R
2012-01-06 9:03 ` [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c Govindraj.R
` (4 more replies)
0 siblings, 5 replies; 40+ messages in thread
From: Govindraj.R @ 2012-01-06 9:03 UTC (permalink / raw)
To: u-boot
From: "Govindraj.R" <govindraj.raja@ti.com>
Clean up ehci-omap added and make it generic to extend support for omap4 socs.
Add ehci support for panda board.
Patch series depends on below patch:
http://patchwork.ozlabs.org/patch/130952/
Patch series based commit id:
9a420986cccc9bd2c37affd931d627b3c3e72952
This patch series long with above dependent patch is avialable at:
git://gitorious.org/denx_u-boot/denx_uboot_omap.git
v2_ehci_omap4
Fatls, ping and tftp was tested with this patch series.
Test log for Panda available here:
http://pastebin.pandaboard.org/index.php/view/55361716
Test log for Beagle-XM available here:
http://pastebin.pandaboard.org/index.php/view/98437825
Changes from v1:
---------------
* v1 was adding ehci-omap.c
Now I have rebased my patch on top of Ilya Yanok's Patch
http://patchwork.ozlabs.org/patch/130952/
* Fixed Tom Rini's Comments as in below thread.
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/120430
http://patchwork.ozlabs.org/patch/131367/
Govindraj.R (4):
ehci-omap: Clean up added ehci-omap.c
OMAP3+: Clock: Adding ehci clock enabling
OMAP4: clock-common: Move the usb dppl configuration to new func
OMAP3+: ehci-omap: enable usb host ports for beagle/panda
arch/arm/cpu/armv7/omap-common/clocks-common.c | 52 ++++--
arch/arm/cpu/armv7/omap3/board.c | 4 +
arch/arm/cpu/armv7/omap3/clock.c | 20 ++
arch/arm/cpu/armv7/omap4/clocks.c | 5 +
arch/arm/include/asm/arch-omap3/ehci.h | 55 ++++++
arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ------
arch/arm/include/asm/arch-omap3/sys_proto.h | 1 +
arch/arm/include/asm/arch-omap4/ehci.h | 49 +++++
arch/arm/include/asm/ehci-omap.h | 147 +++++++++++++++
board/ti/beagle/beagle.c | 28 +++
board/ti/panda/panda.c | 41 +++++
board/ti/panda/panda_mux_data.h | 16 +-
drivers/usb/host/ehci-omap.c | 228 ++++++++++++++++++------
include/configs/omap4_panda.h | 23 +++-
14 files changed, 584 insertions(+), 143 deletions(-)
create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h
delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h
create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h
create mode 100644 arch/arm/include/asm/ehci-omap.h
--
1.7.5.4
^ permalink raw reply [flat|nested] 40+ messages in thread* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R @ 2012-01-06 9:03 ` Govindraj.R 2012-01-10 16:07 ` Marek Vasut 2012-01-06 9:03 ` [U-Boot] [PATCH v2 2/4] OMAP3+: Clock: Adding ehci clock enabling Govindraj.R ` (3 subsequent siblings) 4 siblings, 1 reply; 40+ messages in thread From: Govindraj.R @ 2012-01-06 9:03 UTC (permalink / raw) To: u-boot From: "Govindraj.R" <govindraj.raja@ti.com> Clean up added ehci-omap.c and make it generic for re-use across soc having same ehci ip block. Also pass the modes to be configured and configure the ports accordingly. All usb layers are not cache aligned till then keep cache off for usb ops as ehci will use internally dma for all usb ops. * Add a generic common header ehci-omap.h having common ip block data and reg shifts. * Rename and modify ehci-omap3 to ehci.h retain only conflicting sysc reg shifts remove others and move to common header file. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> --- arch/arm/include/asm/arch-omap3/ehci.h | 55 ++++++ arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ------- arch/arm/include/asm/arch-omap4/ehci.h | 49 ++++++ arch/arm/include/asm/ehci-omap.h | 147 +++++++++++++++++ drivers/usb/host/ehci-omap.c | 228 +++++++++++++++++++------- 5 files changed, 423 insertions(+), 114 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h create mode 100644 arch/arm/include/asm/ehci-omap.h diff --git a/arch/arm/include/asm/arch-omap3/ehci.h b/arch/arm/include/asm/arch-omap3/ehci.h new file mode 100644 index 0000000..d622363 --- /dev/null +++ b/arch/arm/include/asm/arch-omap3/ehci.h @@ -0,0 +1,55 @@ +/* + * (C) Copyright 2011 + * Alexander Holler <holler@ahsoftware.de> + * + * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 + * + * See there for additional Copyrights. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ +#ifndef _EHCI_H_ +#define _EHCI_H_ + +/* USB/EHCI registers */ +#define OMAP_USBTLL_BASE 0x48062000UL +#define OMAP_UHH_BASE 0x48064000UL +#define OMAP_EHCI_BASE 0x48064800UL + +/* TLL Register Set */ +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 + +/* UHH Register Set */ +#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) +#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) +#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) +#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) +#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) + +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_CACTIVITY | \ + OMAP_UHH_SYSCONFIG_SIDLEMODE | \ + OMAP_UHH_SYSCONFIG_ENAWAKEUP | \ + OMAP_UHH_SYSCONFIG_MIDLEMODE) + +#endif /* _EHCI_H_ */ diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h b/arch/arm/include/asm/arch-omap3/ehci_omap3.h deleted file mode 100644 index cd01f50..0000000 --- a/arch/arm/include/asm/arch-omap3/ehci_omap3.h +++ /dev/null @@ -1,58 +0,0 @@ -/* - * (C) Copyright 2011 - * Alexander Holler <holler@ahsoftware.de> - * - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 - * - * See there for additional Copyrights. - * - * See file CREDITS for list of people who contributed to this - * project. - * - * 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., 51 Franklin Street, Fifth Floor, Boston, - * MA 02110-1301 USA - */ -#ifndef _EHCI_OMAP3_H_ -#define _EHCI_OMAP3_H_ - -/* USB/EHCI registers */ -#define OMAP3_USBTLL_BASE 0x48062000UL -#define OMAP3_UHH_BASE 0x48064000UL -#define OMAP3_EHCI_BASE 0x48064800UL - -/* TLL Register Set */ -#define OMAP_USBTLL_SYSCONFIG (0x10) -#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) -#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) -#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) -#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) - -#define OMAP_USBTLL_SYSSTATUS (0x14) -#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0) - -/* UHH Register Set */ -#define OMAP_UHH_SYSCONFIG (0x10) -#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) -#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) -#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) -#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) -#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) - -#define OMAP_UHH_HOSTCONFIG (0x40) -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) - -#endif /* _EHCI_OMAP3_H_ */ diff --git a/arch/arm/include/asm/arch-omap4/ehci.h b/arch/arm/include/asm/arch-omap4/ehci.h new file mode 100644 index 0000000..3af171b --- /dev/null +++ b/arch/arm/include/asm/arch-omap4/ehci.h @@ -0,0 +1,49 @@ +/* + * OMAP EHCI port support + * Based on LINUX KERNEL + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c + * + * Copyright (C) 2011 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 version 2 of + * the License as published by the Free Software Foundation. + * + * 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, see <http://www.gnu.org/licenses/>. + */ + +#ifndef _EHCI_H +#define _EHCI_H + +#define OMAP_EHCI_BASE (OMAP44XX_L4_CORE_BASE + 0x64C00) +#define OMAP_UHH_BASE (OMAP44XX_L4_CORE_BASE + 0x64000) +#define OMAP_USBTLL_BASE (OMAP44XX_L4_CORE_BASE + 0x62000) + +/* UHH, TLL and opt clocks */ +#define CM_L3INIT_HSUSBHOST_CLKCTRL 0x4A009358UL + +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK (1 << 24) + +/* 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 new file mode 100644 index 0000000..336d77e --- /dev/null +++ b/arch/arm/include/asm/ehci-omap.h @@ -0,0 +1,147 @@ +/* + * OMAP EHCI port support + * Based on LINUX KERNEL + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c + * + * Copyright (C) 2011 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 version 2 of + * the License as published by the Free Software Foundation. + * + * 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, see <http://www.gnu.org/licenses/>. + */ + +#ifndef EHCI_H +#define EHCI_H + +enum usbhs_omap_port_mode { + OMAP_USBHS_PORT_MODE_UNUSED, + OMAP_EHCI_PORT_MODE_PHY, + OMAP_EHCI_PORT_MODE_TLL, + OMAP_EHCI_PORT_MODE_HSIC, +}; + +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS +#define OMAP_HS_USB_PORTS CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS +#else +#define OMAP_HS_USB_PORTS 3 +#endif + +#define is_ehci_phy_mode(x) (x == OMAP_EHCI_PORT_MODE_PHY) +#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL) +#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC) + +/* Values of UHH_REVISION - Note: these are not given in the TRM */ +#define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ +#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ + +/* UHH Register Set */ +#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) +#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) +#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) +#define OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN (1 << 5) + +#define OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS 1 +#define OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS (1 << 11) +#define OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS (1 << 12) +#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 << 31) + +#define OMAP_P1_MODE_CLEAR (3 << 16) +#define OMAP_P1_MODE_TLL (1 << 16) +#define OMAP_P1_MODE_HSIC (3 << 16) +#define OMAP_P2_MODE_CLEAR (3 << 18) +#define OMAP_P2_MODE_TLL (1 << 18) +#define OMAP_P2_MODE_HSIC (3 << 18) + +/* EHCI Register Set */ +#define EHCI_INSNREG04_DISABLE_UNSUSPEND (1 << 5) +#define EHCI_INSNREG05_ULPI_CONTROL_SHIFT 31 +#define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT 24 +#define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22 +#define EHCI_INSNREG05_ULPI_REGADD_SHIFT 16 + +#define OMAP_REV1_TLL_CHANNEL_COUNT 3 +#define OMAP_REV2_TLL_CHANNEL_COUNT 2 + +/* TLL Register Set */ +#define OMAP_TLL_CHANNEL_CONF(num) (0x004 * num) +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 << 16) +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 << 15) +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF (1 << 11) +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI (2 << 1) +#define OMAP_TLL_CHANNEL_CONF_CHANEN 1 + +/* ULPI */ +#define ULPI_SET(a) (a + 1) +#define ULPI_CLR(a) (a + 2) +#define ULPI_FUNC_CTRL 0x04 +#define ULPI_FUNC_CTRL_RESET (1 << 5) + +struct omap_usbhs_board_data { + enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; +}; + +struct omap_usbtll { + u32 rev; /* 0x00 */ + u32 hwinfo; /* 0x04 */ + u8 pad1[0x8]; + u32 sysc; /* 0x10 */ + u32 syss; /* 0x14 */ + u32 irqst; /* 0x18 */ + u32 irqen; /* 0x1c */ + u8 pad2[0x10]; + u32 shared_conf; /* 0x30 */ + u8 pad3[0xc]; + u32 channel_conf; /* 0x40 */ +}; + +struct omap_uhh { + u32 rev; /* 0x00 */ + u32 hwinfo; /* 0x04 */ + u8 pad1[0x8]; + u32 sysc; /* 0x10 */ + u32 syss; /* 0x14 */ + u8 pad2[0x28]; + u32 hostconfig; /* 0x40 */ + u32 debugcsr; /* 0x44 */ +}; + +struct omap_ehci { + u32 hccapbase; /* 0x00 */ + u32 hcsparams; /* 0x04 */ + u32 hccparams; /* 0x08 */ + u8 pad1[0x04]; + u32 usbcmd; /* 0x10 */ + u32 usbsts; /* 0x14 */ + u32 usbintr; /* 0x18 */ + u32 frindex; /* 0x1c */ + u32 ctrldssegment; /* 0x20 */ + u32 periodiclistbase; /* 0x24 */ + u32 asysnclistaddr; /* 0x28 */ + u8 pad2[0x24]; + u32 configflag; /* 0x50 */ + u32 portsc_i; /* 0x54 */ + u8 pad3[0x38]; + u32 insreg00; /* 0x90 */ + u32 insreg01; /* 0x94 */ + u32 insreg02; /* 0x98 */ + u32 insreg03; /* 0x9c */ + u32 insreg04; /* 0xa0 */ + u32 insreg05_utmi_ulpi; /* 0xa4 */ + u32 insreg06; /* 0xa8 */ + u32 insreg07; /* 0xac */ + u32 insreg08; /* 0xb0 */ +}; + +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata); +int omap_ehci_hcd_stop(void); + +#endif /* EHCI_H */ diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 93d3bb7..97c9fa3 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -27,14 +27,93 @@ */ #include <common.h> #include <usb.h> +#include <errno.h> #include <asm/io.h> #include <asm/gpio.h> -#include <asm/arch/clocks.h> -#include <asm/arch/clocks_omap3.h> -#include <asm/arch/ehci_omap3.h> -#include <asm/arch/sys_proto.h> +#include <asm/arch/ehci.h> +#include <asm/ehci-omap.h> #include "ehci-core.h" +struct omap_uhh *const uhh = (struct omap_uhh *)OMAP_UHH_BASE; +struct omap_usbtll *const usbtll = (struct omap_usbtll *)OMAP_USBTLL_BASE; +struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE; + +static int omap_uhh_reset(void) +{ + unsigned long init = get_timer(0); + + /* perform UHH soft reset, and wait until reset is complete */ + writel(OMAP_UHH_SYSCONFIG_SOFTRESET, &uhh->sysc); + + /* Wait for UHH reset to complete */ + while (!(readl(&uhh->syss) & OMAP_UHH_SYSSTATUS_EHCI_RESETDONE)) + if (get_timer(init) > CONFIG_SYS_HZ) { + debug("OMAP UHH error: timeout resetting ehci\n"); + return -EL3RST; + } + + return 0; +} + +static int omap_ehci_tll_reset(void) +{ + unsigned long init = get_timer(0); + + /* perform TLL soft reset, and wait until reset is complete */ + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, &usbtll->sysc); + + /* Wait for TLL reset to complete */ + while (!(readl(&usbtll->syss) & OMAP_USBTLL_SYSSTATUS_RESETDONE)) + if (get_timer(init) > CONFIG_SYS_HZ) { + debug("OMAP EHCI error: timeout resetting TLL\n"); + return -EL3RST; + } + + return 0; +} + +static void omap_usbhs_hsic_init(int tll_cnt) +{ + unsigned int reg; + int i; + + /* Enable channels now */ + for (i = 0; i < tll_cnt; i++) { + reg = readl(&usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); + + reg |= OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI + | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF + | OMAP_TLL_CHANNEL_CONF_DRVVBUS + | OMAP_TLL_CHANNEL_CONF_CHRGVBUS + | OMAP_TLL_CHANNEL_CONF_CHANEN; + + writel(reg, &usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); + } +} + +static void omap_ehci_soft_phy_reset(int port) +{ + unsigned int reg = 0; + unsigned long init = get_timer(0); + + /* FUNCTION_CTRL_SET register */ + reg = ULPI_FUNC_CTRL_RESET | + (ULPI_SET(ULPI_FUNC_CTRL) << EHCI_INSNREG05_ULPI_REGADD_SHIFT) | + (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) | + ((port + 1) << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) | + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT); + + writel(reg, &ehci->insreg05_utmi_ulpi); + + /* Wait for ULPI access completion */ + while ((readl(&ehci->insreg05_utmi_ulpi) & + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) + if (get_timer(init) > CONFIG_SYS_HZ) { + debug("OMAP EHCI error: timeout resetting phy\n"); + break; + } +} + inline int __board_usb_init(void) { return 0; @@ -72,31 +151,31 @@ static inline void omap_ehci_phy_reset(int on, int delay) #endif /* Reset is needed otherwise the kernel-driver will throw an error. */ -int ehci_hcd_stop(void) +int omap_ehci_hcd_stop(void) { - debug("Resetting OMAP3 EHCI\n"); + debug("Resetting OMAP EHCI\n"); omap_ehci_phy_reset(1, 0); - writel(OMAP_UHH_SYSCONFIG_SOFTRESET, - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); - /* disable USB clocks */ - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; - sr32(&prcm_base->iclken_usbhost, 0, 1, 0); - sr32(&prcm_base->fclken_usbhost, 0, 2, 0); - sr32(&prcm_base->iclken3_core, 2, 1, 0); - sr32(&prcm_base->fclken3_core, 2, 1, 0); + + if (omap_uhh_reset() < 0) + return -1; + + if (omap_ehci_tll_reset() < 0) + return -1; + return 0; } /* - * Initialize the OMAP3 EHCI controller and PHY. - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. + * Initialize the OMAP EHCI controller and PHY. + * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 * See there for additional Copyrights. */ -int ehci_hcd_init(void) +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) { - int ret; + int ret = 0; + unsigned int i, reg = 0, rev = 0, tll_cnt = 0; - debug("Initializing OMAP3 EHCI\n"); + debug("Initializing OMAP EHCI\n"); ret = board_usb_init(); if (ret < 0) @@ -105,52 +184,89 @@ int ehci_hcd_init(void) /* Put the PHY in RESET */ omap_ehci_phy_reset(1, 10); - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; - /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ - sr32(&prcm_base->iclken_usbhost, 0, 1, 1); - /* - * Enable USBHOST_48M_FCLK (USBHOST_FCLK1) - * and USBHOST_120M_FCLK (USBHOST_FCLK2) - */ - sr32(&prcm_base->fclken_usbhost, 0, 2, 3); - /* Enable USBTTL_ICLK */ - sr32(&prcm_base->iclken3_core, 2, 1, 1); - /* Enable USBTTL_FCLK */ - sr32(&prcm_base->fclken3_core, 2, 1, 1); - debug("USB clocks enabled\n"); + ret = omap_uhh_reset(); + if (ret < 0) + return ret; - /* perform TLL soft reset, and wait until reset is complete */ - writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); - /* Wait for TLL reset to complete */ - while (!(readl(OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSSTATUS) - & OMAP_USBTLL_SYSSTATUS_RESETDONE)) - ; - debug("TLL reset done\n"); + ret = omap_ehci_tll_reset(); + if (ret) + return ret; writel(OMAP_USBTLL_SYSCONFIG_ENAWAKEUP | OMAP_USBTLL_SYSCONFIG_SIDLEMODE | - OMAP_USBTLL_SYSCONFIG_CACTIVITY, - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); + OMAP_USBTLL_SYSCONFIG_CACTIVITY, &usbtll->sysc); /* Put UHH in NoIdle/NoStandby mode */ - writel(OMAP_UHH_SYSCONFIG_ENAWAKEUP - | OMAP_UHH_SYSCONFIG_SIDLEMODE - | OMAP_UHH_SYSCONFIG_CACTIVITY - | OMAP_UHH_SYSCONFIG_MIDLEMODE, - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); - - /* setup burst configurations */ - writel(OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN - | OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN - | OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN, - OMAP3_UHH_BASE + OMAP_UHH_HOSTCONFIG); + writel(OMAP_UHH_SYSCONFIG_VAL, &uhh->sysc); + + /* setup ULPI bypass and burst configurations */ + reg |= (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN | + OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN | + OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN); + reg &= ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN; + + rev = readl(&uhh->rev); + if (rev == OMAP_USBHS_REV1) { + if (is_ehci_phy_mode(usbhs_pdata->port_mode[0])) + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS; + else + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS; + + if (is_ehci_phy_mode(usbhs_pdata->port_mode[1])) + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS; + else + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS; + + if (is_ehci_phy_mode(usbhs_pdata->port_mode[2])) + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS; + else + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS; + + tll_cnt = OMAP_REV1_TLL_CHANNEL_COUNT; + } else if (rev == OMAP_USBHS_REV2) { + + reg |= OMAP4_UHH_HOSTCONFIG_APP_START_CLK; + /* Clear port mode fields for PHY mode*/ + reg &= ~OMAP_P1_MODE_CLEAR; + reg &= ~OMAP_P2_MODE_CLEAR; + + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0])) + reg |= OMAP_P1_MODE_HSIC; + + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) + reg |= OMAP_P2_MODE_HSIC; + + tll_cnt = OMAP_REV2_TLL_CHANNEL_COUNT; + } + + debug("OMAP UHH_REVISION 0x%x\n", rev); + writel(reg, &uhh->hostconfig); + + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0]) || + is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) + omap_usbhs_hsic_init(tll_cnt); omap_ehci_phy_reset(0, 10); - hccr = (struct ehci_hccr *)(OMAP3_EHCI_BASE); - hcor = (struct ehci_hcor *)(OMAP3_EHCI_BASE + 0x10); + /* + * An undocumented "feature" in the OMAP3 EHCI controller, + * causes suspended ports to be taken out of suspend when + * the USBCMD.Run/Stop bit is cleared (for example when + * we do ehci_bus_suspend). + * This breaks suspend-resume if the root-hub is allowed + * to suspend. Writing 1 to this undocumented register bit + * disables this feature and restores normal behavior. + */ + writel(EHCI_INSNREG04_DISABLE_UNSUSPEND, &ehci->insreg04); + + for (i = 0; i < OMAP_HS_USB_PORTS; i++) + if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) + omap_ehci_soft_phy_reset(i); + + dcache_disable(); + hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); + hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); - debug("OMAP3 EHCI init done\n"); + debug("OMAP EHCI init done\n"); return 0; } -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-06 9:03 ` [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c Govindraj.R @ 2012-01-10 16:07 ` Marek Vasut 2012-01-11 6:07 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-01-10 16:07 UTC (permalink / raw) To: u-boot > From: "Govindraj.R" <govindraj.raja@ti.com> > > Clean up added ehci-omap.c and make it generic for re-use across > soc having same ehci ip block. Also pass the modes to be configured > and configure the ports accordingly. All usb layers are not cache > aligned till then keep cache off for usb ops as ehci will use > internally dma for all usb ops. > > * Add a generic common header ehci-omap.h having common ip block > data and reg shifts. > * Rename and modify ehci-omap3 to ehci.h retain only conflicting > sysc reg shifts remove others and move to common header file. Don't reimplement the ulpi stuff ... there's already some ulpi stuff in uboot that needs fixing, so fix it and use it. > > Signed-off-by: Govindraj.R <govindraj.raja@ti.com> > --- > arch/arm/include/asm/arch-omap3/ehci.h | 55 ++++++ > arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ------- > arch/arm/include/asm/arch-omap4/ehci.h | 49 ++++++ > arch/arm/include/asm/ehci-omap.h | 147 +++++++++++++++++ > drivers/usb/host/ehci-omap.c | 228 > +++++++++++++++++++------- 5 files changed, 423 insertions(+), 114 > deletions(-) > create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h > delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h > create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h > create mode 100644 arch/arm/include/asm/ehci-omap.h > > diff --git a/arch/arm/include/asm/arch-omap3/ehci.h > b/arch/arm/include/asm/arch-omap3/ehci.h new file mode 100644 > index 0000000..d622363 > --- /dev/null > +++ b/arch/arm/include/asm/arch-omap3/ehci.h > @@ -0,0 +1,55 @@ > +/* > + * (C) Copyright 2011 > + * Alexander Holler <holler@ahsoftware.de> > + * > + * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 > + * > + * See there for additional Copyrights. > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * 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., 51 Franklin Street, Fifth Floor, Boston, > + * MA 02110-1301 USA > + */ > +#ifndef _EHCI_H_ > +#define _EHCI_H_ > + > +/* USB/EHCI registers */ > +#define OMAP_USBTLL_BASE 0x48062000UL > +#define OMAP_UHH_BASE 0x48064000UL > +#define OMAP_EHCI_BASE 0x48064800UL > + > +/* TLL Register Set */ > +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) > +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) > +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) > +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) > +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 > + > +/* UHH Register Set */ > +#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) > +#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) > +#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) > +#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) > +#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) > +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) > + > +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_CACTIVITY | \ > + OMAP_UHH_SYSCONFIG_SIDLEMODE | \ > + OMAP_UHH_SYSCONFIG_ENAWAKEUP | \ > + OMAP_UHH_SYSCONFIG_MIDLEMODE) > + > +#endif /* _EHCI_H_ */ > diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h > b/arch/arm/include/asm/arch-omap3/ehci_omap3.h deleted file mode 100644 > index cd01f50..0000000 > --- a/arch/arm/include/asm/arch-omap3/ehci_omap3.h > +++ /dev/null > @@ -1,58 +0,0 @@ > -/* > - * (C) Copyright 2011 > - * Alexander Holler <holler@ahsoftware.de> > - * > - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 > - * > - * See there for additional Copyrights. > - * > - * See file CREDITS for list of people who contributed to this > - * project. > - * > - * 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., 51 Franklin Street, Fifth Floor, Boston, > - * MA 02110-1301 USA > - */ > -#ifndef _EHCI_OMAP3_H_ > -#define _EHCI_OMAP3_H_ > - > -/* USB/EHCI registers */ > -#define OMAP3_USBTLL_BASE 0x48062000UL > -#define OMAP3_UHH_BASE 0x48064000UL > -#define OMAP3_EHCI_BASE 0x48064800UL > - > -/* TLL Register Set */ > -#define OMAP_USBTLL_SYSCONFIG (0x10) > -#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) > -#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) > -#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) > -#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) > - > -#define OMAP_USBTLL_SYSSTATUS (0x14) > -#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0) > - > -/* UHH Register Set */ > -#define OMAP_UHH_SYSCONFIG (0x10) > -#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) > -#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) > -#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) > -#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) > -#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) > - > -#define OMAP_UHH_HOSTCONFIG (0x40) > -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) > -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) > -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) > - > -#endif /* _EHCI_OMAP3_H_ */ > diff --git a/arch/arm/include/asm/arch-omap4/ehci.h > b/arch/arm/include/asm/arch-omap4/ehci.h new file mode 100644 > index 0000000..3af171b > --- /dev/null > +++ b/arch/arm/include/asm/arch-omap4/ehci.h > @@ -0,0 +1,49 @@ > +/* > + * OMAP EHCI port support > + * Based on LINUX KERNEL > + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c > + * > + * Copyright (C) 2011 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 version 2 of > + * the License as published by the Free Software Foundation. > + * > + * 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, see <http://www.gnu.org/licenses/>. > + */ > + > +#ifndef _EHCI_H > +#define _EHCI_H > + > +#define OMAP_EHCI_BASE (OMAP44XX_L4_CORE_BASE + 0x64C00) > +#define OMAP_UHH_BASE (OMAP44XX_L4_CORE_BASE + 0x64000) > +#define OMAP_USBTLL_BASE (OMAP44XX_L4_CORE_BASE + 0x62000) > + > +/* UHH, TLL and opt clocks */ > +#define CM_L3INIT_HSUSBHOST_CLKCTRL 0x4A009358UL > + > +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK (1 << 24) > + > +/* 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 new file mode 100644 > index 0000000..336d77e > --- /dev/null > +++ b/arch/arm/include/asm/ehci-omap.h > @@ -0,0 +1,147 @@ > +/* > + * OMAP EHCI port support > + * Based on LINUX KERNEL > + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c > + * > + * Copyright (C) 2011 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 version 2 of > + * the License as published by the Free Software Foundation. > + * > + * 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, see <http://www.gnu.org/licenses/>. > + */ > + > +#ifndef EHCI_H > +#define EHCI_H > + > +enum usbhs_omap_port_mode { > + OMAP_USBHS_PORT_MODE_UNUSED, > + OMAP_EHCI_PORT_MODE_PHY, > + OMAP_EHCI_PORT_MODE_TLL, > + OMAP_EHCI_PORT_MODE_HSIC, > +}; > + > +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS > +#define OMAP_HS_USB_PORTS CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS > +#else > +#define OMAP_HS_USB_PORTS 3 > +#endif > + > +#define is_ehci_phy_mode(x) (x == OMAP_EHCI_PORT_MODE_PHY) > +#define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL) > +#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC) This is unsafe ... use ((x) == ...) > + > +/* Values of UHH_REVISION - Note: these are not given in the TRM */ > +#define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ > +#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ > + > +/* UHH Register Set */ > +#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) > +#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) > +#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) > +#define OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN (1 << 5) > + > +#define OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS 1 > +#define OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS (1 << 11) > +#define OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS (1 << 12) > +#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 << 31) > + > +#define OMAP_P1_MODE_CLEAR (3 << 16) > +#define OMAP_P1_MODE_TLL (1 << 16) > +#define OMAP_P1_MODE_HSIC (3 << 16) > +#define OMAP_P2_MODE_CLEAR (3 << 18) > +#define OMAP_P2_MODE_TLL (1 << 18) > +#define OMAP_P2_MODE_HSIC (3 << 18) > + > +/* EHCI Register Set */ > +#define EHCI_INSNREG04_DISABLE_UNSUSPEND (1 << 5) > +#define EHCI_INSNREG05_ULPI_CONTROL_SHIFT 31 > +#define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT 24 > +#define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22 > +#define EHCI_INSNREG05_ULPI_REGADD_SHIFT 16 > + > +#define OMAP_REV1_TLL_CHANNEL_COUNT 3 > +#define OMAP_REV2_TLL_CHANNEL_COUNT 2 > + > +/* TLL Register Set */ > +#define OMAP_TLL_CHANNEL_CONF(num) (0x004 * num) > +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 << 16) > +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 << 15) > +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF (1 << 11) > +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI (2 << 1) > +#define OMAP_TLL_CHANNEL_CONF_CHANEN 1 > + > +/* ULPI */ > +#define ULPI_SET(a) (a + 1) > +#define ULPI_CLR(a) (a + 2) ULPI ... use generic stuff > +#define ULPI_FUNC_CTRL 0x04 > +#define ULPI_FUNC_CTRL_RESET (1 << 5) > + > +struct omap_usbhs_board_data { > + enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; > +}; > + > +struct omap_usbtll { > + u32 rev; /* 0x00 */ > + u32 hwinfo; /* 0x04 */ > + u8 pad1[0x8]; reserved1[] instead of pad1[], fix globally > + u32 sysc; /* 0x10 */ > + u32 syss; /* 0x14 */ > + u32 irqst; /* 0x18 */ > + u32 irqen; /* 0x1c */ > + u8 pad2[0x10]; > + u32 shared_conf; /* 0x30 */ > + u8 pad3[0xc]; > + u32 channel_conf; /* 0x40 */ > +}; > + > +struct omap_uhh { > + u32 rev; /* 0x00 */ > + u32 hwinfo; /* 0x04 */ > + u8 pad1[0x8]; > + u32 sysc; /* 0x10 */ > + u32 syss; /* 0x14 */ > + u8 pad2[0x28]; > + u32 hostconfig; /* 0x40 */ > + u32 debugcsr; /* 0x44 */ > +}; > + > +struct omap_ehci { > + u32 hccapbase; /* 0x00 */ > + u32 hcsparams; /* 0x04 */ > + u32 hccparams; /* 0x08 */ > + u8 pad1[0x04]; > + u32 usbcmd; /* 0x10 */ > + u32 usbsts; /* 0x14 */ > + u32 usbintr; /* 0x18 */ > + u32 frindex; /* 0x1c */ > + u32 ctrldssegment; /* 0x20 */ > + u32 periodiclistbase; /* 0x24 */ > + u32 asysnclistaddr; /* 0x28 */ > + u8 pad2[0x24]; > + u32 configflag; /* 0x50 */ > + u32 portsc_i; /* 0x54 */ > + u8 pad3[0x38]; > + u32 insreg00; /* 0x90 */ > + u32 insreg01; /* 0x94 */ > + u32 insreg02; /* 0x98 */ > + u32 insreg03; /* 0x9c */ > + u32 insreg04; /* 0xa0 */ > + u32 insreg05_utmi_ulpi; /* 0xa4 */ > + u32 insreg06; /* 0xa8 */ > + u32 insreg07; /* 0xac */ > + u32 insreg08; /* 0xb0 */ > +}; > + > +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata); > +int omap_ehci_hcd_stop(void); > + > +#endif /* EHCI_H */ > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index 93d3bb7..97c9fa3 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -27,14 +27,93 @@ > */ > #include <common.h> > #include <usb.h> > +#include <errno.h> > #include <asm/io.h> > #include <asm/gpio.h> > -#include <asm/arch/clocks.h> > -#include <asm/arch/clocks_omap3.h> > -#include <asm/arch/ehci_omap3.h> > -#include <asm/arch/sys_proto.h> > +#include <asm/arch/ehci.h> > +#include <asm/ehci-omap.h> > #include "ehci-core.h" > > +struct omap_uhh *const uhh = (struct omap_uhh *)OMAP_UHH_BASE; > +struct omap_usbtll *const usbtll = (struct omap_usbtll *)OMAP_USBTLL_BASE; > +struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE; static > + > +static int omap_uhh_reset(void) > +{ > + unsigned long init = get_timer(0); > + > + /* perform UHH soft reset, and wait until reset is complete */ > + writel(OMAP_UHH_SYSCONFIG_SOFTRESET, &uhh->sysc); > + > + /* Wait for UHH reset to complete */ > + while (!(readl(&uhh->syss) & OMAP_UHH_SYSSTATUS_EHCI_RESETDONE)) > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP UHH error: timeout resetting ehci\n"); > + return -EL3RST; > + } > + > + return 0; > +} > + > +static int omap_ehci_tll_reset(void) > +{ > + unsigned long init = get_timer(0); > + > + /* perform TLL soft reset, and wait until reset is complete */ > + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, &usbtll->sysc); > + > + /* Wait for TLL reset to complete */ > + while (!(readl(&usbtll->syss) & OMAP_USBTLL_SYSSTATUS_RESETDONE)) Add timeout, fix globally > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP EHCI error: timeout resetting TLL\n"); > + return -EL3RST; > + } > + > + return 0; > +} > + > +static void omap_usbhs_hsic_init(int tll_cnt) > +{ > + unsigned int reg; > + int i; > + > + /* Enable channels now */ > + for (i = 0; i < tll_cnt; i++) { > + reg = readl(&usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); > + > + reg |= OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI > + | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF > + | OMAP_TLL_CHANNEL_CONF_DRVVBUS > + | OMAP_TLL_CHANNEL_CONF_CHRGVBUS > + | OMAP_TLL_CHANNEL_CONF_CHANEN; > + > + writel(reg, &usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); > + } > +} > + > +static void omap_ehci_soft_phy_reset(int port) > +{ > + unsigned int reg = 0; > + unsigned long init = get_timer(0); > + > + /* FUNCTION_CTRL_SET register */ > + reg = ULPI_FUNC_CTRL_RESET | > + (ULPI_SET(ULPI_FUNC_CTRL) << EHCI_INSNREG05_ULPI_REGADD_SHIFT) | > + (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) | > + ((port + 1) << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) | > + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT); > + > + writel(reg, &ehci->insreg05_utmi_ulpi); > + > + /* Wait for ULPI access completion */ > + while ((readl(&ehci->insreg05_utmi_ulpi) & > + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP EHCI error: timeout resetting phy\n"); > + break; > + } > +} > + > inline int __board_usb_init(void) > { > return 0; > @@ -72,31 +151,31 @@ static inline void omap_ehci_phy_reset(int on, int > delay) #endif > > /* Reset is needed otherwise the kernel-driver will throw an error. */ > -int ehci_hcd_stop(void) > +int omap_ehci_hcd_stop(void) > { > - debug("Resetting OMAP3 EHCI\n"); > + debug("Resetting OMAP EHCI\n"); > omap_ehci_phy_reset(1, 0); > - writel(OMAP_UHH_SYSCONFIG_SOFTRESET, > - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); > - /* disable USB clocks */ > - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; > - sr32(&prcm_base->iclken_usbhost, 0, 1, 0); > - sr32(&prcm_base->fclken_usbhost, 0, 2, 0); > - sr32(&prcm_base->iclken3_core, 2, 1, 0); > - sr32(&prcm_base->fclken3_core, 2, 1, 0); > + > + if (omap_uhh_reset() < 0) > + return -1; > + > + if (omap_ehci_tll_reset() < 0) > + return -1; > + > return 0; > } > > /* > - * Initialize the OMAP3 EHCI controller and PHY. > - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. > + * Initialize the OMAP EHCI controller and PHY. > + * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 > * See there for additional Copyrights. > */ > -int ehci_hcd_init(void) > +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) > { > - int ret; > + int ret = 0; > + unsigned int i, reg = 0, rev = 0, tll_cnt = 0; > > - debug("Initializing OMAP3 EHCI\n"); > + debug("Initializing OMAP EHCI\n"); > > ret = board_usb_init(); > if (ret < 0) > @@ -105,52 +184,89 @@ int ehci_hcd_init(void) > /* Put the PHY in RESET */ > omap_ehci_phy_reset(1, 10); > > - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; > - /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ > - sr32(&prcm_base->iclken_usbhost, 0, 1, 1); > - /* > - * Enable USBHOST_48M_FCLK (USBHOST_FCLK1) > - * and USBHOST_120M_FCLK (USBHOST_FCLK2) > - */ > - sr32(&prcm_base->fclken_usbhost, 0, 2, 3); > - /* Enable USBTTL_ICLK */ > - sr32(&prcm_base->iclken3_core, 2, 1, 1); > - /* Enable USBTTL_FCLK */ > - sr32(&prcm_base->fclken3_core, 2, 1, 1); > - debug("USB clocks enabled\n"); > + ret = omap_uhh_reset(); > + if (ret < 0) > + return ret; > > - /* perform TLL soft reset, and wait until reset is complete */ > - writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, > - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); > - /* Wait for TLL reset to complete */ > - while (!(readl(OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSSTATUS) > - & OMAP_USBTLL_SYSSTATUS_RESETDONE)) > - ; > - debug("TLL reset done\n"); > + ret = omap_ehci_tll_reset(); > + if (ret) > + return ret; > > writel(OMAP_USBTLL_SYSCONFIG_ENAWAKEUP | > OMAP_USBTLL_SYSCONFIG_SIDLEMODE | > - OMAP_USBTLL_SYSCONFIG_CACTIVITY, > - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); > + OMAP_USBTLL_SYSCONFIG_CACTIVITY, &usbtll->sysc); > > /* Put UHH in NoIdle/NoStandby mode */ > - writel(OMAP_UHH_SYSCONFIG_ENAWAKEUP > - | OMAP_UHH_SYSCONFIG_SIDLEMODE > - | OMAP_UHH_SYSCONFIG_CACTIVITY > - | OMAP_UHH_SYSCONFIG_MIDLEMODE, > - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); > - > - /* setup burst configurations */ > - writel(OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN > - | OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN > - | OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN, > - OMAP3_UHH_BASE + OMAP_UHH_HOSTCONFIG); > + writel(OMAP_UHH_SYSCONFIG_VAL, &uhh->sysc); > + > + /* setup ULPI bypass and burst configurations */ > + reg |= (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN | > + OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN | > + OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN); > + reg &= ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN; clrsetbits_le32 ? > + > + rev = readl(&uhh->rev); > + if (rev == OMAP_USBHS_REV1) { > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[0])) > + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS; > + else > + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS; > + > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[1])) > + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS; > + else > + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS; > + > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[2])) > + reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS; > + else > + reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS; > + > + tll_cnt = OMAP_REV1_TLL_CHANNEL_COUNT; > + } else if (rev == OMAP_USBHS_REV2) { > + > + reg |= OMAP4_UHH_HOSTCONFIG_APP_START_CLK; > + /* Clear port mode fields for PHY mode*/ > + reg &= ~OMAP_P1_MODE_CLEAR; > + reg &= ~OMAP_P2_MODE_CLEAR; > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0])) > + reg |= OMAP_P1_MODE_HSIC; > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) > + reg |= OMAP_P2_MODE_HSIC; > + > + tll_cnt = OMAP_REV2_TLL_CHANNEL_COUNT; > + } > + > + debug("OMAP UHH_REVISION 0x%x\n", rev); > + writel(reg, &uhh->hostconfig); > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0]) || > + is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) > + omap_usbhs_hsic_init(tll_cnt); > > omap_ehci_phy_reset(0, 10); > > - hccr = (struct ehci_hccr *)(OMAP3_EHCI_BASE); > - hcor = (struct ehci_hcor *)(OMAP3_EHCI_BASE + 0x10); > + /* > + * An undocumented "feature" in the OMAP3 EHCI controller, > + * causes suspended ports to be taken out of suspend when > + * the USBCMD.Run/Stop bit is cleared (for example when > + * we do ehci_bus_suspend). > + * This breaks suspend-resume if the root-hub is allowed > + * to suspend. Writing 1 to this undocumented register bit > + * disables this feature and restores normal behavior. > + */ > + writel(EHCI_INSNREG04_DISABLE_UNSUSPEND, &ehci->insreg04); > + > + for (i = 0; i < OMAP_HS_USB_PORTS; i++) > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) > + omap_ehci_soft_phy_reset(i); > + > + dcache_disable(); > + hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); > + hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); > > - debug("OMAP3 EHCI init done\n"); > + debug("OMAP EHCI init done\n"); > return 0; > } M ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-10 16:07 ` Marek Vasut @ 2012-01-11 6:07 ` Govindraj 2012-01-11 10:52 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-11 6:07 UTC (permalink / raw) To: u-boot Hi Marek, Thanks for you review. On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> Clean up added ehci-omap.c and make it generic for re-use across >> soc having same ehci ip block. Also pass the modes to be configured >> and configure the ports accordingly. All usb layers are not cache >> aligned till then keep cache off for usb ops as ehci will use >> internally dma for all usb ops. >> >> * Add a generic common header ehci-omap.h having common ip block >> ? data and reg shifts. >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >> ? sysc reg shifts remove others and move to common header file. > > Don't reimplement the ulpi stuff ... there's already some ulpi stuff in uboot > that needs fixing, so fix it and use it. > I am not implementing any ulpi stuff I am just configuring OMAP on soc usb host controller (ehci). All the configuration stuff is OMAP specific things which are done in ehci-omap.c file stuffs done are like soft-reset, port mode to be used and putting port in no -idle mode(omap specific pm implementation) etc. >> >> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> >> --- >> ?arch/arm/include/asm/arch-omap3/ehci.h ? ? ? | ? 55 ++++++ >> ?arch/arm/include/asm/arch-omap3/ehci_omap3.h | ? 58 ------- >> ?arch/arm/include/asm/arch-omap4/ehci.h ? ? ? | ? 49 ++++++ >> ?arch/arm/include/asm/ehci-omap.h ? ? ? ? ? ? | ?147 +++++++++++++++++ >> ?drivers/usb/host/ehci-omap.c ? ? ? ? ? ? ? ? | ?228 [...] >> + >> +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >> +#define OMAP_HS_USB_PORTS ? ?CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >> +#else >> +#define OMAP_HS_USB_PORTS ? ?3 >> +#endif >> + >> +#define is_ehci_phy_mode(x) ?(x == OMAP_EHCI_PORT_MODE_PHY) >> +#define is_ehci_tll_mode(x) ?(x == OMAP_EHCI_PORT_MODE_TLL) >> +#define is_ehci_hsic_mode(x) (x == OMAP_EHCI_PORT_MODE_HSIC) > > This is unsafe ... use ((x) == ...) Okay, will correct this. > >> + >> +/* Values of UHH_REVISION - Note: these are not given in the TRM */ >> +#define OMAP_USBHS_REV1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00000010 /* > OMAP3 */ >> +#define OMAP_USBHS_REV2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x50700100 /* > OMAP4 */ >> + [...] >> +/* ULPI */ >> +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >> +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) > > ULPI ... use generic stuff Actually this for omap specific configuration done with omap reg map. EHCI register INSNREG05_ULPI needs to be configured if we are in ulpi-phy mode same is done here. > >> +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >> +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >> + >> +struct omap_usbhs_board_data { >> + ? ? enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; >> +}; >> + >> +struct omap_usbtll { >> + ? ? u32 rev; ? ? ? ? ? ? ? ?/* 0x00 */ >> + ? ? u32 hwinfo; ? ? ? ? ? ? /* 0x04 */ >> + ? ? u8 pad1[0x8]; > > reserved1[] instead of pad1[], fix globally yes fine, will correct this. [..] >> >> +struct omap_uhh *const uhh = (struct omap_uhh *)OMAP_UHH_BASE; >> +struct omap_usbtll *const usbtll = (struct omap_usbtll *)OMAP_USBTLL_BASE; >> +struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE; > > static > yes correct, will change this. >> + >> +static int omap_uhh_reset(void) >> +{ [...] >> + ? ? /* perform TLL soft reset, and wait until reset is complete */ >> + ? ? writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, &usbtll->sysc); >> + >> + ? ? /* Wait for TLL reset to complete */ >> + ? ? while (!(readl(&usbtll->syss) & OMAP_USBTLL_SYSSTATUS_RESETDONE)) > > Add timeout, fix globally Sorry I didn't get you here. The function uses a timeout value init and then same init value to used to poll for CONFIG_SYS_HZ time for reset to be done else prints timeout failure. >> + ? ? ? ? ? ? if (get_timer(init) > CONFIG_SYS_HZ) { >> + ? ? ? ? ? ? ? ? ? ? debug("OMAP EHCI error: timeout resetting TLL\n"); >> + ? ? ? ? ? ? ? ? ? ? return -EL3RST; >> + ? ? } >> + [...] >> + ? ? /* setup ULPI bypass and burst configurations */ >> + ? ? reg |= (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN | >> + ? ? ? ? ? ? OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN | >> + ? ? ? ? ? ? OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN); >> + ? ? reg &= ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN; > > clrsetbits_le32 ? yes can be used. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 6:07 ` Govindraj @ 2012-01-11 10:52 ` Marek Vasut 2012-01-11 11:32 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-01-11 10:52 UTC (permalink / raw) To: u-boot > Hi Marek, > > Thanks for you review. > > On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> > >> Clean up added ehci-omap.c and make it generic for re-use across > >> soc having same ehci ip block. Also pass the modes to be configured > >> and configure the ports accordingly. All usb layers are not cache > >> aligned till then keep cache off for usb ops as ehci will use > >> internally dma for all usb ops. > >> > >> * Add a generic common header ehci-omap.h having common ip block > >> data and reg shifts. > >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting > >> sysc reg shifts remove others and move to common header file. > > > > Don't reimplement the ulpi stuff ... there's already some ulpi stuff in > > uboot that needs fixing, so fix it and use it. > > I am not implementing any ulpi stuff I am just configuring OMAP on > soc usb host controller (ehci). All the configuration stuff > is OMAP specific things which are done in ehci-omap.c file > > stuffs done are like soft-reset, port mode to be used and putting > port in no -idle mode(omap specific pm implementation) etc. > This stuff: +/* ULPI */ +#define ULPI_SET(a) (a + 1) +#define ULPI_CLR(a) (a + 2) +#define ULPI_FUNC_CTRL 0x04 +#define ULPI_FUNC_CTRL_RESET (1 << 5) is just accidentally conforming to ULPI spec? M btw. somewhere in the patch is one more asterisk@the end of line: + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com* [...] > >> + /* perform TLL soft reset, and wait until reset is complete */ > >> + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, &usbtll->sysc); > >> + > >> + /* Wait for TLL reset to complete */ > >> + while (!(readl(&usbtll->syss) & OMAP_USBTLL_SYSSTATUS_RESETDONE)) > > > > Add timeout, fix globally > > Sorry I didn't get you here. > > The function uses a timeout value init and then same init > value to used to poll for CONFIG_SYS_HZ time for reset to be > done else prints timeout failure. Ah sorry, I didn't notice. OK. > > >> + if (get_timer(init) > CONFIG_SYS_HZ) { > >> + debug("OMAP EHCI error: timeout resetting TLL\n"); > >> + return -EL3RST; > >> + } > >> + > > [...] > > >> + /* setup ULPI bypass and burst configurations */ > >> + reg |= (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN | > >> + OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN | > >> + OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN); > >> + reg &= ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN; > > > > clrsetbits_le32 ? > > yes can be used. Use where applicable > > -- > Thanks, > Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 10:52 ` Marek Vasut @ 2012-01-11 11:32 ` Govindraj 2012-01-11 12:46 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-11 11:32 UTC (permalink / raw) To: u-boot On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> Hi Marek, >> >> Thanks for you review. >> >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> >> >> Clean up added ehci-omap.c and make it generic for re-use across >> >> soc having same ehci ip block. Also pass the modes to be configured >> >> and configure the ports accordingly. All usb layers are not cache >> >> aligned till then keep cache off for usb ops as ehci will use >> >> internally dma for all usb ops. >> >> >> >> * Add a generic common header ehci-omap.h having common ip block >> >> ? data and reg shifts. >> >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >> >> ? sysc reg shifts remove others and move to common header file. >> > >> > Don't reimplement the ulpi stuff ... there's already some ulpi stuff in >> > uboot that needs fixing, so fix it and use it. >> >> I am not implementing any ulpi stuff I am just configuring OMAP on >> soc usb host controller (ehci). All the configuration stuff >> is OMAP specific things which are done in ehci-omap.c file >> >> stuffs done are like soft-reset, port mode to be used and putting >> port in no -idle mode(omap specific pm implementation) etc. >> > > This stuff: > > +/* ULPI */ > +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) > +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) > +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 > +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) > > is just accidentally conforming to ULPI spec? > These are for configuring INSNREG05_ULPI reg in EHCI reg map of omap while configuring in ulpi-phy mode. looking into struct ulpi_regs {..} then it doesn't map this configuration. btw, IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy chip for communication. > M > > btw. somewhere in the patch is one more asterisk at the end of line: Will check that -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 11:32 ` Govindraj @ 2012-01-11 12:46 ` Marek Vasut 2012-01-11 13:00 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-01-11 12:46 UTC (permalink / raw) To: u-boot > On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> Hi Marek, > >> > >> Thanks for you review. > >> > >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> >> > >> >> Clean up added ehci-omap.c and make it generic for re-use across > >> >> soc having same ehci ip block. Also pass the modes to be configured > >> >> and configure the ports accordingly. All usb layers are not cache > >> >> aligned till then keep cache off for usb ops as ehci will use > >> >> internally dma for all usb ops. > >> >> > >> >> * Add a generic common header ehci-omap.h having common ip block > >> >> data and reg shifts. > >> >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting > >> >> sysc reg shifts remove others and move to common header file. > >> > > >> > Don't reimplement the ulpi stuff ... there's already some ulpi stuff > >> > in uboot that needs fixing, so fix it and use it. > >> > >> I am not implementing any ulpi stuff I am just configuring OMAP on > >> soc usb host controller (ehci). All the configuration stuff > >> is OMAP specific things which are done in ehci-omap.c file > >> > >> stuffs done are like soft-reset, port mode to be used and putting > >> port in no -idle mode(omap specific pm implementation) etc. > > > > This stuff: > > > > +/* ULPI */ > > +#define ULPI_SET(a) (a + 1) > > +#define ULPI_CLR(a) (a + 2) > > +#define ULPI_FUNC_CTRL 0x04 > > +#define ULPI_FUNC_CTRL_RESET (1 << 5) > > > > is just accidentally conforming to ULPI spec? > > These are for configuring INSNREG05_ULPI reg in EHCI reg map > of omap while configuring in ulpi-phy mode. > > looking into struct ulpi_regs {..} > then it doesn't map this configuration. Can you point me to some documentation about this please? It's not that I don't trust you, I'd rather prefer to avoid unnecessary duplication. > > btw, > IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy chip > for communication. > > > M > > > btw. somewhere in the patch is one more asterisk at the end of line: > Will check that It was on the line I pointed out > > -- > Thanks, > Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 12:46 ` Marek Vasut @ 2012-01-11 13:00 ` Govindraj 2012-01-11 13:28 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-11 13:00 UTC (permalink / raw) To: u-boot On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> >> Hi Marek, >> >> >> >> Thanks for you review. >> >> >> >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> >> >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> >> >> >> >> Clean up added ehci-omap.c and make it generic for re-use across >> >> >> soc having same ehci ip block. Also pass the modes to be configured >> >> >> and configure the ports accordingly. All usb layers are not cache >> >> >> aligned till then keep cache off for usb ops as ehci will use >> >> >> internally dma for all usb ops. >> >> >> >> >> >> * Add a generic common header ehci-omap.h having common ip block >> >> >> ? data and reg shifts. >> >> >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >> >> >> ? sysc reg shifts remove others and move to common header file. >> >> > >> >> > Don't reimplement the ulpi stuff ... there's already some ulpi stuff >> >> > in uboot that needs fixing, so fix it and use it. >> >> >> >> I am not implementing any ulpi stuff I am just configuring OMAP on >> >> soc usb host controller (ehci). All the configuration stuff >> >> is OMAP specific things which are done in ehci-omap.c file >> >> >> >> stuffs done are like soft-reset, port mode to be used and putting >> >> port in no -idle mode(omap specific pm implementation) etc. >> > >> > This stuff: >> > >> > +/* ULPI */ >> > +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >> > +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) >> > +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >> > +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >> > >> > is just accidentally conforming to ULPI spec? >> >> These are for configuring INSNREG05_ULPI reg in EHCI reg map >> of omap while configuring in ulpi-phy mode. >> >> looking into struct ulpi_regs {..} >> then it doesn't map this configuration. > > Can you point me to some documentation about this please? It's not that I don't > trust you, I'd rather prefer to avoid unnecessary duplication. > Yes that would be fine. You can download the omap4460 public trm from here: http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip Go to chapter 23.11.6.6.1 EHCI Register Summary (page number 5171 and 5186/87) click INSNREG05_ULPI this for configuring in ulpi mode for external ulpi phy. reference chapter 23.11.4.1 refer to Figure 23-252. HS USB Host Controller Architecture (page number 5096) >> >> btw, >> IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy chip >> for communication. >> >> > M >> >> > btw. somewhere in the patch is one more asterisk at the end of line: >> Will check that > > It was on the line I pointed out okay, got it. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 13:00 ` Govindraj @ 2012-01-11 13:28 ` Marek Vasut 2012-01-11 14:13 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-01-11 13:28 UTC (permalink / raw) To: u-boot > On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> >> Hi Marek, > >> >> > >> >> Thanks for you review. > >> >> > >> >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> >> >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> >> >> > >> >> >> Clean up added ehci-omap.c and make it generic for re-use across > >> >> >> soc having same ehci ip block. Also pass the modes to be > >> >> >> configured and configure the ports accordingly. All usb layers > >> >> >> are not cache aligned till then keep cache off for usb ops as > >> >> >> ehci will use internally dma for all usb ops. > >> >> >> > >> >> >> * Add a generic common header ehci-omap.h having common ip block > >> >> >> data and reg shifts. > >> >> >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting > >> >> >> sysc reg shifts remove others and move to common header file. > >> >> > > >> >> > Don't reimplement the ulpi stuff ... there's already some ulpi > >> >> > stuff in uboot that needs fixing, so fix it and use it. > >> >> > >> >> I am not implementing any ulpi stuff I am just configuring OMAP on > >> >> soc usb host controller (ehci). All the configuration stuff > >> >> is OMAP specific things which are done in ehci-omap.c file > >> >> > >> >> stuffs done are like soft-reset, port mode to be used and putting > >> >> port in no -idle mode(omap specific pm implementation) etc. > >> > > >> > This stuff: > >> > > >> > +/* ULPI */ > >> > +#define ULPI_SET(a) (a + 1) > >> > +#define ULPI_CLR(a) (a + 2) > >> > +#define ULPI_FUNC_CTRL 0x04 > >> > +#define ULPI_FUNC_CTRL_RESET (1 << 5) > >> > > >> > is just accidentally conforming to ULPI spec? > >> > >> These are for configuring INSNREG05_ULPI reg in EHCI reg map > >> of omap while configuring in ulpi-phy mode. > >> > >> looking into struct ulpi_regs {..} > >> then it doesn't map this configuration. > > > > Can you point me to some documentation about this please? It's not that I > > don't trust you, I'd rather prefer to avoid unnecessary duplication. > > Yes that would be fine. > > You can download the omap4460 public trm from here: > > http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip > > Go to chapter 23.11.6.6.1 EHCI Register Summary > (page number 5171 and 5186/87) Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for that purpose, the struct ulpi_regs is fitting ok. Actually ... can you check the ulpi_read and ulpi_write stuff that's already in u-boot and explain why they can not be used with this port? M > > click INSNREG05_ULPI > > this for configuring in ulpi mode for external ulpi phy. > reference > chapter 23.11.4.1 refer to Figure 23-252. HS USB Host Controller > Architecture (page number 5096) > > >> btw, > >> IIUC that ulpi_regs struct is for otg transceiver that uses a ulpi phy > >> chip for communication. > >> > >> > M > >> > >> > btw. somewhere in the patch is one more asterisk at the end of line: > >> Will check that > > > > It was on the line I pointed out > > okay, got it. > > -- > Thanks, > Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 13:28 ` Marek Vasut @ 2012-01-11 14:13 ` Govindraj 2012-01-11 14:34 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-11 14:13 UTC (permalink / raw) To: u-boot On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> >> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> >> >> Hi Marek, >> >> >> >> >> >> Thanks for you review. >> >> >> >> >> >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut <marek.vasut@gmail.com> > wrote: >> >> >> >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> >> >> >> >> >> >> Clean up added ehci-omap.c and make it generic for re-use across >> >> >> >> soc having same ehci ip block. Also pass the modes to be >> >> >> >> configured and configure the ports accordingly. All usb layers >> >> >> >> are not cache aligned till then keep cache off for usb ops as >> >> >> >> ehci will use internally dma for all usb ops. >> >> >> >> >> >> >> >> * Add a generic common header ehci-omap.h having common ip block >> >> >> >> ? data and reg shifts. >> >> >> >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >> >> >> >> ? sysc reg shifts remove others and move to common header file. >> >> >> > >> >> >> > Don't reimplement the ulpi stuff ... there's already some ulpi >> >> >> > stuff in uboot that needs fixing, so fix it and use it. >> >> >> >> >> >> I am not implementing any ulpi stuff I am just configuring OMAP on >> >> >> soc usb host controller (ehci). All the configuration stuff >> >> >> is OMAP specific things which are done in ehci-omap.c file >> >> >> >> >> >> stuffs done are like soft-reset, port mode to be used and putting >> >> >> port in no -idle mode(omap specific pm implementation) etc. >> >> > >> >> > This stuff: >> >> > >> >> > +/* ULPI */ >> >> > +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >> >> > +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) >> >> > +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >> >> > +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >> >> > >> >> > is just accidentally conforming to ULPI spec? >> >> >> >> These are for configuring INSNREG05_ULPI reg in EHCI reg map >> >> of omap while configuring in ulpi-phy mode. >> >> >> >> looking into struct ulpi_regs {..} >> >> then it doesn't map this configuration. >> > >> > Can you point me to some documentation about this please? It's not that I >> > don't trust you, I'd rather prefer to avoid unnecessary duplication. >> >> Yes that would be fine. >> >> You can download the omap4460 public trm from here: >> >> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >> >> Go to chapter 23.11.6.6.1 EHCI Register Summary >> (page number 5171 and 5186/87) > > Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for that > purpose, the struct ulpi_regs is fitting ok. > > Actually ... can you check the ulpi_read and ulpi_write stuff that's already in > u-boot and explain why they can not be used with this port? > echi-omap.c is no where writing to those registers and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map reg map in 23.11.6.3 used only for a external ulpi-phy communication. and debug purpose(to view vid, pid etc) and to hack external phy configuration through ulpi commands from omap - usb host controller point of view only needs INSNREG05_ULPI reg in EHCI reg configuration rest on soc host controller takes care of it. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 14:13 ` Govindraj @ 2012-01-11 14:34 ` Marek Vasut 2012-01-11 15:03 ` Igor Grinberg 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-01-11 14:34 UTC (permalink / raw) To: u-boot > On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> >> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> >> >> Hi Marek, > >> >> >> > >> >> >> Thanks for you review. > >> >> >> > >> >> >> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut > >> >> >> <marek.vasut@gmail.com> > > > > wrote: > >> >> >> >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> >> >> >> > >> >> >> >> Clean up added ehci-omap.c and make it generic for re-use > >> >> >> >> across soc having same ehci ip block. Also pass the modes to > >> >> >> >> be configured and configure the ports accordingly. All usb > >> >> >> >> layers are not cache aligned till then keep cache off for usb > >> >> >> >> ops as ehci will use internally dma for all usb ops. > >> >> >> >> > >> >> >> >> * Add a generic common header ehci-omap.h having common ip > >> >> >> >> block data and reg shifts. > >> >> >> >> * Rename and modify ehci-omap3 to ehci.h retain only > >> >> >> >> conflicting sysc reg shifts remove others and move to common > >> >> >> >> header file. > >> >> >> > > >> >> >> > Don't reimplement the ulpi stuff ... there's already some ulpi > >> >> >> > stuff in uboot that needs fixing, so fix it and use it. > >> >> >> > >> >> >> I am not implementing any ulpi stuff I am just configuring OMAP on > >> >> >> soc usb host controller (ehci). All the configuration stuff > >> >> >> is OMAP specific things which are done in ehci-omap.c file > >> >> >> > >> >> >> stuffs done are like soft-reset, port mode to be used and putting > >> >> >> port in no -idle mode(omap specific pm implementation) etc. > >> >> > > >> >> > This stuff: > >> >> > > >> >> > +/* ULPI */ > >> >> > +#define ULPI_SET(a) (a + 1) > >> >> > +#define ULPI_CLR(a) (a + 2) > >> >> > +#define ULPI_FUNC_CTRL 0x04 > >> >> > +#define ULPI_FUNC_CTRL_RESET (1 << 5) > >> >> > > >> >> > is just accidentally conforming to ULPI spec? > >> >> > >> >> These are for configuring INSNREG05_ULPI reg in EHCI reg map > >> >> of omap while configuring in ulpi-phy mode. > >> >> > >> >> looking into struct ulpi_regs {..} > >> >> then it doesn't map this configuration. > >> > > >> > Can you point me to some documentation about this please? It's not > >> > that I don't trust you, I'd rather prefer to avoid unnecessary > >> > duplication. > >> > >> Yes that would be fine. > >> > >> You can download the omap4460 public trm from here: > >> > >> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip > >> > >> Go to chapter 23.11.6.6.1 EHCI Register Summary > >> (page number 5171 and 5186/87) > > > > Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for > > that purpose, the struct ulpi_regs is fitting ok. > > > > Actually ... can you check the ulpi_read and ulpi_write stuff that's > > already in u-boot and explain why they can not be used with this port? > > echi-omap.c is no where writing to those registers > and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map > > reg map in 23.11.6.3 used only for a external ulpi-phy communication. > and debug purpose(to view vid, pid etc) and to hack external phy > configuration through ulpi commands > from omap - usb host controller point of view only needs > INSNREG05_ULPI reg in EHCI reg configuration > rest on soc host controller takes care of it. Can someone else comment on this? I think I don't understand well (as I'm not OMAP guy). M > > -- > Thanks, > Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 14:34 ` Marek Vasut @ 2012-01-11 15:03 ` Igor Grinberg 2012-01-11 18:50 ` Marek Vasut 2012-01-12 5:45 ` Govindraj 0 siblings, 2 replies; 40+ messages in thread From: Igor Grinberg @ 2012-01-11 15:03 UTC (permalink / raw) To: u-boot Hi Guys, On 01/11/12 16:34, Marek Vasut wrote: >> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> > wrote: >>>>>>>> Hi Marek, >>>>>>>> >>>>>>>> Thanks for you review. >>>>>>>> >>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>> <marek.vasut@gmail.com> >>> >>> wrote: >>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>> >>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>> >>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>> block data and reg shifts. >>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>> header file. >>>>>>>>> >>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. >>>>>>>> >>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>> is OMAP specific things which are done in ehci-omap.c file >>>>>>>> >>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>> port in no -idle mode(omap specific pm implementation) etc. >>>>>>> >>>>>>> This stuff: >>>>>>> >>>>>>> +/* ULPI */ >>>>>>> +#define ULPI_SET(a) (a + 1) >>>>>>> +#define ULPI_CLR(a) (a + 2) >>>>>>> +#define ULPI_FUNC_CTRL 0x04 >>>>>>> +#define ULPI_FUNC_CTRL_RESET (1 << 5) >>>>>>> >>>>>>> is just accidentally conforming to ULPI spec? >>>>>> >>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>> of omap while configuring in ulpi-phy mode. >>>>>> >>>>>> looking into struct ulpi_regs {..} >>>>>> then it doesn't map this configuration. >>>>> >>>>> Can you point me to some documentation about this please? It's not >>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>> duplication. >>>> >>>> Yes that would be fine. >>>> >>>> You can download the omap4460 public trm from here: >>>> >>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>> >>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>> (page number 5171 and 5186/87) >>> >>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>> that purpose, the struct ulpi_regs is fitting ok. >>> >>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>> already in u-boot and explain why they can not be used with this port? >> >> echi-omap.c is no where writing to those registers >> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map >> >> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >> and debug purpose(to view vid, pid etc) and to hack external phy >> configuration through ulpi commands >> from omap - usb host controller point of view only needs >> INSNREG05_ULPI reg in EHCI reg configuration >> rest on soc host controller takes care of it. > > Can someone else comment on this? I think I don't understand well (as I'm not > OMAP guy). Well, it is on my list, actually, but I will be able to get to it only in a couple of days. (I'm really busy right now). -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 15:03 ` Igor Grinberg @ 2012-01-11 18:50 ` Marek Vasut 2012-01-12 5:45 ` Govindraj 1 sibling, 0 replies; 40+ messages in thread From: Marek Vasut @ 2012-01-11 18:50 UTC (permalink / raw) To: u-boot > Hi Guys, > > On 01/11/12 16:34, Marek Vasut wrote: > >> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: > >>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> > > > > wrote: > >>>>>>>> Hi Marek, > >>>>>>>> > >>>>>>>> Thanks for you review. > >>>>>>>> > >>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut > >>>>>>>> <marek.vasut@gmail.com> > >>> > >>> wrote: > >>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> > >>>>>>>>>> > >>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use > >>>>>>>>>> across soc having same ehci ip block. Also pass the modes to > >>>>>>>>>> be configured and configure the ports accordingly. All usb > >>>>>>>>>> layers are not cache aligned till then keep cache off for usb > >>>>>>>>>> ops as ehci will use internally dma for all usb ops. > >>>>>>>>>> > >>>>>>>>>> * Add a generic common header ehci-omap.h having common ip > >>>>>>>>>> block data and reg shifts. > >>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only > >>>>>>>>>> conflicting sysc reg shifts remove others and move to common > >>>>>>>>>> header file. > >>>>>>>>> > >>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi > >>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. > >>>>>>>> > >>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on > >>>>>>>> soc usb host controller (ehci). All the configuration stuff > >>>>>>>> is OMAP specific things which are done in ehci-omap.c file > >>>>>>>> > >>>>>>>> stuffs done are like soft-reset, port mode to be used and putting > >>>>>>>> port in no -idle mode(omap specific pm implementation) etc. > >>>>>>> > >>>>>>> This stuff: > >>>>>>> > >>>>>>> +/* ULPI */ > >>>>>>> +#define ULPI_SET(a) (a + 1) > >>>>>>> +#define ULPI_CLR(a) (a + 2) > >>>>>>> +#define ULPI_FUNC_CTRL 0x04 > >>>>>>> +#define ULPI_FUNC_CTRL_RESET (1 << 5) > >>>>>>> > >>>>>>> is just accidentally conforming to ULPI spec? > >>>>>> > >>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map > >>>>>> of omap while configuring in ulpi-phy mode. > >>>>>> > >>>>>> looking into struct ulpi_regs {..} > >>>>>> then it doesn't map this configuration. > >>>>> > >>>>> Can you point me to some documentation about this please? It's not > >>>>> that I don't trust you, I'd rather prefer to avoid unnecessary > >>>>> duplication. > >>>> > >>>> Yes that would be fine. > >>>> > >>>> You can download the omap4460 public trm from here: > >>>> > >>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip > >>>> > >>>> Go to chapter 23.11.6.6.1 EHCI Register Summary > >>>> (page number 5171 and 5186/87) > >>> > >>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And > >>> for that purpose, the struct ulpi_regs is fitting ok. > >>> > >>> Actually ... can you check the ulpi_read and ulpi_write stuff that's > >>> already in u-boot and explain why they can not be used with this port? > >> > >> echi-omap.c is no where writing to those registers > >> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg > >> map > >> > >> reg map in 23.11.6.3 used only for a external ulpi-phy communication. > >> and debug purpose(to view vid, pid etc) and to hack external phy > >> configuration through ulpi commands > >> from omap - usb host controller point of view only needs > >> INSNREG05_ULPI reg in EHCI reg configuration > >> rest on soc host controller takes care of it. > > > > Can someone else comment on this? I think I don't understand well (as I'm > > not OMAP guy). > > Well, it is on my list, actually, > but I will be able to get to it only in a couple of days. > (I'm really busy right now). Good, please keep me updated, Igor. Thank you ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-11 15:03 ` Igor Grinberg 2012-01-11 18:50 ` Marek Vasut @ 2012-01-12 5:45 ` Govindraj 2012-01-12 9:23 ` Igor Grinberg 1 sibling, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-12 5:45 UTC (permalink / raw) To: u-boot Hi Igor, On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Guys, > > On 01/11/12 16:34, Marek Vasut wrote: >>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> >> wrote: >>>>>>>>> Hi Marek, >>>>>>>>> >>>>>>>>> Thanks for you review. >>>>>>>>> >>>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>>> <marek.vasut@gmail.com> >>>> >>>> wrote: >>>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>>> >>>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>>> >>>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>>> block data and reg shifts. >>>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>>> header file. >>>>>>>>>> >>>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. >>>>>>>>> >>>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>>> is OMAP specific things which are done in ehci-omap.c file >>>>>>>>> >>>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>>> port in no -idle mode(omap specific pm implementation) etc. >>>>>>>> >>>>>>>> This stuff: >>>>>>>> >>>>>>>> +/* ULPI */ >>>>>>>> +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >>>>>>>> +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) >>>>>>>> +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >>>>>>>> +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >>>>>>>> >>>>>>>> is just accidentally conforming to ULPI spec? >>>>>>> >>>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>>> of omap while configuring in ulpi-phy mode. >>>>>>> >>>>>>> looking into struct ulpi_regs {..} >>>>>>> then it doesn't map this configuration. >>>>>> >>>>>> Can you point me to some documentation about this please? It's not >>>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>>> duplication. >>>>> >>>>> Yes that would be fine. >>>>> >>>>> You can download the omap4460 public trm from here: >>>>> >>>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>>> >>>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>>> (page number 5171 and 5186/87) >>>> >>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>>> that purpose, the struct ulpi_regs is fitting ok. >>>> >>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>>> already in u-boot and explain why they can not be used with this port? >>> >>> echi-omap.c is no where writing to those registers >>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map >>> >>> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >>> and debug purpose(to view vid, pid etc) and to hack external phy >>> configuration through ulpi commands >>> from omap - usb host controller point of view only needs >>> INSNREG05_ULPI reg in EHCI reg configuration >>> rest on soc host controller takes care of it. >> >> Can someone else comment on this? I think I don't understand well (as I'm not >> OMAP guy). > > Well, it is on my list, actually, > but I will be able to get to it only in a couple of days. > (I'm really busy right now). > Could you please let me know what exactly that you will be updating? So that I can accordingly post my v3 of this patch fixing comments from Marek Vasut <marek.vasut@gmail.com> -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-12 5:45 ` Govindraj @ 2012-01-12 9:23 ` Igor Grinberg 2012-01-12 10:52 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Igor Grinberg @ 2012-01-12 9:23 UTC (permalink / raw) To: u-boot Hi Govindraj, On 01/12/12 07:45, Govindraj wrote: > Hi Igor, > > On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> Hi Guys, >> >> On 01/11/12 16:34, Marek Vasut wrote: >>>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> >>> wrote: >>>>>>>>>> Hi Marek, >>>>>>>>>> >>>>>>>>>> Thanks for you review. >>>>>>>>>> >>>>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>>>> <marek.vasut@gmail.com> >>>>> >>>>> wrote: >>>>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>>>> >>>>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>>>> >>>>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>>>> block data and reg shifts. >>>>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>>>> header file. >>>>>>>>>>> >>>>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. >>>>>>>>>> >>>>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>>>> is OMAP specific things which are done in ehci-omap.c file >>>>>>>>>> >>>>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>>>> port in no -idle mode(omap specific pm implementation) etc. >>>>>>>>> >>>>>>>>> This stuff: >>>>>>>>> >>>>>>>>> +/* ULPI */ >>>>>>>>> +#define ULPI_SET(a) (a + 1) >>>>>>>>> +#define ULPI_CLR(a) (a + 2) >>>>>>>>> +#define ULPI_FUNC_CTRL 0x04 >>>>>>>>> +#define ULPI_FUNC_CTRL_RESET (1 << 5) >>>>>>>>> >>>>>>>>> is just accidentally conforming to ULPI spec? >>>>>>>> >>>>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>>>> of omap while configuring in ulpi-phy mode. >>>>>>>> >>>>>>>> looking into struct ulpi_regs {..} >>>>>>>> then it doesn't map this configuration. >>>>>>> >>>>>>> Can you point me to some documentation about this please? It's not >>>>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>>>> duplication. >>>>>> >>>>>> Yes that would be fine. >>>>>> >>>>>> You can download the omap4460 public trm from here: >>>>>> >>>>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>>>> >>>>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>>>> (page number 5171 and 5186/87) >>>>> >>>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>>>> that purpose, the struct ulpi_regs is fitting ok. >>>>> >>>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>>>> already in u-boot and explain why they can not be used with this port? >>>> >>>> echi-omap.c is no where writing to those registers >>>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map >>>> >>>> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >>>> and debug purpose(to view vid, pid etc) and to hack external phy >>>> configuration through ulpi commands >>>> from omap - usb host controller point of view only needs >>>> INSNREG05_ULPI reg in EHCI reg configuration >>>> rest on soc host controller takes care of it. >>> >>> Can someone else comment on this? I think I don't understand well (as I'm not >>> OMAP guy). >> >> Well, it is on my list, actually, >> but I will be able to get to it only in a couple of days. >> (I'm really busy right now). >> > > Could you please let me know what exactly that you will be > updating? > > So that I can accordingly post my v3 of this patch fixing comments > from Marek Vasut <marek.vasut@gmail.com> Well, I did not say, I'm going to update anything. What I meant is that I'm going to look into TI's documentation regarding EHCI and the ULPI to understand the dependencies and see how your code meets those and if the generic ULPI layer can be used for that. So to lower the work load from from you, I'd suggest you to wait till Monday (if you can of course) to let me look into this. It is also possible that I will be able to check the above today or tomorrow, but I can't promise, as I'm really busy now. Thanks. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-12 9:23 ` Igor Grinberg @ 2012-01-12 10:52 ` Govindraj 2012-01-17 6:10 ` Govindraj 2012-01-17 18:17 ` Igor Grinberg 0 siblings, 2 replies; 40+ messages in thread From: Govindraj @ 2012-01-12 10:52 UTC (permalink / raw) To: u-boot On Thu, Jan 12, 2012 at 2:53 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Govindraj, > > On 01/12/12 07:45, Govindraj wrote: >> Hi Igor, >> >> On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>> Hi Guys, >>> >>> On 01/11/12 16:34, Marek Vasut wrote: >>>>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> >>>> wrote: >>>>>>>>>>> Hi Marek, >>>>>>>>>>> >>>>>>>>>>> Thanks for you review. >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>>>>> <marek.vasut@gmail.com> >>>>>> >>>>>> wrote: >>>>>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>>>>> >>>>>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>>>>> >>>>>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>>>>> block data and reg shifts. >>>>>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>>>>> header file. >>>>>>>>>>>> >>>>>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. >>>>>>>>>>> >>>>>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>>>>> is OMAP specific things which are done in ehci-omap.c file >>>>>>>>>>> >>>>>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>>>>> port in no -idle mode(omap specific pm implementation) etc. >>>>>>>>>> >>>>>>>>>> This stuff: >>>>>>>>>> >>>>>>>>>> +/* ULPI */ >>>>>>>>>> +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >>>>>>>>>> +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) >>>>>>>>>> +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >>>>>>>>>> +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >>>>>>>>>> >>>>>>>>>> is just accidentally conforming to ULPI spec? >>>>>>>>> >>>>>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>>>>> of omap while configuring in ulpi-phy mode. >>>>>>>>> >>>>>>>>> looking into struct ulpi_regs {..} >>>>>>>>> then it doesn't map this configuration. >>>>>>>> >>>>>>>> Can you point me to some documentation about this please? It's not >>>>>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>>>>> duplication. >>>>>>> >>>>>>> Yes that would be fine. >>>>>>> >>>>>>> You can download the omap4460 public trm from here: >>>>>>> >>>>>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>>>>> >>>>>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>>>>> (page number 5171 and 5186/87) >>>>>> >>>>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>>>>> that purpose, the struct ulpi_regs is fitting ok. >>>>>> >>>>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>>>>> already in u-boot and explain why they can not be used with this port? >>>>> >>>>> echi-omap.c is no where writing to those registers >>>>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map >>>>> >>>>> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >>>>> and debug purpose(to view vid, pid etc) and to hack external phy >>>>> configuration through ulpi commands >>>>> from omap - usb host controller point of view only needs >>>>> INSNREG05_ULPI reg in EHCI reg configuration >>>>> rest on soc host controller takes care of it. >>>> >>>> Can someone else comment on this? I think I don't understand well (as I'm not >>>> OMAP guy). >>> >>> Well, it is on my list, actually, >>> but I will be able to get to it only in a couple of days. >>> (I'm really busy right now). >>> >> >> Could you please let me know what exactly that you will be >> updating? >> >> So that I can accordingly post my v3 of this patch fixing comments >> from Marek Vasut <marek.vasut@gmail.com> > > Well, I did not say, I'm going to update anything. > What I meant is that I'm going to look into TI's documentation > regarding EHCI and the ULPI to understand the dependencies and see > how your code meets those and if the generic ULPI layer can be used > for that. > okay, Thanks, > So to lower the work load from from you, I'd suggest you to wait > till Monday (if you can of course) to let me look into this. Yes Sure. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-12 10:52 ` Govindraj @ 2012-01-17 6:10 ` Govindraj 2012-01-18 17:51 ` Igor Grinberg 2012-01-17 18:17 ` Igor Grinberg 1 sibling, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-17 6:10 UTC (permalink / raw) To: u-boot On Thu, Jan 12, 2012 at 4:22 PM, Govindraj <govindraj.ti@gmail.com> wrote: > On Thu, Jan 12, 2012 at 2:53 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> Hi Govindraj, >> >> On 01/12/12 07:45, Govindraj wrote: >>> Hi Igor, >>> >>> On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>>> Hi Guys, >>>> >>>> On 01/11/12 16:34, Marek Vasut wrote: >>>>>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> >>>>> wrote: >>>>>>>>>>>> Hi Marek, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for you review. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>>>>>> <marek.vasut@gmail.com> >>>>>>> >>>>>>> wrote: >>>>>>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>>>>>> block data and reg shifts. >>>>>>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>>>>>> header file. >>>>>>>>>>>>> >>>>>>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. >>>>>>>>>>>> >>>>>>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>>>>>> is OMAP specific things which are done in ehci-omap.c file >>>>>>>>>>>> >>>>>>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>>>>>> port in no -idle mode(omap specific pm implementation) etc. >>>>>>>>>>> >>>>>>>>>>> This stuff: >>>>>>>>>>> >>>>>>>>>>> +/* ULPI */ >>>>>>>>>>> +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) >>>>>>>>>>> +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) >>>>>>>>>>> +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 >>>>>>>>>>> +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) >>>>>>>>>>> >>>>>>>>>>> is just accidentally conforming to ULPI spec? >>>>>>>>>> >>>>>>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>>>>>> of omap while configuring in ulpi-phy mode. >>>>>>>>>> >>>>>>>>>> looking into struct ulpi_regs {..} >>>>>>>>>> then it doesn't map this configuration. >>>>>>>>> >>>>>>>>> Can you point me to some documentation about this please? It's not >>>>>>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>>>>>> duplication. >>>>>>>> >>>>>>>> Yes that would be fine. >>>>>>>> >>>>>>>> You can download the omap4460 public trm from here: >>>>>>>> >>>>>>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>>>>>> >>>>>>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>>>>>> (page number 5171 and 5186/87) >>>>>>> >>>>>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>>>>>> that purpose, the struct ulpi_regs is fitting ok. >>>>>>> >>>>>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>>>>>> already in u-boot and explain why they can not be used with this port? >>>>>> >>>>>> echi-omap.c is no where writing to those registers >>>>>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map >>>>>> >>>>>> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >>>>>> and debug purpose(to view vid, pid etc) and to hack external phy >>>>>> configuration through ulpi commands >>>>>> from omap - usb host controller point of view only needs >>>>>> INSNREG05_ULPI reg in EHCI reg configuration >>>>>> rest on soc host controller takes care of it. >>>>> >>>>> Can someone else comment on this? I think I don't understand well (as I'm not >>>>> OMAP guy). >>>> >>>> Well, it is on my list, actually, >>>> but I will be able to get to it only in a couple of days. >>>> (I'm really busy right now). >>>> >>> >>> Could you please let me know what exactly that you will be >>> updating? >>> >>> So that I can accordingly post my v3 of this patch fixing comments >>> from Marek Vasut <marek.vasut@gmail.com> >> >> Well, I did not say, I'm going to update anything. >> What I meant is that I'm going to look into TI's documentation >> regarding EHCI and the ULPI to understand the dependencies and see >> how your code meets those and if the generic ULPI layer can be used >> for that. >> > > okay, Thanks, > >> So to lower the work load from from you, I'd suggest you to wait >> till Monday (if you can of course) to let me look into this. > Gentle Ping. And just to clarify further there is no code duplication for ulpi read writes in ehci-omap.c done with this patch. Patch intends only in configuring ehci to right modes as specified by board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode. This patch is derived with reference to linux kernel and even there we can see that no ulpi_reg map registers are used and only ehci is configured is respective mode as passed by board data. Here [1] is the patch fixing Marek Vasut <marek.vasut@gmail.com> comments. This corrected patch along with dependent patch from Ilya Yanok <yanok@emcraft.com> [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 Is available here: git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap -- Thanks, Govindraj.R [1]: ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-17 6:10 ` Govindraj @ 2012-01-18 17:51 ` Igor Grinberg 2012-01-19 8:15 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Igor Grinberg @ 2012-01-18 17:51 UTC (permalink / raw) To: u-boot Hi Govindraj, On 01/17/12 08:10, Govindraj wrote: > > And just to clarify further there is no code duplication for ulpi read writes > in ehci-omap.c done with this patch. This is not just about code duplication, this is also about using the ULPI framework instead of direct writes to the ULPI PHYs. > Patch intends only in configuring ehci to right modes as specified by > board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode. > > This patch is derived with reference to linux kernel and even there > we can see that no ulpi_reg map registers are used and only ehci > is configured is respective mode as passed by board data. This is not correct. They are used, see: drivers/usb/host/ehci-omap.c file, omap_ehci_soft_phy_reset() function. It does exactly the same, but yes it does not use the ULPI framework, because in Linux currently, there is no generic enough ULPI framework, so drivers can use it. There were discussions about it and decided that until there is such a framework, things can be done the way they are. > > Here [1] is the patch fixing Marek Vasut <marek.vasut@gmail.com> > comments. > > This corrected patch along with dependent patch from > Ilya Yanok <yanok@emcraft.com> > [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 > > Is available here: > git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap > > -- > Thanks, > Govindraj.R > > [1]: > >>From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001 > From: "Govindraj.R" <govindraj.raja@ti.com> > Date: Tue, 27 Dec 2011 14:53:12 +0530 > Subject: [PATCH 2/6] ehci-omap: Clean up added ehci-omap.c > > Clean up added ehci-omap.c and make it generic for re-use across > soc having same ehci ip block. Also pass the modes to be configured > and configure the ports accordingly. All usb layers are not cache > aligned till then keep cache off for usb ops as ehci will use > internally dma for all usb ops. > > * Add a generic common header ehci-omap.h having common ip block > data and reg shifts. > * Rename and modify ehci-omap3 to ehci.h retain only conflicting > sysc reg shifts remove others and move to common header file. > > Signed-off-by: Govindraj.R <govindraj.raja@ti.com> > --- > arch/arm/include/asm/arch-omap3/ehci.h | 55 ++++++ > arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ------- > arch/arm/include/asm/arch-omap4/ehci.h | 49 ++++++ > arch/arm/include/asm/ehci-omap.h | 147 +++++++++++++++++ > drivers/usb/host/ehci-omap.c | 228 +++++++++++++++++++------- > 5 files changed, 423 insertions(+), 114 deletions(-) > create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h > delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h > create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h > create mode 100644 arch/arm/include/asm/ehci-omap.h > > diff --git a/arch/arm/include/asm/arch-omap3/ehci.h > b/arch/arm/include/asm/arch-omap3/ehci.h > new file mode 100644 > index 0000000..d622363 > --- /dev/null > +++ b/arch/arm/include/asm/arch-omap3/ehci.h > @@ -0,0 +1,55 @@ > +/* > + * (C) Copyright 2011 > + * Alexander Holler <holler@ahsoftware.de> > + * > + * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 > + * > + * See there for additional Copyrights. > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * 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., 51 Franklin Street, Fifth Floor, Boston, > + * MA 02110-1301 USA > + */ > +#ifndef _EHCI_H_ > +#define _EHCI_H_ hmmm... isn't it too generic? I think you should have included a part of the path to the file, so no namespace collision will occure. something like _OMAP3_EHCI_H_? > + > +/* USB/EHCI registers */ > +#define OMAP_USBTLL_BASE 0x48062000UL > +#define OMAP_UHH_BASE 0x48064000UL > +#define OMAP_EHCI_BASE 0x48064800UL > + > +/* TLL Register Set */ > +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) > +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) > +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) > +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) > +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 > + > +/* UHH Register Set */ > +#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) > +#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) > +#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) > +#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) > +#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) > +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) > + > +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_CACTIVITY | \ > + OMAP_UHH_SYSCONFIG_SIDLEMODE | \ > + OMAP_UHH_SYSCONFIG_ENAWAKEUP | \ > + OMAP_UHH_SYSCONFIG_MIDLEMODE) > + > +#endif /* _EHCI_H_ */ > diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h > b/arch/arm/include/asm/arch-omap3/ehci_omap3.h > deleted file mode 100644 > index cd01f50..0000000 > --- a/arch/arm/include/asm/arch-omap3/ehci_omap3.h > +++ /dev/null > @@ -1,58 +0,0 @@ > -/* > - * (C) Copyright 2011 > - * Alexander Holler <holler@ahsoftware.de> > - * > - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 > - * > - * See there for additional Copyrights. > - * > - * See file CREDITS for list of people who contributed to this > - * project. > - * > - * 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., 51 Franklin Street, Fifth Floor, Boston, > - * MA 02110-1301 USA > - */ > -#ifndef _EHCI_OMAP3_H_ > -#define _EHCI_OMAP3_H_ > - > -/* USB/EHCI registers */ > -#define OMAP3_USBTLL_BASE 0x48062000UL > -#define OMAP3_UHH_BASE 0x48064000UL > -#define OMAP3_EHCI_BASE 0x48064800UL > - > -/* TLL Register Set */ > -#define OMAP_USBTLL_SYSCONFIG (0x10) > -#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) > -#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) > -#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) > -#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) > - > -#define OMAP_USBTLL_SYSSTATUS (0x14) > -#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0) > - > -/* UHH Register Set */ > -#define OMAP_UHH_SYSCONFIG (0x10) > -#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) > -#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) > -#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) > -#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) > -#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) > - > -#define OMAP_UHH_HOSTCONFIG (0x40) > -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) > -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) > -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) > - > -#endif /* _EHCI_OMAP3_H_ */ > diff --git a/arch/arm/include/asm/arch-omap4/ehci.h > b/arch/arm/include/asm/arch-omap4/ehci.h > new file mode 100644 > index 0000000..eaa82cf > --- /dev/null > +++ b/arch/arm/include/asm/arch-omap4/ehci.h > @@ -0,0 +1,49 @@ > +/* > + * OMAP EHCI port support > + * Based on LINUX KERNEL > + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c > + * > + * Copyright (C) 2011 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 version 2 of > + * the License as published by the Free Software Foundation. > + * > + * 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, see <http://www.gnu.org/licenses/>. > + */ > + > +#ifndef _EHCI_H > +#define _EHCI_H see what I mean? above you have _EHCI_H_ and here _EHCI_H... That is too confusing... IMO, something like _OMAP4_EHCI_H_ will do here. > + > +#define OMAP_EHCI_BASE (OMAP44XX_L4_CORE_BASE + 0x64C00) > +#define OMAP_UHH_BASE (OMAP44XX_L4_CORE_BASE + 0x64000) > +#define OMAP_USBTLL_BASE (OMAP44XX_L4_CORE_BASE + 0x62000) > + > +/* UHH, TLL and opt clocks */ > +#define CM_L3INIT_HSUSBHOST_CLKCTRL 0x4A009358UL > + > +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK (1 << 24) > + > +/* 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 > new file mode 100644 > index 0000000..ac68db7 > --- /dev/null > +++ b/arch/arm/include/asm/ehci-omap.h > @@ -0,0 +1,147 @@ > +/* > + * OMAP EHCI port support > + * Based on LINUX KERNEL > + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c > + * > + * Copyright (C) 2011 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 version 2 of > + * the License as published by the Free Software Foundation. > + * > + * 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, see <http://www.gnu.org/licenses/>. > + */ > + > +#ifndef EHCI_H > +#define EHCI_H And even worth... now there are three of them!!! No, this is not good... what about OMAP5 will it be EHCI__H? Probably here, something like _OMAP_COMMON_EHCI_H_ will do? > + > +enum usbhs_omap_port_mode { > + OMAP_USBHS_PORT_MODE_UNUSED, > + OMAP_EHCI_PORT_MODE_PHY, > + OMAP_EHCI_PORT_MODE_TLL, > + OMAP_EHCI_PORT_MODE_HSIC, > +}; > + > +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS > +#define OMAP_HS_USB_PORTS CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS > +#else > +#define OMAP_HS_USB_PORTS 3 > +#endif > + > +#define is_ehci_phy_mode(x) ((x) == OMAP_EHCI_PORT_MODE_PHY) > +#define is_ehci_tll_mode(x) ((x) == OMAP_EHCI_PORT_MODE_TLL) > +#define is_ehci_hsic_mode(x) ((x) == OMAP_EHCI_PORT_MODE_HSIC) > + > +/* Values of UHH_REVISION - Note: these are not given in the TRM */ > +#define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ > +#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ > + > +/* UHH Register Set */ > +#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) > +#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) > +#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) > +#define OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN (1 << 5) > + > +#define OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS 1 > +#define OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS (1 << 11) > +#define OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS (1 << 12) > +#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 << 31) > + > +#define OMAP_P1_MODE_CLEAR (3 << 16) > +#define OMAP_P1_MODE_TLL (1 << 16) > +#define OMAP_P1_MODE_HSIC (3 << 16) > +#define OMAP_P2_MODE_CLEAR (3 << 18) > +#define OMAP_P2_MODE_TLL (1 << 18) > +#define OMAP_P2_MODE_HSIC (3 << 18) > + > +/* EHCI Register Set */ > +#define EHCI_INSNREG04_DISABLE_UNSUSPEND (1 << 5) > +#define EHCI_INSNREG05_ULPI_CONTROL_SHIFT 31 > +#define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT 24 > +#define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22 > +#define EHCI_INSNREG05_ULPI_REGADD_SHIFT 16 > + > +#define OMAP_REV1_TLL_CHANNEL_COUNT 3 > +#define OMAP_REV2_TLL_CHANNEL_COUNT 2 > + > +/* TLL Register Set */ > +#define OMAP_TLL_CHANNEL_CONF(num) (0x004 * num) > +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 << 16) > +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 << 15) > +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF (1 << 11) > +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI (2 << 1) > +#define OMAP_TLL_CHANNEL_CONF_CHANEN 1 > + > +/* ULPI */ > +#define ULPI_SET(a) (a + 1) This is the offset of each "set" register of ULPI PHY > +#define ULPI_CLR(a) (a + 2) This is the offset of each "clear" register of ULPI PHY > +#define ULPI_FUNC_CTRL 0x04 This is the offset of the "Function Control register" of the ULPI PHY This is already defined as ulpi_regs.function_ctrl member in include/usb/ulpi.h file. > +#define ULPI_FUNC_CTRL_RESET (1 << 5) This is the reset bin inside the "Function Control register" of the ULPI PHY This bit is already defined in the include/usb/ulpi.h file. > + > +struct omap_usbhs_board_data { > + enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; > +}; > + > +struct omap_usbtll { > + u32 rev; /* 0x00 */ > + u32 hwinfo; /* 0x04 */ > + u8 reserved1[0x8]; > + u32 sysc; /* 0x10 */ > + u32 syss; /* 0x14 */ > + u32 irqst; /* 0x18 */ > + u32 irqen; /* 0x1c */ > + u8 reserved2[0x10]; > + u32 shared_conf; /* 0x30 */ > + u8 reserved3[0xc]; > + u32 channel_conf; /* 0x40 */ > +}; > + > +struct omap_uhh { > + u32 rev; /* 0x00 */ > + u32 hwinfo; /* 0x04 */ > + u8 reserved1[0x8]; > + u32 sysc; /* 0x10 */ > + u32 syss; /* 0x14 */ > + u8 reserved2[0x28]; > + u32 hostconfig; /* 0x40 */ > + u32 debugcsr; /* 0x44 */ > +}; > + > +struct omap_ehci { > + u32 hccapbase; /* 0x00 */ > + u32 hcsparams; /* 0x04 */ > + u32 hccparams; /* 0x08 */ > + u8 reserved1[0x04]; > + u32 usbcmd; /* 0x10 */ > + u32 usbsts; /* 0x14 */ > + u32 usbintr; /* 0x18 */ > + u32 frindex; /* 0x1c */ > + u32 ctrldssegment; /* 0x20 */ > + u32 periodiclistbase; /* 0x24 */ > + u32 asysnclistaddr; /* 0x28 */ > + u8 reserved2[0x24]; > + u32 configflag; /* 0x50 */ > + u32 portsc_i; /* 0x54 */ > + u8 reserved3[0x38]; > + u32 insreg00; /* 0x90 */ > + u32 insreg01; /* 0x94 */ > + u32 insreg02; /* 0x98 */ > + u32 insreg03; /* 0x9c */ > + u32 insreg04; /* 0xa0 */ > + u32 insreg05_utmi_ulpi; /* 0xa4 */ > + u32 insreg06; /* 0xa8 */ > + u32 insreg07; /* 0xac */ > + u32 insreg08; /* 0xb0 */ > +}; > + > +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata); > +int omap_ehci_hcd_stop(void); > + > +#endif /* EHCI_H */ > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index 93d3bb7..01c22e6 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -27,14 +27,93 @@ > */ > #include <common.h> > #include <usb.h> > +#include <errno.h> > #include <asm/io.h> > #include <asm/gpio.h> > -#include <asm/arch/clocks.h> > -#include <asm/arch/clocks_omap3.h> > -#include <asm/arch/ehci_omap3.h> > -#include <asm/arch/sys_proto.h> > +#include <asm/arch/ehci.h> > +#include <asm/ehci-omap.h> > #include "ehci-core.h" > > +static struct omap_uhh *const uhh = (struct omap_uhh *)OMAP_UHH_BASE; > +static struct omap_usbtll *const usbtll = (struct omap_usbtll > *)OMAP_USBTLL_BASE; > +static struct omap_ehci *const ehci = (struct omap_ehci *)OMAP_EHCI_BASE; > + > +static int omap_uhh_reset(void) > +{ > + unsigned long init = get_timer(0); > + > + /* perform UHH soft reset, and wait until reset is complete */ > + writel(OMAP_UHH_SYSCONFIG_SOFTRESET, &uhh->sysc); > + > + /* Wait for UHH reset to complete */ > + while (!(readl(&uhh->syss) & OMAP_UHH_SYSSTATUS_EHCI_RESETDONE)) > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP UHH error: timeout resetting ehci\n"); > + return -EL3RST; > + } > + > + return 0; > +} > + > +static int omap_ehci_tll_reset(void) > +{ > + unsigned long init = get_timer(0); > + > + /* perform TLL soft reset, and wait until reset is complete */ > + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, &usbtll->sysc); > + > + /* Wait for TLL reset to complete */ > + while (!(readl(&usbtll->syss) & OMAP_USBTLL_SYSSTATUS_RESETDONE)) > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP EHCI error: timeout resetting TLL\n"); > + return -EL3RST; > + } > + > + return 0; > +} > + > +static void omap_usbhs_hsic_init(int tll_cnt) > +{ > + unsigned int reg; > + int i; > + > + /* Enable channels now */ > + for (i = 0; i < tll_cnt; i++) { > + reg = readl(&usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); > + > + setbits_le32(®, (OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI > + | OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF > + | OMAP_TLL_CHANNEL_CONF_DRVVBUS > + | OMAP_TLL_CHANNEL_CONF_CHRGVBUS > + | OMAP_TLL_CHANNEL_CONF_CHANEN)); > + > + writel(reg, &usbtll->channel_conf + OMAP_TLL_CHANNEL_CONF(i)); > + } > +} > + > +static void omap_ehci_soft_phy_reset(int port) > +{ > + unsigned int reg = 0; > + unsigned long init = get_timer(0); > + > + /* FUNCTION_CTRL_SET register */ > + reg = ULPI_FUNC_CTRL_RESET | > + (ULPI_SET(ULPI_FUNC_CTRL) << EHCI_INSNREG05_ULPI_REGADD_SHIFT) | > + (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) | > + ((port + 1) << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) | > + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT); > + > + writel(reg, &ehci->insreg05_utmi_ulpi); > + > + /* Wait for ULPI access completion */ > + while ((readl(&ehci->insreg05_utmi_ulpi) & > + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) > + if (get_timer(init) > CONFIG_SYS_HZ) { > + debug("OMAP EHCI error: timeout resetting phy\n"); > + break; > + } > +} Ok, this function is kind of "duplication" of the ULPI code. ulpi_reset() function in drivers/usb/ulpi/ulpi.c provides an implementation of the ULPI spec. and should be used by the drivers. What it lacks currently, is a way to pass a port number to the viewport implementation and of course the omap-ulpi-viewport(.c) implementation itself... So, IMO, the right way would be to implement ULPI accessors (omap-ulpi-viewport.c) and add an ability to pass some kind of private data to the viewport, which in case of OMAP will be the port number. Now, I know, that this will add much more code then this function does, but it is always about using frameworks, otherwise each board file can implement the whole U-Boot startup.... > + > inline int __board_usb_init(void) > { > return 0; > @@ -72,31 +151,31 @@ static inline void omap_ehci_phy_reset(int on, int delay) > #endif > > /* Reset is needed otherwise the kernel-driver will throw an error. */ > -int ehci_hcd_stop(void) > +int omap_ehci_hcd_stop(void) > { > - debug("Resetting OMAP3 EHCI\n"); > + debug("Resetting OMAP EHCI\n"); > omap_ehci_phy_reset(1, 0); > - writel(OMAP_UHH_SYSCONFIG_SOFTRESET, > - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); > - /* disable USB clocks */ > - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; > - sr32(&prcm_base->iclken_usbhost, 0, 1, 0); > - sr32(&prcm_base->fclken_usbhost, 0, 2, 0); > - sr32(&prcm_base->iclken3_core, 2, 1, 0); > - sr32(&prcm_base->fclken3_core, 2, 1, 0); > + > + if (omap_uhh_reset() < 0) > + return -1; > + > + if (omap_ehci_tll_reset() < 0) > + return -1; > + > return 0; > } > > /* > - * Initialize the OMAP3 EHCI controller and PHY. > - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. > + * Initialize the OMAP EHCI controller and PHY. > + * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 > * See there for additional Copyrights. > */ > -int ehci_hcd_init(void) > +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) > { > - int ret; > + int ret = 0; > + unsigned int i, reg = 0, rev = 0, tll_cnt = 0; > > - debug("Initializing OMAP3 EHCI\n"); > + debug("Initializing OMAP EHCI\n"); > > ret = board_usb_init(); > if (ret < 0) > @@ -105,52 +184,89 @@ int ehci_hcd_init(void) > /* Put the PHY in RESET */ > omap_ehci_phy_reset(1, 10); > > - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; > - /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ > - sr32(&prcm_base->iclken_usbhost, 0, 1, 1); > - /* > - * Enable USBHOST_48M_FCLK (USBHOST_FCLK1) > - * and USBHOST_120M_FCLK (USBHOST_FCLK2) > - */ > - sr32(&prcm_base->fclken_usbhost, 0, 2, 3); > - /* Enable USBTTL_ICLK */ > - sr32(&prcm_base->iclken3_core, 2, 1, 1); > - /* Enable USBTTL_FCLK */ > - sr32(&prcm_base->fclken3_core, 2, 1, 1); > - debug("USB clocks enabled\n"); > + ret = omap_uhh_reset(); > + if (ret < 0) > + return ret; > > - /* perform TLL soft reset, and wait until reset is complete */ > - writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, > - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); > - /* Wait for TLL reset to complete */ > - while (!(readl(OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSSTATUS) > - & OMAP_USBTLL_SYSSTATUS_RESETDONE)) > - ; > - debug("TLL reset done\n"); > + ret = omap_ehci_tll_reset(); > + if (ret) > + return ret; You do both resets unconditionally, shouldn't you check which mode the port is in and only reset the right one? Is it because all of them need to be configurred? > > writel(OMAP_USBTLL_SYSCONFIG_ENAWAKEUP | > OMAP_USBTLL_SYSCONFIG_SIDLEMODE | > - OMAP_USBTLL_SYSCONFIG_CACTIVITY, > - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); > + OMAP_USBTLL_SYSCONFIG_CACTIVITY, &usbtll->sysc); > > /* Put UHH in NoIdle/NoStandby mode */ > - writel(OMAP_UHH_SYSCONFIG_ENAWAKEUP > - | OMAP_UHH_SYSCONFIG_SIDLEMODE > - | OMAP_UHH_SYSCONFIG_CACTIVITY > - | OMAP_UHH_SYSCONFIG_MIDLEMODE, > - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); > - > - /* setup burst configurations */ > - writel(OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN > - | OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN > - | OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN, > - OMAP3_UHH_BASE + OMAP_UHH_HOSTCONFIG); > + writel(OMAP_UHH_SYSCONFIG_VAL, &uhh->sysc); > + > + /* setup ULPI bypass and burst configurations */ > + clrsetbits_le32(®, OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN, > + (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN | > + OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN | > + OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN)); > + > + rev = readl(&uhh->rev); > + if (rev == OMAP_USBHS_REV1) { > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[0])) > + clrbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS); > + else > + setbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS); > + > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[1])) > + clrbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS); > + else > + setbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS); > + > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[2])) > + clrbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS); > + else > + setbits_le32(®, OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS); > + > + tll_cnt = OMAP_REV1_TLL_CHANNEL_COUNT; > + } else if (rev == OMAP_USBHS_REV2) { > + > + clrsetbits_le32(®, (OMAP_P1_MODE_CLEAR | OMAP_P2_MODE_CLEAR), > + OMAP4_UHH_HOSTCONFIG_APP_START_CLK); > + > + /* Clear port mode fields for PHY mode*/ > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0])) > + setbits_le32(®, OMAP_P1_MODE_HSIC); > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) > + setbits_le32(®, OMAP_P2_MODE_HSIC); > + > + tll_cnt = OMAP_REV2_TLL_CHANNEL_COUNT; > + } > + > + debug("OMAP UHH_REVISION 0x%x\n", rev); > + writel(reg, &uhh->hostconfig); > + > + if (is_ehci_hsic_mode(usbhs_pdata->port_mode[0]) || > + is_ehci_hsic_mode(usbhs_pdata->port_mode[1])) > + omap_usbhs_hsic_init(tll_cnt); > > omap_ehci_phy_reset(0, 10); > > - hccr = (struct ehci_hccr *)(OMAP3_EHCI_BASE); > - hcor = (struct ehci_hcor *)(OMAP3_EHCI_BASE + 0x10); > + /* > + * An undocumented "feature" in the OMAP3 EHCI controller, > + * causes suspended ports to be taken out of suspend when > + * the USBCMD.Run/Stop bit is cleared (for example when > + * we do ehci_bus_suspend). > + * This breaks suspend-resume if the root-hub is allowed > + * to suspend. Writing 1 to this undocumented register bit > + * disables this feature and restores normal behavior. > + */ > + writel(EHCI_INSNREG04_DISABLE_UNSUSPEND, &ehci->insreg04); > + > + for (i = 0; i < OMAP_HS_USB_PORTS; i++) > + if (is_ehci_phy_mode(usbhs_pdata->port_mode[i])) > + omap_ehci_soft_phy_reset(i); > + > + dcache_disable(); > + hccr = (struct ehci_hccr *)(OMAP_EHCI_BASE); > + hcor = (struct ehci_hcor *)(OMAP_EHCI_BASE + 0x10); > > - debug("OMAP3 EHCI init done\n"); > + debug("OMAP EHCI init done\n"); > return 0; > } -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-18 17:51 ` Igor Grinberg @ 2012-01-19 8:15 ` Govindraj 2012-01-22 12:20 ` Igor Grinberg 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-19 8:15 UTC (permalink / raw) To: u-boot On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Govindraj, > > On 01/17/12 08:10, Govindraj wrote: >> >> And just to clarify further there is no code duplication for ulpi read writes >> in ehci-omap.c done with this patch. > > This is not just about code duplication, > this is also about using the ULPI framework instead of direct writes to the > ULPI PHYs. > >> Patch intends only in configuring ehci to right modes as specified by >> board file. ?Modes possible are hsic_mode, tll_mode, ulpi_phy mode. >> >> This patch is derived with reference to linux kernel and even there >> we can see that no ulpi_reg map registers are used and only ehci >> is configured is respective mode as passed by board data. > > This is not correct. They are used, see: > drivers/usb/host/ehci-omap.c file, omap_ehci_soft_phy_reset() function. > It does exactly the same, but yes it does not use the ULPI framework, > because in Linux currently, there is no generic enough ULPI framework, > so drivers can use it. linux-2.6/drivers/usb/otg/ulpi.c ? > There were discussions about it and decided that until there is such > a framework, things can be done the way they are. > >> >> Here [1] is the patch fixing Marek Vasut <marek.vasut@gmail.com> >> comments. >> >> This corrected patch along with dependent patch from >> Ilya Yanok <yanok@emcraft.com> >> [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 >> >> Is available here: >> git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap >> >> -- >> Thanks, >> Govindraj.R >> >> [1]: >> >>>From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001 >> From: "Govindraj.R" <govindraj.raja@ti.com> >> Date: Tue, 27 Dec 2011 14:53:12 +0530 >> Subject: [PATCH 2/6] ehci-omap: Clean up added ehci-omap.c >> >> Clean up added ehci-omap.c and make it generic for re-use across >> soc having same ehci ip block. Also pass the modes to be configured >> and configure the ports accordingly. All usb layers are not cache >> aligned till then keep cache off for usb ops as ehci will use >> internally dma for all usb ops. >> >> * Add a generic common header ehci-omap.h having common ip block >> ? data and reg shifts. >> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >> ? sysc reg shifts remove others and move to common header file. >> >> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> >> --- >> ?arch/arm/include/asm/arch-omap3/ehci.h ? ? ? | ? 55 ++++++ >> ?arch/arm/include/asm/arch-omap3/ehci_omap3.h | ? 58 ------- >> ?arch/arm/include/asm/arch-omap4/ehci.h ? ? ? | ? 49 ++++++ >> ?arch/arm/include/asm/ehci-omap.h ? ? ? ? ? ? | ?147 +++++++++++++++++ >> ?drivers/usb/host/ehci-omap.c ? ? ? ? ? ? ? ? | ?228 +++++++++++++++++++------- >> ?5 files changed, 423 insertions(+), 114 deletions(-) >> ?create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h >> ?delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h >> ?create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h >> ?create mode 100644 arch/arm/include/asm/ehci-omap.h >> >> diff --git a/arch/arm/include/asm/arch-omap3/ehci.h >> b/arch/arm/include/asm/arch-omap3/ehci.h >> new file mode 100644 >> index 0000000..d622363 >> --- /dev/null >> +++ b/arch/arm/include/asm/arch-omap3/ehci.h >> @@ -0,0 +1,55 @@ >> +/* >> + * (C) Copyright 2011 >> + * Alexander Holler <holler@ahsoftware.de> >> + * >> + * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 >> + * >> + * See there for additional Copyrights. >> + * >> + * See file CREDITS for list of people who contributed to this >> + * project. >> + * >> + * 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., 51 Franklin Street, Fifth Floor, Boston, >> + * MA 02110-1301 USA >> + */ >> +#ifndef _EHCI_H_ >> +#define _EHCI_H_ > > hmmm... isn't it too generic? > I think you should have included a part of the path to the file, > so no namespace collision will occure. > something like _OMAP3_EHCI_H_? > since these include's are part of arch folder will not collide with other ones. But still its better to have _OMAP3_EHCI_H_ will correct this. >> + >> +/* USB/EHCI registers */ >> +#define OMAP_USBTLL_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x48062000UL >> +#define OMAP_UHH_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x48064000UL >> +#define OMAP_EHCI_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x48064800UL >> + >> +/* TLL Register Set */ >> +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET ? ? ? ? ? ? ? ? ? ? ?(1 << 1) >> +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP ? ? ? ? ? ? ? ? ? ? ?(1 << 2) >> +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE ? ? ? ? ? ? ? ? ? ? ?(1 << 3) >> +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY ? ? ? ? ? ? ? ? ? ? ?(1 << 8) >> +#define OMAP_USBTLL_SYSSTATUS_RESETDONE ? ? ? ? ? ? ? ? ? ? ?1 >> + >> +/* UHH Register Set */ >> +#define OMAP_UHH_SYSCONFIG_SOFTRESET ? ? ? ? ? ? ? ? (1 << 1) >> +#define OMAP_UHH_SYSCONFIG_CACTIVITY ? ? ? ? ? ? ? ? (1 << 8) >> +#define OMAP_UHH_SYSCONFIG_SIDLEMODE ? ? ? ? ? ? ? ? (1 << 3) >> +#define OMAP_UHH_SYSCONFIG_ENAWAKEUP ? ? ? ? ? ? ? ? (1 << 2) >> +#define OMAP_UHH_SYSCONFIG_MIDLEMODE ? ? ? ? ? ? ? ? (1 << 12) >> +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE ? ? ? ? ? ?(1 << 2) >> + >> +#define OMAP_UHH_SYSCONFIG_VAL ? ? ? ? ? ? ? (OMAP_UHH_SYSCONFIG_CACTIVITY | \ >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OMAP_UHH_SYSCONFIG_SIDLEMODE | \ >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OMAP_UHH_SYSCONFIG_ENAWAKEUP | \ >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? OMAP_UHH_SYSCONFIG_MIDLEMODE) >> + >> +#endif /* _EHCI_H_ */ >> diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h >> b/arch/arm/include/asm/arch-omap3/ehci_omap3.h >> deleted file mode 100644 >> index cd01f50..0000000 >> --- a/arch/arm/include/asm/arch-omap3/ehci_omap3.h >> +++ /dev/null >> @@ -1,58 +0,0 @@ >> -/* >> - * (C) Copyright 2011 >> - * Alexander Holler <holler@ahsoftware.de> >> - * >> - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 >> - * >> - * See there for additional Copyrights. >> - * >> - * See file CREDITS for list of people who contributed to this >> - * project. >> - * >> - * 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., 51 Franklin Street, Fifth Floor, Boston, >> - * MA 02110-1301 USA >> - */ >> -#ifndef _EHCI_OMAP3_H_ >> -#define _EHCI_OMAP3_H_ >> - >> -/* USB/EHCI registers */ >> -#define OMAP3_USBTLL_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x48062000UL >> -#define OMAP3_UHH_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x48064000UL >> -#define OMAP3_EHCI_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x48064800UL >> - >> -/* TLL Register Set */ >> -#define ? ? ?OMAP_USBTLL_SYSCONFIG ? ? ? ? ? ? ? ? ? ? ? ? ? (0x10) >> -#define ? ? ?OMAP_USBTLL_SYSCONFIG_SOFTRESET ? ? ? ? ? ? ? ? (1 << 1) >> -#define ? ? ?OMAP_USBTLL_SYSCONFIG_ENAWAKEUP ? ? ? ? ? ? ? ? (1 << 2) >> -#define ? ? ?OMAP_USBTLL_SYSCONFIG_SIDLEMODE ? ? ? ? ? ? ? ? (1 << 3) >> -#define ? ? ?OMAP_USBTLL_SYSCONFIG_CACTIVITY ? ? ? ? ? ? ? ? (1 << 8) >> - >> -#define ? ? ?OMAP_USBTLL_SYSSTATUS ? ? ? ? ? ? ? ? ? ? ? ? ? (0x14) >> -#define ? ? ?OMAP_USBTLL_SYSSTATUS_RESETDONE ? ? ? ? ? ? ? ? (1 << 0) >> - >> -/* UHH Register Set */ >> -#define ? ? ?OMAP_UHH_SYSCONFIG ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(0x10) >> -#define ? ? ?OMAP_UHH_SYSCONFIG_SOFTRESET ? ? ? ? ? ? ? ? ? ?(1 << 1) >> -#define ? ? ?OMAP_UHH_SYSCONFIG_CACTIVITY ? ? ? ? ? ? ? ? ? ?(1 << 8) >> -#define ? ? ?OMAP_UHH_SYSCONFIG_SIDLEMODE ? ? ? ? ? ? ? ? ? ?(1 << 3) >> -#define ? ? ?OMAP_UHH_SYSCONFIG_ENAWAKEUP ? ? ? ? ? ? ? ? ? ?(1 << 2) >> -#define ? ? ?OMAP_UHH_SYSCONFIG_MIDLEMODE ? ? ? ? ? ? ? ? ? ?(1 << 12) >> - >> -#define ? ? ?OMAP_UHH_HOSTCONFIG ? ? ? ? ? ? ? ? ? ? ? ? ? ? (0x40) >> -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN ? ? ? ? ? (1 << 2) >> -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN ? ? ? ? ? (1 << 3) >> -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN ? ? ? ? ?(1 << 4) >> - >> -#endif /* _EHCI_OMAP3_H_ */ >> diff --git a/arch/arm/include/asm/arch-omap4/ehci.h >> b/arch/arm/include/asm/arch-omap4/ehci.h >> new file mode 100644 >> index 0000000..eaa82cf >> --- /dev/null >> +++ b/arch/arm/include/asm/arch-omap4/ehci.h >> @@ -0,0 +1,49 @@ >> +/* >> + * OMAP EHCI port support >> + * Based on LINUX KERNEL >> + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c >> + * >> + * Copyright (C) 2011 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 version 2 ?of >> + * the License as published by the Free Software Foundation. >> + * >> + * 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, see <http://www.gnu.org/licenses/>. >> + */ >> + >> +#ifndef _EHCI_H >> +#define _EHCI_H > > see what I mean? above you have _EHCI_H_ and here _EHCI_H... > That is too confusing... > IMO, something like _OMAP4_EHCI_H_ will do here. > will correct it. >> + >> +#define OMAP_EHCI_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (OMAP44XX_L4_CORE_BASE + 0x64C00) >> +#define OMAP_UHH_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(OMAP44XX_L4_CORE_BASE + 0x64000) >> +#define OMAP_USBTLL_BASE ? ? ? ? ? ? ? ? ? ? (OMAP44XX_L4_CORE_BASE + 0x62000) >> + >> +/* UHH, TLL and opt clocks */ >> +#define CM_L3INIT_HSUSBHOST_CLKCTRL ? ? ? ? ?0x4A009358UL >> + >> +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK ? ? ? ?(1 << 24) >> + >> +/* 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 >> new file mode 100644 >> index 0000000..ac68db7 >> --- /dev/null >> +++ b/arch/arm/include/asm/ehci-omap.h >> @@ -0,0 +1,147 @@ >> +/* >> + * OMAP EHCI port support >> + * Based on LINUX KERNEL >> + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c >> + * >> + * Copyright (C) 2011 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 version 2 ?of >> + * the License as published by the Free Software Foundation. >> + * >> + * 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, see <http://www.gnu.org/licenses/>. >> + */ >> + >> +#ifndef EHCI_H >> +#define EHCI_H > > And even worth... now there are three of them!!! > No, this is not good... what about OMAP5 will it be EHCI__H? > Probably here, something like _OMAP_COMMON_EHCI_H_ will do? > sure will do it. >> + >> +enum usbhs_omap_port_mode { >> + ? ? OMAP_USBHS_PORT_MODE_UNUSED, >> + ? ? OMAP_EHCI_PORT_MODE_PHY, >> + ? ? OMAP_EHCI_PORT_MODE_TLL, >> + ? ? OMAP_EHCI_PORT_MODE_HSIC, >> +}; >> + >> +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >> +#define OMAP_HS_USB_PORTS ? ?CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >> +#else >> +#define OMAP_HS_USB_PORTS ? ?3 >> +#endif >> + >> +#define is_ehci_phy_mode(x) ?((x) == OMAP_EHCI_PORT_MODE_PHY) >> +#define is_ehci_tll_mode(x) ?((x) == OMAP_EHCI_PORT_MODE_TLL) >> +#define is_ehci_hsic_mode(x) ((x) == OMAP_EHCI_PORT_MODE_HSIC) >> + >> +/* Values of UHH_REVISION - Note: these are not given in the TRM */ >> +#define OMAP_USBHS_REV1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00000010 /* OMAP3 */ >> +#define OMAP_USBHS_REV2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x50700100 /* OMAP4 */ >> + >> +/* UHH Register Set */ >> +#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN ? ? ? ? ? (1 << 2) >> +#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN ? ? ? ? ? (1 << 3) >> +#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN ? ? ? ? ?(1 << 4) >> +#define OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN ? ? ? ? ? (1 << 5) >> + >> +#define OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS ? ? ? ? ? 1 >> +#define OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS ? ? ? ? ? (1 << 11) >> +#define OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS ? ? ? ? ? (1 << 12) >> +#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK ? ? ? ? ? (1 << 31) >> + >> +#define OMAP_P1_MODE_CLEAR ? ? ? ? ? ? ? ? ? ? ? ? ? (3 << 16) >> +#define OMAP_P1_MODE_TLL ? ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 16) >> +#define OMAP_P1_MODE_HSIC ? ? ? ? ? ? ? ? ? ? ? ? ? ?(3 << 16) >> +#define OMAP_P2_MODE_CLEAR ? ? ? ? ? ? ? ? ? ? ? ? ? (3 << 18) >> +#define OMAP_P2_MODE_TLL ? ? ? ? ? ? ? ? ? ? ? ? ? ? (1 << 18) >> +#define OMAP_P2_MODE_HSIC ? ? ? ? ? ? ? ? ? ? ? ? ? ?(3 << 18) >> + >> +/* EHCI Register Set */ >> +#define EHCI_INSNREG04_DISABLE_UNSUSPEND ? ? ? ? ? ? (1 << 5) >> +#define EHCI_INSNREG05_ULPI_CONTROL_SHIFT ? ? ? ? ? ?31 >> +#define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT ? ? ? ? ? ?24 >> +#define EHCI_INSNREG05_ULPI_OPSEL_SHIFT ? ? ? ? ? ? ? ? ? ? ?22 >> +#define EHCI_INSNREG05_ULPI_REGADD_SHIFT ? ? ? ? ? ? 16 >> + >> +#define OMAP_REV1_TLL_CHANNEL_COUNT ? ? ? ? ? ? ? ? ?3 >> +#define OMAP_REV2_TLL_CHANNEL_COUNT ? ? ? ? ? ? ? ? ?2 >> + >> +/* TLL Register Set */ >> +#define OMAP_TLL_CHANNEL_CONF(num) ? ? ? ? ? ? ? ? ? (0x004 * num) >> +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS ? ? ? ? ? ? ? ? ? ? ? ?(1 << 16) >> +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS ? ? ? ? ? ? ? ? ? ? ? (1 << 15) >> +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF ? ? ? ? (1 << 11) >> +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI ? ? ?(2 << 1) >> +#define OMAP_TLL_CHANNEL_CONF_CHANEN ? ? ? ? ? ? ? ? 1 >> + >> +/* ULPI */ >> +#define ULPI_SET(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 1) > > This is the offset of each "set" register of ULPI PHY > >> +#define ULPI_CLR(a) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(a + 2) > > This is the offset of each "clear" register of ULPI PHY > >> +#define ULPI_FUNC_CTRL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x04 > > This is the offset of the "Function Control register" of the ULPI PHY > This is already defined as ulpi_regs.function_ctrl member in > include/usb/ulpi.h file. > >> +#define ULPI_FUNC_CTRL_RESET ? ? ? ? ? ? ? ? ? ? ? ? (1 << 5) > > This is the reset bin inside the "Function Control register" of the ULPI PHY > This bit is already defined in the include/usb/ulpi.h file. > yes but these are not dedicated reg maps that can be written. on omap usb host controller is coupled with tll module to compose the ULPI TLL interface and the way to speak to them is using the INSNREG05_ULPI which has the reg address field and value to be written. ulpi framework needs a full reg map to read write registers. [..] ulpi_write(ulpi_viewport, &ulpi->function_ctrl_set, ULPI_FC_RESET); [..] from above code snip what we need is dedicated ulpi reg start address to get func ctrl. so these api's cannot be used. >> + >> +struct omap_usbhs_board_data { >> + ? ? enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; >> +}; >> + >> +struct omap_usbtll { >> + ? ? u32 rev; ? ? ? ? ? ? ? ?/* 0x00 */ >> + ? ? u32 hwinfo; ? ? ? ? ? ? /* 0x04 */ >> + ? ? u8 reserved1[0x8]; >> + ? ? u32 sysc; ? ? ? ? ? ? ? /* 0x10 */ [...] >> +} >> + >> +static void omap_ehci_soft_phy_reset(int port) >> +{ >> + ? ? unsigned int reg = 0; >> + ? ? unsigned long init = get_timer(0); >> + >> + ? ? /* FUNCTION_CTRL_SET register */ >> + ? ? reg = ULPI_FUNC_CTRL_RESET | >> + ? ? ? ? ? ? (ULPI_SET(ULPI_FUNC_CTRL) << EHCI_INSNREG05_ULPI_REGADD_SHIFT) | >> + ? ? ? ? ? ? (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) | >> + ? ? ? ? ? ? ((port + 1) << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) | >> + ? ? ? ? ? ? (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT); >> + >> + ? ? writel(reg, &ehci->insreg05_utmi_ulpi); >> + >> + ? ? /* Wait for ULPI access completion */ >> + ? ? while ((readl(&ehci->insreg05_utmi_ulpi) & >> + ? ? ? ? ? ? ? ? ? ? (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) >> + ? ? ? ? ? ? if (get_timer(init) > CONFIG_SYS_HZ) { >> + ? ? ? ? ? ? ? ? ? ? debug("OMAP EHCI error: timeout resetting phy\n"); >> + ? ? ? ? ? ? ? ? ? ? break; >> + ? ? ? ? ? ? } >> +} > > Ok, this function is kind of "duplication" of the ULPI code. > ulpi_reset() function in drivers/usb/ulpi/ulpi.c provides an implementation > of the ULPI spec. and should be used by the drivers. > What it lacks currently, is a way to pass a port number to the viewport > implementation and of course the omap-ulpi-viewport(.c) implementation itself... > So, IMO, the right way would be to implement ULPI accessors (omap-ulpi-viewport.c) so you mean add omap-ulpi-viewport.c which will do ulpi read writes for ulpi implementation within tll module of omap host controller. we just need func reset to be done for ulpi which is done using ehci register INSNREG05_ULPI. IMHO I don't see any use case or true requirement of omap-ulpi-viewport.c framework. > and add an ability to pass some kind of private data to the viewport, which > in case of OMAP will be the port number. > > Now, I know, that this will add much more code then this function does, but > it is always about using frameworks, otherwise each board file can implement > the whole U-Boot startup.... > > + >> ?inline int __board_usb_init(void) >> ?{ >> ? ? ? return 0; >> @@ -72,31 +151,31 @@ static inline void omap_ehci_phy_reset(int on, int delay) >> ?#endif >> >> ?/* Reset is needed otherwise the kernel-driver will throw an error. */ >> -int ehci_hcd_stop(void) >> +int omap_ehci_hcd_stop(void) >> ?{ >> - ? ? debug("Resetting OMAP3 EHCI\n"); >> + ? ? debug("Resetting OMAP EHCI\n"); >> ? ? ? omap_ehci_phy_reset(1, 0); >> - ? ? writel(OMAP_UHH_SYSCONFIG_SOFTRESET, >> - ? ? ? ? ? ? ? ? ? ? OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); >> - ? ? /* disable USB clocks */ >> - ? ? struct prcm *prcm_base = (struct prcm *)PRCM_BASE; >> - ? ? sr32(&prcm_base->iclken_usbhost, 0, 1, 0); >> - ? ? sr32(&prcm_base->fclken_usbhost, 0, 2, 0); >> - ? ? sr32(&prcm_base->iclken3_core, 2, 1, 0); >> - ? ? sr32(&prcm_base->fclken3_core, 2, 1, 0); >> + >> + ? ? if (omap_uhh_reset() < 0) >> + ? ? ? ? ? ? return -1; >> + >> + ? ? if (omap_ehci_tll_reset() < 0) >> + ? ? ? ? ? ? return -1; >> + >> ? ? ? return 0; >> ?} >> >> ?/* >> - * Initialize the OMAP3 EHCI controller and PHY. >> - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. >> + * Initialize the OMAP EHCI controller and PHY. >> + * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 >> ? * See there for additional Copyrights. >> ? */ >> -int ehci_hcd_init(void) >> +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) >> ?{ >> - ? ? int ret; >> + ? ? int ret = 0; >> + ? ? unsigned int i, reg = 0, rev = 0, tll_cnt = 0; >> >> - ? ? debug("Initializing OMAP3 EHCI\n"); >> + ? ? debug("Initializing OMAP EHCI\n"); >> >> ? ? ? ret = board_usb_init(); >> ? ? ? if (ret < 0) >> @@ -105,52 +184,89 @@ int ehci_hcd_init(void) >> ? ? ? /* Put the PHY in RESET */ >> ? ? ? omap_ehci_phy_reset(1, 10); >> >> - ? ? struct prcm *prcm_base = (struct prcm *)PRCM_BASE; >> - ? ? /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ >> - ? ? sr32(&prcm_base->iclken_usbhost, 0, 1, 1); >> - ? ? /* >> - ? ? ?* Enable USBHOST_48M_FCLK (USBHOST_FCLK1) >> - ? ? ?* and USBHOST_120M_FCLK (USBHOST_FCLK2) >> - ? ? ?*/ >> - ? ? sr32(&prcm_base->fclken_usbhost, 0, 2, 3); >> - ? ? /* Enable USBTTL_ICLK */ >> - ? ? sr32(&prcm_base->iclken3_core, 2, 1, 1); >> - ? ? /* Enable USBTTL_FCLK */ >> - ? ? sr32(&prcm_base->fclken3_core, 2, 1, 1); >> - ? ? debug("USB clocks enabled\n"); >> + ? ? ret = omap_uhh_reset(); >> + ? ? if (ret < 0) >> + ? ? ? ? ? ? return ret; >> >> - ? ? /* perform TLL soft reset, and wait until reset is complete */ >> - ? ? writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, >> - ? ? ? ? ? ? OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); >> - ? ? /* Wait for TLL reset to complete */ >> - ? ? while (!(readl(OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSSTATUS) >> - ? ? ? ? ? ? ? ? ? ? & OMAP_USBTLL_SYSSTATUS_RESETDONE)) >> - ? ? ? ? ? ? ; >> - ? ? debug("TLL reset done\n"); >> + ? ? ret = omap_ehci_tll_reset(); >> + ? ? if (ret) >> + ? ? ? ? ? ? return ret; > > You do both resets unconditionally, shouldn't you check which mode > the port is in and only reset the right one? > Is it because all of them need to be configurred? > yes, and to set sys_config register settings. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-19 8:15 ` Govindraj @ 2012-01-22 12:20 ` Igor Grinberg 2012-01-25 9:04 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Igor Grinberg @ 2012-01-22 12:20 UTC (permalink / raw) To: u-boot On 01/19/12 10:15, Govindraj wrote: > On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> Hi Govindraj, >> >> On 01/17/12 08:10, Govindraj wrote: >>> >>> And just to clarify further there is no code duplication for ulpi read writes >>> in ehci-omap.c done with this patch. >> >> This is not just about code duplication, >> this is also about using the ULPI framework instead of direct writes to the >> ULPI PHYs. >> >>> Patch intends only in configuring ehci to right modes as specified by >>> board file. Modes possible are hsic_mode, tll_mode, ulpi_phy mode. >>> >>> This patch is derived with reference to linux kernel and even there >>> we can see that no ulpi_reg map registers are used and only ehci >>> is configured is respective mode as passed by board data. >> >> This is not correct. They are used, see: >> drivers/usb/host/ehci-omap.c file, omap_ehci_soft_phy_reset() function. >> It does exactly the same, but yes it does not use the ULPI framework, >> because in Linux currently, there is no generic enough ULPI framework, >> so drivers can use it. > > linux-2.6/drivers/usb/otg/ulpi.c ? No, this is a kind of attempt to implement the ULPI framework, but not really a good one... and that is the reason why no driver inside drivers/usb/otg/ is using it... > >> There were discussions about it and decided that until there is such >> a framework, things can be done the way they are. >> >>> >>> Here [1] is the patch fixing Marek Vasut <marek.vasut@gmail.com> >>> comments. >>> >>> This corrected patch along with dependent patch from >>> Ilya Yanok <yanok@emcraft.com> >>> [PATCH V4 1/2] ehci-omap: driver for EHCI host on OMAP3 >>> >>> Is available here: >>> git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap >>> >>> -- >>> Thanks, >>> Govindraj.R >>> >>> [1]: >>> >>> >From 56b1b94128495ed4bf83e2f20f3884833e2aa082 Mon Sep 17 00:00:00 2001 >>> From: "Govindraj.R" <govindraj.raja@ti.com> >>> Date: Tue, 27 Dec 2011 14:53:12 +0530 >>> Subject: [PATCH 2/6] ehci-omap: Clean up added ehci-omap.c >>> >>> Clean up added ehci-omap.c and make it generic for re-use across >>> soc having same ehci ip block. Also pass the modes to be configured >>> and configure the ports accordingly. All usb layers are not cache >>> aligned till then keep cache off for usb ops as ehci will use >>> internally dma for all usb ops. >>> >>> * Add a generic common header ehci-omap.h having common ip block >>> data and reg shifts. >>> * Rename and modify ehci-omap3 to ehci.h retain only conflicting >>> sysc reg shifts remove others and move to common header file. >>> >>> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> >>> --- >>> arch/arm/include/asm/arch-omap3/ehci.h | 55 ++++++ >>> arch/arm/include/asm/arch-omap3/ehci_omap3.h | 58 ------- >>> arch/arm/include/asm/arch-omap4/ehci.h | 49 ++++++ >>> arch/arm/include/asm/ehci-omap.h | 147 +++++++++++++++++ >>> drivers/usb/host/ehci-omap.c | 228 +++++++++++++++++++------- >>> 5 files changed, 423 insertions(+), 114 deletions(-) >>> create mode 100644 arch/arm/include/asm/arch-omap3/ehci.h >>> delete mode 100644 arch/arm/include/asm/arch-omap3/ehci_omap3.h >>> create mode 100644 arch/arm/include/asm/arch-omap4/ehci.h >>> create mode 100644 arch/arm/include/asm/ehci-omap.h >>> >>> diff --git a/arch/arm/include/asm/arch-omap3/ehci.h >>> b/arch/arm/include/asm/arch-omap3/ehci.h >>> new file mode 100644 >>> index 0000000..d622363 >>> --- /dev/null >>> +++ b/arch/arm/include/asm/arch-omap3/ehci.h >>> @@ -0,0 +1,55 @@ >>> +/* >>> + * (C) Copyright 2011 >>> + * Alexander Holler <holler@ahsoftware.de> >>> + * >>> + * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 >>> + * >>> + * See there for additional Copyrights. >>> + * >>> + * See file CREDITS for list of people who contributed to this >>> + * project. >>> + * >>> + * 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., 51 Franklin Street, Fifth Floor, Boston, >>> + * MA 02110-1301 USA >>> + */ >>> +#ifndef _EHCI_H_ >>> +#define _EHCI_H_ >> >> hmmm... isn't it too generic? >> I think you should have included a part of the path to the file, >> so no namespace collision will occure. >> something like _OMAP3_EHCI_H_? >> > > since these include's are part of arch folder > will not collide with other ones. > > But still its better to have _OMAP3_EHCI_H_ > > will correct this. > > >>> + >>> +/* USB/EHCI registers */ >>> +#define OMAP_USBTLL_BASE 0x48062000UL >>> +#define OMAP_UHH_BASE 0x48064000UL >>> +#define OMAP_EHCI_BASE 0x48064800UL >>> + >>> +/* TLL Register Set */ >>> +#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) >>> +#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) >>> +#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) >>> +#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) >>> +#define OMAP_USBTLL_SYSSTATUS_RESETDONE 1 >>> + >>> +/* UHH Register Set */ >>> +#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) >>> +#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) >>> +#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) >>> +#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) >>> +#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) >>> +#define OMAP_UHH_SYSSTATUS_EHCI_RESETDONE (1 << 2) >>> + >>> +#define OMAP_UHH_SYSCONFIG_VAL (OMAP_UHH_SYSCONFIG_CACTIVITY | \ >>> + OMAP_UHH_SYSCONFIG_SIDLEMODE | \ >>> + OMAP_UHH_SYSCONFIG_ENAWAKEUP | \ >>> + OMAP_UHH_SYSCONFIG_MIDLEMODE) >>> + >>> +#endif /* _EHCI_H_ */ >>> diff --git a/arch/arm/include/asm/arch-omap3/ehci_omap3.h >>> b/arch/arm/include/asm/arch-omap3/ehci_omap3.h >>> deleted file mode 100644 >>> index cd01f50..0000000 >>> --- a/arch/arm/include/asm/arch-omap3/ehci_omap3.h >>> +++ /dev/null >>> @@ -1,58 +0,0 @@ >>> -/* >>> - * (C) Copyright 2011 >>> - * Alexander Holler <holler@ahsoftware.de> >>> - * >>> - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37 >>> - * >>> - * See there for additional Copyrights. >>> - * >>> - * See file CREDITS for list of people who contributed to this >>> - * project. >>> - * >>> - * 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., 51 Franklin Street, Fifth Floor, Boston, >>> - * MA 02110-1301 USA >>> - */ >>> -#ifndef _EHCI_OMAP3_H_ >>> -#define _EHCI_OMAP3_H_ >>> - >>> -/* USB/EHCI registers */ >>> -#define OMAP3_USBTLL_BASE 0x48062000UL >>> -#define OMAP3_UHH_BASE 0x48064000UL >>> -#define OMAP3_EHCI_BASE 0x48064800UL >>> - >>> -/* TLL Register Set */ >>> -#define OMAP_USBTLL_SYSCONFIG (0x10) >>> -#define OMAP_USBTLL_SYSCONFIG_SOFTRESET (1 << 1) >>> -#define OMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 << 2) >>> -#define OMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 << 3) >>> -#define OMAP_USBTLL_SYSCONFIG_CACTIVITY (1 << 8) >>> - >>> -#define OMAP_USBTLL_SYSSTATUS (0x14) >>> -#define OMAP_USBTLL_SYSSTATUS_RESETDONE (1 << 0) >>> - >>> -/* UHH Register Set */ >>> -#define OMAP_UHH_SYSCONFIG (0x10) >>> -#define OMAP_UHH_SYSCONFIG_SOFTRESET (1 << 1) >>> -#define OMAP_UHH_SYSCONFIG_CACTIVITY (1 << 8) >>> -#define OMAP_UHH_SYSCONFIG_SIDLEMODE (1 << 3) >>> -#define OMAP_UHH_SYSCONFIG_ENAWAKEUP (1 << 2) >>> -#define OMAP_UHH_SYSCONFIG_MIDLEMODE (1 << 12) >>> - >>> -#define OMAP_UHH_HOSTCONFIG (0x40) >>> -#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) >>> -#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) >>> -#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) >>> - >>> -#endif /* _EHCI_OMAP3_H_ */ >>> diff --git a/arch/arm/include/asm/arch-omap4/ehci.h >>> b/arch/arm/include/asm/arch-omap4/ehci.h >>> new file mode 100644 >>> index 0000000..eaa82cf >>> --- /dev/null >>> +++ b/arch/arm/include/asm/arch-omap4/ehci.h >>> @@ -0,0 +1,49 @@ >>> +/* >>> + * OMAP EHCI port support >>> + * Based on LINUX KERNEL >>> + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c >>> + * >>> + * Copyright (C) 2011 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 version 2 of >>> + * the License as published by the Free Software Foundation. >>> + * >>> + * 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, see <http://www.gnu.org/licenses/>. >>> + */ >>> + >>> +#ifndef _EHCI_H >>> +#define _EHCI_H >> >> see what I mean? above you have _EHCI_H_ and here _EHCI_H... >> That is too confusing... >> IMO, something like _OMAP4_EHCI_H_ will do here. >> > > will correct it. > > >>> + >>> +#define OMAP_EHCI_BASE (OMAP44XX_L4_CORE_BASE + 0x64C00) >>> +#define OMAP_UHH_BASE (OMAP44XX_L4_CORE_BASE + 0x64000) >>> +#define OMAP_USBTLL_BASE (OMAP44XX_L4_CORE_BASE + 0x62000) >>> + >>> +/* UHH, TLL and opt clocks */ >>> +#define CM_L3INIT_HSUSBHOST_CLKCTRL 0x4A009358UL >>> + >>> +#define HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK (1 << 24) >>> + >>> +/* 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 >>> new file mode 100644 >>> index 0000000..ac68db7 >>> --- /dev/null >>> +++ b/arch/arm/include/asm/ehci-omap.h >>> @@ -0,0 +1,147 @@ >>> +/* >>> + * OMAP EHCI port support >>> + * Based on LINUX KERNEL >>> + * drivers/usb/host/ehci-omap.c and drivers/mfd/omap-usb-host.c >>> + * >>> + * Copyright (C) 2011 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 version 2 of >>> + * the License as published by the Free Software Foundation. >>> + * >>> + * 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, see <http://www.gnu.org/licenses/>. >>> + */ >>> + >>> +#ifndef EHCI_H >>> +#define EHCI_H >> >> And even worth... now there are three of them!!! >> No, this is not good... what about OMAP5 will it be EHCI__H? >> Probably here, something like _OMAP_COMMON_EHCI_H_ will do? >> > > sure will do it. > >>> + >>> +enum usbhs_omap_port_mode { >>> + OMAP_USBHS_PORT_MODE_UNUSED, >>> + OMAP_EHCI_PORT_MODE_PHY, >>> + OMAP_EHCI_PORT_MODE_TLL, >>> + OMAP_EHCI_PORT_MODE_HSIC, >>> +}; >>> + >>> +#ifdef CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >>> +#define OMAP_HS_USB_PORTS CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS >>> +#else >>> +#define OMAP_HS_USB_PORTS 3 >>> +#endif >>> + >>> +#define is_ehci_phy_mode(x) ((x) == OMAP_EHCI_PORT_MODE_PHY) >>> +#define is_ehci_tll_mode(x) ((x) == OMAP_EHCI_PORT_MODE_TLL) >>> +#define is_ehci_hsic_mode(x) ((x) == OMAP_EHCI_PORT_MODE_HSIC) >>> + >>> +/* Values of UHH_REVISION - Note: these are not given in the TRM */ >>> +#define OMAP_USBHS_REV1 0x00000010 /* OMAP3 */ >>> +#define OMAP_USBHS_REV2 0x50700100 /* OMAP4 */ >>> + >>> +/* UHH Register Set */ >>> +#define OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN (1 << 2) >>> +#define OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN (1 << 3) >>> +#define OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN (1 << 4) >>> +#define OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN (1 << 5) >>> + >>> +#define OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS 1 >>> +#define OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS (1 << 11) >>> +#define OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS (1 << 12) >>> +#define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1 << 31) >>> + >>> +#define OMAP_P1_MODE_CLEAR (3 << 16) >>> +#define OMAP_P1_MODE_TLL (1 << 16) >>> +#define OMAP_P1_MODE_HSIC (3 << 16) >>> +#define OMAP_P2_MODE_CLEAR (3 << 18) >>> +#define OMAP_P2_MODE_TLL (1 << 18) >>> +#define OMAP_P2_MODE_HSIC (3 << 18) >>> + >>> +/* EHCI Register Set */ >>> +#define EHCI_INSNREG04_DISABLE_UNSUSPEND (1 << 5) >>> +#define EHCI_INSNREG05_ULPI_CONTROL_SHIFT 31 >>> +#define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT 24 >>> +#define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22 >>> +#define EHCI_INSNREG05_ULPI_REGADD_SHIFT 16 >>> + >>> +#define OMAP_REV1_TLL_CHANNEL_COUNT 3 >>> +#define OMAP_REV2_TLL_CHANNEL_COUNT 2 >>> + >>> +/* TLL Register Set */ >>> +#define OMAP_TLL_CHANNEL_CONF(num) (0x004 * num) >>> +#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 << 16) >>> +#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 << 15) >>> +#define OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF (1 << 11) >>> +#define OMAP_TLL_CHANNEL_CONF_CHANMODE_TRANSPARENT_UTMI (2 << 1) >>> +#define OMAP_TLL_CHANNEL_CONF_CHANEN 1 >>> + >>> +/* ULPI */ >>> +#define ULPI_SET(a) (a + 1) >> >> This is the offset of each "set" register of ULPI PHY >> >>> +#define ULPI_CLR(a) (a + 2) >> >> This is the offset of each "clear" register of ULPI PHY >> >>> +#define ULPI_FUNC_CTRL 0x04 >> >> This is the offset of the "Function Control register" of the ULPI PHY >> This is already defined as ulpi_regs.function_ctrl member in >> include/usb/ulpi.h file. >> >>> +#define ULPI_FUNC_CTRL_RESET (1 << 5) >> >> This is the reset bin inside the "Function Control register" of the ULPI PHY >> This bit is already defined in the include/usb/ulpi.h file. >> > > yes but these are not dedicated reg maps that can be written. Well, they are, but over the ULPI... just like "any" other bus... > > on omap usb host controller is coupled with tll module to compose the > ULPI TLL interface > and the way to speak to them is using the INSNREG05_ULPI which has the > reg address field > and value to be written. > > ulpi framework needs a full reg map to read write registers. No, the reg map is virtual and is supplied as the register offset: U-Boot: line 38 in drivers/usb/ulpi/ulpi.c: static struct ulpi_regs *ulpi = (struct ulpi_regs *)0; > > [..] > > ulpi_write(ulpi_viewport, > &ulpi->function_ctrl_set, ULPI_FC_RESET); > > [..] > > from above code snip what we need is dedicated ulpi reg start address > to get func ctrl. No you don't. As I've already said, it is virtual (e.g. 0x0). Current ULPI framework deals with it, after adding the ability to specify the port number, you will only need to call the correct API function, in your case the ulpi_reset(). > > so these api's cannot be used. It can be used, but the port number needs to be passed. > >>> + >>> +struct omap_usbhs_board_data { >>> + enum usbhs_omap_port_mode port_mode[OMAP_HS_USB_PORTS]; >>> +}; >>> + >>> +struct omap_usbtll { >>> + u32 rev; /* 0x00 */ >>> + u32 hwinfo; /* 0x04 */ >>> + u8 reserved1[0x8]; >>> + u32 sysc; /* 0x10 */ > > [...] > >>> +} >>> + >>> +static void omap_ehci_soft_phy_reset(int port) >>> +{ >>> + unsigned int reg = 0; >>> + unsigned long init = get_timer(0); >>> + >>> + /* FUNCTION_CTRL_SET register */ >>> + reg = ULPI_FUNC_CTRL_RESET | >>> + (ULPI_SET(ULPI_FUNC_CTRL) << EHCI_INSNREG05_ULPI_REGADD_SHIFT) | >>> + (2 << EHCI_INSNREG05_ULPI_OPSEL_SHIFT) | >>> + ((port + 1) << EHCI_INSNREG05_ULPI_PORTSEL_SHIFT) | >>> + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT); >>> + >>> + writel(reg, &ehci->insreg05_utmi_ulpi); >>> + >>> + /* Wait for ULPI access completion */ >>> + while ((readl(&ehci->insreg05_utmi_ulpi) & >>> + (1 << EHCI_INSNREG05_ULPI_CONTROL_SHIFT))) >>> + if (get_timer(init) > CONFIG_SYS_HZ) { >>> + debug("OMAP EHCI error: timeout resetting phy\n"); >>> + break; >>> + } >>> +} >> >> Ok, this function is kind of "duplication" of the ULPI code. >> ulpi_reset() function in drivers/usb/ulpi/ulpi.c provides an implementation >> of the ULPI spec. and should be used by the drivers. >> What it lacks currently, is a way to pass a port number to the viewport >> implementation and of course the omap-ulpi-viewport(.c) implementation itself... >> So, IMO, the right way would be to implement ULPI accessors (omap-ulpi-viewport.c) > > so you mean add omap-ulpi-viewport.c which will do ulpi read writes > for ulpi implementation > within tll module of omap host controller. No. What I meant is that omap-ulpi-viewport.c will do the ULPI access to the PHY (which is not TLL), but after the above question, I think it can do both: TLL and non-TLL. > > we just need func reset to be done for ulpi which is done using ehci register > INSNREG05_ULPI. IMHO I don't see any use case or true requirement of > omap-ulpi-viewport.c framework. The fact that the reset is done by writing the ULPI_FUNC_CTRL_RESET bit of the ULPI_FUNC_CTRL register - is the requirement... For example tomorrow, you will find out that besides reset, you also need to set some other bit in a register inside the ULPI PHY (e.g. VBUS), so you will implement another "ehci" function that will do a write to ULPI and thus duplicate another portion of code... > >> and add an ability to pass some kind of private data to the viewport, which >> in case of OMAP will be the port number. >> >> Now, I know, that this will add much more code then this function does, but >> it is always about using frameworks, otherwise each board file can implement >> the whole U-Boot startup.... >> >> + >>> inline int __board_usb_init(void) >>> { >>> return 0; >>> @@ -72,31 +151,31 @@ static inline void omap_ehci_phy_reset(int on, int delay) >>> #endif >>> >>> /* Reset is needed otherwise the kernel-driver will throw an error. */ >>> -int ehci_hcd_stop(void) >>> +int omap_ehci_hcd_stop(void) >>> { >>> - debug("Resetting OMAP3 EHCI\n"); >>> + debug("Resetting OMAP EHCI\n"); >>> omap_ehci_phy_reset(1, 0); >>> - writel(OMAP_UHH_SYSCONFIG_SOFTRESET, >>> - OMAP3_UHH_BASE + OMAP_UHH_SYSCONFIG); >>> - /* disable USB clocks */ >>> - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; >>> - sr32(&prcm_base->iclken_usbhost, 0, 1, 0); >>> - sr32(&prcm_base->fclken_usbhost, 0, 2, 0); >>> - sr32(&prcm_base->iclken3_core, 2, 1, 0); >>> - sr32(&prcm_base->fclken3_core, 2, 1, 0); >>> + >>> + if (omap_uhh_reset() < 0) >>> + return -1; >>> + >>> + if (omap_ehci_tll_reset() < 0) >>> + return -1; >>> + >>> return 0; >>> } >>> >>> /* >>> - * Initialize the OMAP3 EHCI controller and PHY. >>> - * Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. >>> + * Initialize the OMAP EHCI controller and PHY. >>> + * Based on "drivers/usb/host/ehci-omap.c" from Linux 3.1 >>> * See there for additional Copyrights. >>> */ >>> -int ehci_hcd_init(void) >>> +int omap_ehci_hcd_init(struct omap_usbhs_board_data *usbhs_pdata) >>> { >>> - int ret; >>> + int ret = 0; >>> + unsigned int i, reg = 0, rev = 0, tll_cnt = 0; >>> >>> - debug("Initializing OMAP3 EHCI\n"); >>> + debug("Initializing OMAP EHCI\n"); >>> >>> ret = board_usb_init(); >>> if (ret < 0) >>> @@ -105,52 +184,89 @@ int ehci_hcd_init(void) >>> /* Put the PHY in RESET */ >>> omap_ehci_phy_reset(1, 10); >>> >>> - struct prcm *prcm_base = (struct prcm *)PRCM_BASE; >>> - /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ >>> - sr32(&prcm_base->iclken_usbhost, 0, 1, 1); >>> - /* >>> - * Enable USBHOST_48M_FCLK (USBHOST_FCLK1) >>> - * and USBHOST_120M_FCLK (USBHOST_FCLK2) >>> - */ >>> - sr32(&prcm_base->fclken_usbhost, 0, 2, 3); >>> - /* Enable USBTTL_ICLK */ >>> - sr32(&prcm_base->iclken3_core, 2, 1, 1); >>> - /* Enable USBTTL_FCLK */ >>> - sr32(&prcm_base->fclken3_core, 2, 1, 1); >>> - debug("USB clocks enabled\n"); >>> + ret = omap_uhh_reset(); >>> + if (ret < 0) >>> + return ret; >>> >>> - /* perform TLL soft reset, and wait until reset is complete */ >>> - writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, >>> - OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); >>> - /* Wait for TLL reset to complete */ >>> - while (!(readl(OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSSTATUS) >>> - & OMAP_USBTLL_SYSSTATUS_RESETDONE)) >>> - ; >>> - debug("TLL reset done\n"); >>> + ret = omap_ehci_tll_reset(); >>> + if (ret) >>> + return ret; >> >> You do both resets unconditionally, shouldn't you check which mode >> the port is in and only reset the right one? >> Is it because all of them need to be configurred? >> > > yes, and to set sys_config register settings. Ok. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-22 12:20 ` Igor Grinberg @ 2012-01-25 9:04 ` Govindraj 2012-01-25 13:40 ` Igor Grinberg 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-25 9:04 UTC (permalink / raw) To: u-boot Hi Igor, On Sun, Jan 22, 2012 at 5:50 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > On 01/19/12 10:15, Govindraj wrote: >> On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>> Hi Govindraj, >>> >>> On 01/17/12 08:10, Govindraj wrote: >>>> [...] >>>> + ? ? ? ? ? ? if (get_timer(init) > CONFIG_SYS_HZ) { >>>> + ? ? ? ? ? ? ? ? ? ? debug("OMAP EHCI error: timeout resetting phy\n"); >>>> + ? ? ? ? ? ? ? ? ? ? break; >>>> + ? ? ? ? ? ? } >>>> +} >>> >>> Ok, this function is kind of "duplication" of the ULPI code. >>> ulpi_reset() function in drivers/usb/ulpi/ulpi.c provides an implementation >>> of the ULPI spec. and should be used by the drivers. >>> What it lacks currently, is a way to pass a port number to the viewport >>> implementation and of course the omap-ulpi-viewport(.c) implementation itself... >>> So, IMO, the right way would be to implement ULPI accessors (omap-ulpi-viewport.c) >> >> so you mean add omap-ulpi-viewport.c which will do ulpi read writes >> for ulpi implementation >> within tll module of omap host controller. > > No. What I meant is that omap-ulpi-viewport.c will do the ULPI access > to the PHY (which is not TLL), but after the above question, I think > it can do both: TLL and non-TLL. > >> >> we just need func reset to be done for ulpi which is done using ehci register >> INSNREG05_ULPI. IMHO I don't see any use case or true requirement of >> omap-ulpi-viewport.c framework. > > The fact that the reset is done by writing the ULPI_FUNC_CTRL_RESET bit > of the ULPI_FUNC_CTRL register - is the requirement... > For example tomorrow, you will find out that besides reset, you also need > to set some other bit in a register inside the ULPI PHY (e.g. VBUS), so > you will implement another "ehci" function that will do a write to ULPI > and thus duplicate another portion of code... > >> >>> and add an ability to pass some kind of private data to the viewport, which >>> in case of OMAP will be the port number. I started on adding omap-ulpi-viewport.c which will work with ulpi.c if omap_ehci.c is used. for port id can we just set a global data field that will inform the omap_view port on the port id, or we have to modify most api's syntax in "drivers/usb/ulpi/ulpi.c" Is it okay to have the port id from ehci-omap.c set and used in "drivers/usb/ulpi/omap-ulpi-viewport.c" ? -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-25 9:04 ` Govindraj @ 2012-01-25 13:40 ` Igor Grinberg 2012-01-27 13:29 ` Govindraj 0 siblings, 1 reply; 40+ messages in thread From: Igor Grinberg @ 2012-01-25 13:40 UTC (permalink / raw) To: u-boot Hi Govindraj, On 01/25/12 11:04, Govindraj wrote: > Hi Igor, > > On Sun, Jan 22, 2012 at 5:50 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> On 01/19/12 10:15, Govindraj wrote: >>> On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>>> Hi Govindraj, >>>> >>>> On 01/17/12 08:10, Govindraj wrote: >>>>> [...] >>>> and add an ability to pass some kind of private data to the viewport, which >>>> in case of OMAP will be the port number. > > > I started on adding omap-ulpi-viewport.c which will work with ulpi.c > if omap_ehci.c is used. Good! Thanks for working on that. > > for port id can we just set a global data field that will inform the > omap_view port > on the port id, or we have to modify most api's syntax in > "drivers/usb/ulpi/ulpi.c" IMO, we should modify the API, because it does not make sense to use the generic layer, but workaround some missing feature... My suggestion for the change is: 1) introduce some kind of struct ulpi_viewport { u32 viewport_addr; uint portnum; } 2) use the above struct _instead_ of the "u32 ulpi_viewport" parameter Another way, would be instead of uint portnum, use void *private_data, but I think it will just complicate things too much and there will be no real benefit (and also will add, otherwise needless, castings). If the above structure will not be enough for some platform, it can be extended easily and without changing the API anymore. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-25 13:40 ` Igor Grinberg @ 2012-01-27 13:29 ` Govindraj 2012-01-29 9:42 ` Igor Grinberg 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-01-27 13:29 UTC (permalink / raw) To: u-boot On Wed, Jan 25, 2012 at 7:10 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Govindraj, > > On 01/25/12 11:04, Govindraj wrote: >> Hi Igor, >> >> On Sun, Jan 22, 2012 at 5:50 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>> On 01/19/12 10:15, Govindraj wrote: >>>> On Wed, Jan 18, 2012 at 11:21 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>>>> Hi Govindraj, >>>>> >>>>> On 01/17/12 08:10, Govindraj wrote: >>>>>> > > [...] > >>>>> and add an ability to pass some kind of private data to the viewport, which >>>>> in case of OMAP will be the port number. >> >> >> I started on adding omap-ulpi-viewport.c which will work with ulpi.c >> if omap_ehci.c is used. > > Good! Thanks for working on that. > >> >> for port id can we just set a global data field that will inform the >> omap_view port >> on the port id, or we have to modify most api's syntax in >> "drivers/usb/ulpi/ulpi.c" > > IMO, we should modify the API, because it does not make sense > to use the generic layer, but workaround some missing feature... > > My suggestion for the change is: > 1) introduce some kind of > struct ulpi_viewport { > ? ? ? ?u32 viewport_addr; > ? ? ? ?uint portnum; > } > > 2) use the above struct _instead_ of the "u32 ulpi_viewport" parameter > > Another way, would be instead of uint portnum, use void *private_data, > but I think it will just complicate things too much and there will be no > real benefit (and also will add, otherwise needless, castings). > If the above structure will not be enough for some platform, > it can be extended easily and without changing the API anymore. > Thanks for the suggestions. Here [1] is the first attempt to implement the same. sorry for late reply, as I was preempted with some other work. -- Thanks, Govindraj.R [1]: ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-27 13:29 ` Govindraj @ 2012-01-29 9:42 ` Igor Grinberg 2012-01-29 11:42 ` Stefano Babic 2012-02-03 12:50 ` Govindraj 0 siblings, 2 replies; 40+ messages in thread From: Igor Grinberg @ 2012-01-29 9:42 UTC (permalink / raw) To: u-boot Hi Govindraj, Put Remy on Cc. Note: my new mail client for some reason, messes with white spaces... (Thunderbird (9) just gets better and better...) So, please ignore those. BTW, is there anyone who has those issues fixed and can save me a wasted hour? On 01/27/12 15:29, Govindraj wrote: > On Wed, Jan 25, 2012 at 7:10 PM, Igor Grinberg<grinberg@compulab.co.il> wrote: [...] >> >> My suggestion for the change is: >> 1) introduce some kind of >> struct ulpi_viewport { >> u32 viewport_addr; >> uint portnum; >> } >> >> 2) use the above struct _instead_ of the "u32 ulpi_viewport" parameter >> >> Another way, would be instead of uint portnum, use void *private_data, >> but I think it will just complicate things too much and there will be no >> real benefit (and also will add, otherwise needless, castings). >> If the above structure will not be enough for some platform, >> it can be extended easily and without changing the API anymore. >> > > Thanks for the suggestions. > > Here [1] is the first attempt to implement the same. > > sorry for late reply, as I was preempted with some other work. Thanks for the work you've done! Overall it looks very good, though several tiny comments below. > > -- > Thanks, > Govindraj.R > > [1]: > >> From 2bc311c26572aff3ebaac035106434b444692f68 Mon Sep 17 00:00:00 2001 > From: "Govindraj.R"<govindraj.raja@ti.com> > Date: Fri, 27 Jan 2012 18:34:11 +0530 > Subject: [PATCH] ulpi: Modify the ulpi framework to accept port number > > Based on discussion in the thread [1] this patch > attempts to modify the ulpi framework to accept the > port number along with view port address, adding the omap-ulpi > view port that helps us in using the generic ulpi > framework to configure ulpi phy using the INSNREG05_ULPI viewport > reg available on omap platform. Ok, I think you should split this patch to: 1) modify the ulpi framework... (this one extends the ulpi functionality and fixes current users) 2) add omap ulpi support (this one makes use of the ulpi framework on omap platforms and IMO, should amended to you original 1/4 patch: ehci-omap: Clean up added ehci-omap.c) > > Tested on beagle-xm and Panda. > Compile tested on efikamx platform. > > This patch is based on earlier posted patch series[1]. Shouldn't this be [2]? > > Prior to this patch ulpi reset was done directly now > it is done using ulpi_reset. > > Thanks to Igor Grinberg<grinberg@compulab.co.il> for reviewing the > omap-ehci patches and suggesting this approach. > > This patch along with the patch series [1] rebased on latest u-boot Probably same here, or am I mistaken? > is available here. > git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4 > > [1]: http://www.mail-archive.com/u-boot at lists.denx.de/msg76076.html > [2]: "[PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs" > > Signed-off-by: Govindraj.R<govindraj.raja@ti.com> > --- > board/efikamx/efikamx-usb.c | 21 ++++--- > drivers/usb/host/ehci-omap.c | 21 ++----- > drivers/usb/ulpi/Makefile | 1 + > drivers/usb/ulpi/omap-ulpi-viewport.c | 110 +++++++++++++++++++++++++++++++++ > drivers/usb/ulpi/ulpi-viewport.c | 30 +++++----- > drivers/usb/ulpi/ulpi.c | 54 ++++++++-------- > include/configs/omap3_beagle.h | 3 + > include/configs/omap4_panda.h | 2 + > include/usb/ulpi.h | 37 ++++++++---- You should also, update the README file with the new CONFIG_USB_ULPI_VIEWPORT_OMAP option. (Also may be some OMAP specific doc files..) > 9 files changed, 202 insertions(+), 77 deletions(-) > create mode 100644 drivers/usb/ulpi/omap-ulpi-viewport.c > > diff --git a/board/efikamx/efikamx-usb.c b/board/efikamx/efikamx-usb.c > index 840bd9a..bb1398b 100644 > --- a/board/efikamx/efikamx-usb.c > +++ b/board/efikamx/efikamx-usb.c > @@ -120,6 +120,7 @@ static void efika_ehci_init(struct usb_ehci *ehci, > uint32_t stp_gpio, > { > int ret; > struct ulpi_regs *ulpi = (struct ulpi_regs *)0; > + struct ulpi_viewport ulpi_vp; > > mxc_request_iomux(stp_gpio, alt0); > mxc_iomux_set_pad(stp_gpio, PAD_CTL_DRV_HIGH | > @@ -133,23 +134,25 @@ static void efika_ehci_init(struct usb_ehci > *ehci, uint32_t stp_gpio, > mxc_iomux_set_pad(stp_gpio, USB_PAD_CONFIG); > udelay(10000); > > - ret = ulpi_init((u32)&ehci->ulpi_viewpoint); > + ulpi_vp.viewport_addr = (u32)&ehci->ulpi_viewpoint; here, you should also: + ulpi_vp.port_num = 0; because the ulpi_vp structure is not initialized and can have garbage in it. > + > + ret = ulpi_init(&ulpi_vp); > if (ret) { > printf("Efika USB ULPI initialization failed\n"); > return; > } > > /* ULPI set flags */ > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl, > + ulpi_write(&ulpi_vp,&ulpi->otg_ctrl, > ULPI_OTG_DP_PULLDOWN | ULPI_OTG_DM_PULLDOWN | > ULPI_OTG_EXTVBUSIND); > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->function_ctrl, > + ulpi_write(&ulpi_vp,&ulpi->function_ctrl, > ULPI_FC_FULL_SPEED | ULPI_FC_OPMODE_NORMAL | > ULPI_FC_SUSPENDM); > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->iface_ctrl, 0); > + ulpi_write(&ulpi_vp,&ulpi->iface_ctrl, 0); > > /* Set VBus */ > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, > + ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, > ULPI_OTG_DRVVBUS | ULPI_OTG_DRVVBUS_EXT); > > /* > @@ -158,7 +161,7 @@ static void efika_ehci_init(struct usb_ehci *ehci, > uint32_t stp_gpio, > * NOTE: This violates USB specification, but otherwise, USB on Efika > * doesn't work. > */ > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, > + ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, > ULPI_OTG_CHRGVBUS); This fits 80 characters, right? Can this now be on the same line? > } > > @@ -177,9 +180,11 @@ void ehci_powerup_fixup(uint32_t *status_reg, > uint32_t *reg) > uint32_t port = OTG_BASE_ADDR + (0x200 * CONFIG_MXC_USB_PORT); > struct usb_ehci *ehci = (struct usb_ehci *)port; > struct ulpi_regs *ulpi = (struct ulpi_regs *)0; > + struct ulpi_viewport ulpi_vp; > > - ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, > - ULPI_OTG_CHRGVBUS); > + ulpi_vp.viewport_addr = (u32)&ehci->ulpi_viewpoint; same here: + ulpi_vp.port_num = 0; > + > + ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, ULPI_OTG_CHRGVBUS); > > wait_ms(50); > [...] > diff --git a/drivers/usb/ulpi/Makefile b/drivers/usb/ulpi/Makefile > index d43b229..67d5e5e 100644 > --- a/drivers/usb/ulpi/Makefile > +++ b/drivers/usb/ulpi/Makefile > @@ -24,6 +24,7 @@ LIB := $(obj)libusb_ulpi.o > > COBJS-$(CONFIG_USB_ULPI) += ulpi.o > COBJS-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi-viewport.o > +COBJS-$(CONFIG_USB_OMAP_ULPI_VIEWPORT) += omap-ulpi-viewport.o IMO, CONFIG_USB_ULPI_VIEWPORT_OMAP will look better here, but you can leave it as it is - it does not really meter. > > COBJS := $(COBJS-y) > SRCS := $(COBJS:.o=.c) > diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c > b/drivers/usb/ulpi/omap-ulpi-viewport.c > new file mode 100644 > index 0000000..1718788 > --- /dev/null > +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c > @@ -0,0 +1,110 @@ [...] > +/* ULPI viewport control bits */ > +#define OMAP_ULPI_PORT_SHIFT 24 > + > +#define OMAP_ULPI_WR_OPSEL (3<< 21) > +#define OMAP_ULPI_ACCESS (1<< 31) > + > +/* > + * Wait for the ULPI Access to complete > + */ > +static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) > +{ > + int timeout = CONFIG_USB_ULPI_TIMEOUT; > + > + while (--timeout) { > + if ((readl(ulpi_vp->viewport_addr)& mask)) > + return 0; > + > + udelay(1); > + } > + > + return ULPI_ERROR; > +} > + > +/* > + * Wake the ULPI PHY up for communication > + * > + * returns 0 on success. > + */ > +static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) > +{ > + int err; > + > + if (readl(ulpi_vp->viewport_addr)& OMAP_ULPI_ACCESS) > + return 0; /* already awake */ > + > + writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr); > + > + err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); > + if (err) > + debug("ULPI wakeup timed out\n"); > + > + return err; > +} This function looks really weird... You write the OMAP_ULPI_ACCESS bit, but you don't specify the port... Now, if you will specify the port, what access type (read/write) should it be? So, I don't really know what whould be the consequence of that access... TRM does not talk about waking the ULPI PHY at all or have I missed it... I think this function is unneeded on OMAP - it looks like OMAP wakes the ULPI PHY automatically as soon as you access it for read/write, but the TRM does not talk too much on that... Have you tried without this function? Just calling ulpi_wait() to verify that the previous access has completed, should do the job, no? Can you, please, check that? > + > +/* > + * Issue a ULPI read/write request > + */ > +static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) > +{ > + int err; > + > + err = ulpi_wakeup(ulpi_vp); > + if (err) > + return err; > + > + writel(value, ulpi_vp->viewport_addr); > + > + err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); > + if (err) > + debug("ULPI request timed out\n"); > + > + return err; > +} > + > +int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) > +{ > + u32 val = (ulpi_vp->port_num<< OMAP_ULPI_PORT_SHIFT) | > + OMAP_ULPI_WR_OPSEL | > + ((u32)reg<< 16) | (value& 0xff); If you use OMAP_ULPI_PORT_SHIFT, then probably 16 should be also defined in the same way? Or... I would just drop the OMAP_ULPI_PORT_SHIFT, because it is clear that 24 is the offset of port number... Also, you should mask the port_num: ulpi_vp->port_num & 0xf as for this field is 4 bits wide. > + > + return ulpi_request(ulpi_vp, val); > +} > + > +u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) > +{ > + int err; > + u32 val = (ulpi_vp->port_num<< OMAP_ULPI_PORT_SHIFT) | > + OMAP_ULPI_WR_OPSEL | > + ((u32)reg<< 16); same here > + > + err = ulpi_request(ulpi_vp, val); > + if (err) > + return err; > + > + return readl(ulpi_vp->viewport_addr)& 0xff; > +} > diff --git a/drivers/usb/ulpi/ulpi-viewport.c b/drivers/usb/ulpi/ulpi-viewport.c > index 490fb0e..6f03f08 100644 > --- a/drivers/usb/ulpi/ulpi-viewport.c > +++ b/drivers/usb/ulpi/ulpi-viewport.c > @@ -40,13 +40,13 @@ [...] > -int ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value) > +int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) > { > u32 val = ULPI_RWRUN | ULPI_RWCTRL | ((u32)reg<< 16) | (value& 0xff); You have extended the ULPI framework - now it has support for port number... here, you should also: val |= (ulpi_vp->port_num & 0x7) << 24; (yes, 24 is the correct offset and it is 3 bits wide according to the iMX35 RM). > > - return ulpi_request(ulpi_viewport, val); > + return ulpi_request(ulpi_vp, val); > } > > -u32 ulpi_read(u32 ulpi_viewport, u8 *reg) > +u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) > { > int err; > u32 val = ULPI_RWRUN | ((u32)reg<< 16); same here > > - err = ulpi_request(ulpi_viewport, val); > + err = ulpi_request(ulpi_vp, val); > if (err) > return err; > > - return (readl(ulpi_viewport)>> 8)& 0xff; > + return (readl(ulpi_vp->viewport_addr)>> 8)& 0xff; > } > diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c > index 6202227..dde2585 100644 > --- a/drivers/usb/ulpi/ulpi.c > +++ b/drivers/usb/ulpi/ulpi.c > @@ -37,18 +37,18 @@ [...] > -int ulpi_reset(u32 ulpi_viewport) > +int ulpi_reset(struct ulpi_viewport *ulpi_vp) > { > int err; > > - err = ulpi_write(ulpi_viewport, > + err = ulpi_write(ulpi_vp, > &ulpi->function_ctrl_set, ULPI_FC_RESET); This fits 80 characters now. Please, make it on the same line. > if (err) { > printf("ULPI: %s: failed writing reset bit\n", __func__); > return err; > } > > - return ulpi_reset_wait(ulpi_viewport); > + return ulpi_reset_wait(ulpi_vp); > } > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h > index b4d6443..2183ea6 100644 > --- a/include/configs/omap3_beagle.h > +++ b/include/configs/omap3_beagle.h > @@ -130,6 +130,9 @@ > #define CONFIG_CMD_USB > #define CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_OMAP > +#define CONFIG_USB_ULPI > +#define CONFIG_USB_OMAP_ULPI_VIEWPORT > + > /*#define CONFIG_EHCI_DCACHE*/ /* leave it disabled for now */ > #define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 147 > #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 > diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h > index 23c0230..0228a66 100644 > --- a/include/configs/omap4_panda.h > +++ b/include/configs/omap4_panda.h > @@ -38,6 +38,8 @@ > #define CONFIG_USB_HOST > #define CONFIG_USB_EHCI > #define CONFIG_USB_EHCI_OMAP > +#define CONFIG_USB_ULPI > +#define CONFIG_USB_OMAP_ULPI_VIEWPORT > #define CONFIG_USB_STORAGE > #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 This also should apply for TAM3517 board. Stefano, can you test this on TAM3517? Probably Ilya is also interested in this for HTKW mcx board. Adding both to Cc. > > diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h > index 802f077..1da43ae 100644 > --- a/include/usb/ulpi.h > +++ b/include/usb/ulpi.h > @@ -28,12 +28,24 @@ > #endif > > /* > + * ulpi view port address and > + * Port_number that can be passed. > + * Any additional data to be passed can > + * be extended from this structure > + */ > +struct ulpi_viewport { > + u32 viewport_addr; > + u8 port_num; You shift this by 24 bits... Can this be u32 instead, to remove any confusion? It can also spare some alignment bugs with some compilers/linkers... > +}; > + > +/* > * Initialize the ULPI transciever and check the interface integrity. > - * @ulpi_viewport - the address of the ULPI viewport register. > + * @ulpi_viewport - structure containing the address of the ULPI viewport > + register and port number to access. Please, do not describe here the internal fields of the structure, it can be done better along with structure definition. IMO, simply: 'structure containing ULPI viewport data' should be enough. [...] -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-29 9:42 ` Igor Grinberg @ 2012-01-29 11:42 ` Stefano Babic 2012-02-01 11:01 ` Igor Grinberg 2012-02-03 12:52 ` Govindraj 2012-02-03 12:50 ` Govindraj 1 sibling, 2 replies; 40+ messages in thread From: Stefano Babic @ 2012-01-29 11:42 UTC (permalink / raw) To: u-boot On 29/01/2012 10:42, Igor Grinberg wrote: > Hi Govindraj, > Hi all, > Put Remy on Cc. Remy resigned as USB maintainer - but Tom is aware about these patches... > > Note: my new mail client for some reason, messes with white spaces... > (Thunderbird (9) just gets better and better...) I had the opposite problem - this patch from patchwork is messy. Patchworks mixed some answer with the patch and it is not appliable. But using Thunderbird 9 I had no problem... > So, please ignore those. > BTW, is there anyone who has those issues fixed and can save me a wasted > hour? I do not know exactly your problem, but I pushed my tree for TAM3517 on git.denx.de/u-boot-imx, spl_linux_twister branch Maybe this can help you >> diff --git a/include/configs/omap4_panda.h >> b/include/configs/omap4_panda.h >> index 23c0230..0228a66 100644 >> --- a/include/configs/omap4_panda.h >> +++ b/include/configs/omap4_panda.h >> @@ -38,6 +38,8 @@ >> #define CONFIG_USB_HOST >> #define CONFIG_USB_EHCI >> #define CONFIG_USB_EHCI_OMAP >> +#define CONFIG_USB_ULPI >> +#define CONFIG_USB_OMAP_ULPI_VIEWPORT >> #define CONFIG_USB_STORAGE >> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 > > This also should apply for TAM3517 board. > Stefano, can you test this on TAM3517? Tested on twister / TAM3517, I can read a USB pen. Tested-by: Stefano Babic <sbabic@denx.de> Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-29 11:42 ` Stefano Babic @ 2012-02-01 11:01 ` Igor Grinberg 2012-02-01 11:26 ` Stefano Babic 2012-02-03 12:52 ` Govindraj 1 sibling, 1 reply; 40+ messages in thread From: Igor Grinberg @ 2012-02-01 11:01 UTC (permalink / raw) To: u-boot Hi Stefano, On 01/29/12 13:42, Stefano Babic wrote: > On 29/01/2012 10:42, Igor Grinberg wrote: >> Hi Govindraj, >> > > Hi all, > >> Put Remy on Cc. > > Remy resigned as USB maintainer - but Tom is aware about these patches... Right. This patch touches the USB subsystem, therefore I put Remy in Cc. > >> >> Note: my new mail client for some reason, messes with white spaces... >> (Thunderbird (9) just gets better and better...) > > I had the opposite problem - this patch from patchwork is messy. > Patchworks mixed some answer with the patch and it is not appliable. But > using Thunderbird 9 I had no problem... > >> So, please ignore those. >> BTW, is there anyone who has those issues fixed and can save me a wasted >> hour? > > I do not know exactly your problem, but I pushed my tree for TAM3517 on > > git.denx.de/u-boot-imx, spl_linux_twister branch > > Maybe this can help you Thanks, actually it turned out to be some kind of dynamic libraries problem that Thunderbird uses (probably spelling libraries...), so reinstalling Thunderbird along with all libraries it depends on, did the trick. > >>> diff --git a/include/configs/omap4_panda.h >>> b/include/configs/omap4_panda.h >>> index 23c0230..0228a66 100644 >>> --- a/include/configs/omap4_panda.h >>> +++ b/include/configs/omap4_panda.h >>> @@ -38,6 +38,8 @@ >>> #define CONFIG_USB_HOST >>> #define CONFIG_USB_EHCI >>> #define CONFIG_USB_EHCI_OMAP >>> +#define CONFIG_USB_ULPI >>> +#define CONFIG_USB_OMAP_ULPI_VIEWPORT >>> #define CONFIG_USB_STORAGE >>> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 >> >> This also should apply for TAM3517 board. >> Stefano, can you test this on TAM3517? > > Tested on twister / TAM3517, I can read a USB pen. > > Tested-by: Stefano Babic <sbabic@denx.de> Thanks for testing! Govidraj, can the "enabling the ULPI for boards" reside in a separate patch and also include the boards that were tested with it (e.g. TAM3517)? Thanks. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-02-01 11:01 ` Igor Grinberg @ 2012-02-01 11:26 ` Stefano Babic 2012-02-01 13:22 ` Igor Grinberg 0 siblings, 1 reply; 40+ messages in thread From: Stefano Babic @ 2012-02-01 11:26 UTC (permalink / raw) To: u-boot On 01/02/2012 12:01, Igor Grinberg wrote: > Thanks for testing! > > Govidraj, can the "enabling the ULPI for boards" reside > in a separate patch and also include the boards that were > tested with it (e.g. TAM3517)? Well, this is maybe too much ;-) ... and Govidraj has no possibility to test it. I will send a patch for TAM3517 as soon as Govidraj's patches will be merged, so you do not need to worry about it ! Stefano -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-02-01 11:26 ` Stefano Babic @ 2012-02-01 13:22 ` Igor Grinberg 0 siblings, 0 replies; 40+ messages in thread From: Igor Grinberg @ 2012-02-01 13:22 UTC (permalink / raw) To: u-boot On 02/01/12 13:26, Stefano Babic wrote: > On 01/02/2012 12:01, Igor Grinberg wrote: > >> Thanks for testing! >> >> Govidraj, can the "enabling the ULPI for boards" reside >> in a separate patch and also include the boards that were >> tested with it (e.g. TAM3517)? > > Well, this is maybe too much ;-) > > ... and Govidraj has no possibility to test it. I will send a patch for > TAM3517 as soon as Govidraj's patches will be merged, so you do not need > to worry about it ! Fare enough, let it be so :) -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-29 11:42 ` Stefano Babic 2012-02-01 11:01 ` Igor Grinberg @ 2012-02-03 12:52 ` Govindraj 1 sibling, 0 replies; 40+ messages in thread From: Govindraj @ 2012-02-03 12:52 UTC (permalink / raw) To: u-boot On Sun, Jan 29, 2012 at 5:12 PM, Stefano Babic <sbabic@denx.de> wrote: > On 29/01/2012 10:42, Igor Grinberg wrote: >> Hi Govindraj, >> > > Hi all, > >> Put Remy on Cc. > > Remy resigned as USB maintainer - but Tom is aware about these patches... > >> >> Note: my new mail client for some reason, messes with white spaces... >> (Thunderbird (9) just gets better and better...) > > I had the opposite problem - this patch from patchwork is messy. > Patchworks mixed some answer with the patch and it is not appliable. But > using Thunderbird 9 I had no problem... > >> So, please ignore those. >> BTW, is there anyone who has those issues fixed and can save me a wasted >> hour? > > I do not know exactly your problem, but I pushed my tree for TAM3517 on > > ? ? ? ?git.denx.de/u-boot-imx, spl_linux_twister branch > > Maybe this can help you > >>> diff --git a/include/configs/omap4_panda.h >>> b/include/configs/omap4_panda.h >>> index 23c0230..0228a66 100644 >>> --- a/include/configs/omap4_panda.h >>> +++ b/include/configs/omap4_panda.h >>> @@ -38,6 +38,8 @@ >>> ? #define CONFIG_USB_HOST >>> ? #define CONFIG_USB_EHCI >>> ? #define CONFIG_USB_EHCI_OMAP >>> +#define CONFIG_USB_ULPI >>> +#define CONFIG_USB_OMAP_ULPI_VIEWPORT >>> ? #define CONFIG_USB_STORAGE >>> ? #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 >> >> This also should apply for TAM3517 board. >> Stefano, can you test this on TAM3517? > > Tested on twister / TAM3517, I can read a USB pen. > > Tested-by: Stefano Babic <sbabic@denx.de> Thanks for testing I have added your tested by after splitting this into two patches as per Igor Grinberg <grinberg@compulab.co.il> comments. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-29 9:42 ` Igor Grinberg 2012-01-29 11:42 ` Stefano Babic @ 2012-02-03 12:50 ` Govindraj 2012-02-03 13:18 ` Igor Grinberg 1 sibling, 1 reply; 40+ messages in thread From: Govindraj @ 2012-02-03 12:50 UTC (permalink / raw) To: u-boot Hi Igor, Sorry for late reply, Was really busy with some other tasks. On Sun, Jan 29, 2012 at 3:12 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: > Hi Govindraj, > > Put Remy on Cc. > Yes Sure, > Note: my new mail client for some reason, messes with white spaces... > (Thunderbird (9) just gets better and better...) > So, please ignore those. > BTW, is there anyone who has those issues fixed and can save me a wasted > hour? > [...] > > Ok, I think you should split this patch to: > 1) modify the ulpi framework... (this one extends the ulpi functionality > ? and fixes current users) > 2) add omap ulpi support (this one makes use of the ulpi framework > ? on omap platforms and IMO, should amended to you original > ? 1/4 patch: ehci-omap: Clean up added ehci-omap.c) Yes Correct, I have done that will be posting the complete series in short while. > > >> >> Tested on beagle-xm and Panda. >> Compile tested on efikamx platform. >> >> This patch is based on earlier posted patch series[1]. > > > Shouldn't this be [2]? yes correct my mistake. > > >> >> Prior to this patch ulpi reset was done directly now >> it is done using ulpi_reset. >> >> Thanks to Igor Grinberg<grinberg@compulab.co.il> ?for reviewing the >> omap-ehci patches and suggesting this approach. >> >> This patch along with the patch series [1] rebased on latest u-boot > > > Probably same here, or am I mistaken? yes you are right, it should be [2] > > >> is available here. >> ? ? ? ?git://gitorious.org/denx_u-boot/denx_uboot_omap.git v2_ehci_omap4 >> >> [1]: http://www.mail-archive.com/u-boot at lists.denx.de/msg76076.html >> [2]: "[PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 >> socs" >> >> Signed-off-by: Govindraj.R<govindraj.raja@ti.com> >> --- >> ?board/efikamx/efikamx-usb.c ? ? ? ? ? | ? 21 ++++--- >> ?drivers/usb/host/ehci-omap.c ? ? ? ? ?| ? 21 ++----- >> ?drivers/usb/ulpi/Makefile ? ? ? ? ? ? | ? ?1 + >> ?drivers/usb/ulpi/omap-ulpi-viewport.c | ?110 >> +++++++++++++++++++++++++++++++++ >> ?drivers/usb/ulpi/ulpi-viewport.c ? ? ?| ? 30 +++++----- >> ?drivers/usb/ulpi/ulpi.c ? ? ? ? ? ? ? | ? 54 ++++++++-------- >> ?include/configs/omap3_beagle.h ? ? ? ?| ? ?3 + >> ?include/configs/omap4_panda.h ? ? ? ? | ? ?2 + >> ?include/usb/ulpi.h ? ? ? ? ? ? ? ? ? ?| ? 37 ++++++++---- > > > You should also, update the README file with the new > CONFIG_USB_ULPI_VIEWPORT_OMAP option. > (Also may be some OMAP specific doc files..) > yes fine, I am adding a new doc README.omap-ulpi-viewport and adding some minimal info on the omap-ulpi-viewport usage and usecase. > > >> ?9 files changed, 202 insertions(+), 77 deletions(-) >> ?create mode 100644 drivers/usb/ulpi/omap-ulpi-viewport.c >> >> diff --git a/board/efikamx/efikamx-usb.c b/board/efikamx/efikamx-usb.c >> index 840bd9a..bb1398b 100644 >> --- a/board/efikamx/efikamx-usb.c >> +++ b/board/efikamx/efikamx-usb.c >> @@ -120,6 +120,7 @@ static void efika_ehci_init(struct usb_ehci *ehci, >> uint32_t stp_gpio, >> ?{ >> ? ? ? ?int ret; >> ? ? ? ?struct ulpi_regs *ulpi = (struct ulpi_regs *)0; >> + ? ? ? struct ulpi_viewport ulpi_vp; >> >> ? ? ? ?mxc_request_iomux(stp_gpio, alt0); >> ? ? ? ?mxc_iomux_set_pad(stp_gpio, PAD_CTL_DRV_HIGH | >> @@ -133,23 +134,25 @@ static void efika_ehci_init(struct usb_ehci >> *ehci, uint32_t stp_gpio, >> ? ? ? ?mxc_iomux_set_pad(stp_gpio, USB_PAD_CONFIG); >> ? ? ? ?udelay(10000); >> >> - ? ? ? ret = ulpi_init((u32)&ehci->ulpi_viewpoint); >> + ? ? ? ulpi_vp.viewport_addr = (u32)&ehci->ulpi_viewpoint; > > > here, you should also: > > + ? ? ? ulpi_vp.port_num = 0; okay. > > because the ulpi_vp structure is not initialized and can have garbage in it. > >> + >> + ? ? ? ret = ulpi_init(&ulpi_vp); >> ? ? ? ?if (ret) { >> ? ? ? ? ? ? ? ?printf("Efika USB ULPI initialization failed\n"); >> ? ? ? ? ? ? ? ?return; >> ? ? ? ?} >> >> ? ? ? ?/* ULPI set flags */ >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl, >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->otg_ctrl, >> >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_OTG_DP_PULLDOWN | ULPI_OTG_DM_PULLDOWN | >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_OTG_EXTVBUSIND); >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->function_ctrl, >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->function_ctrl, >> >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_FC_FULL_SPEED | ULPI_FC_OPMODE_NORMAL | >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_FC_SUSPENDM); >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->iface_ctrl, 0); >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->iface_ctrl, 0); >> >> >> ? ? ? ?/* Set VBus */ >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, >> >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_OTG_DRVVBUS | ULPI_OTG_DRVVBUS_EXT); >> >> ? ? ? ?/* >> @@ -158,7 +161,7 @@ static void efika_ehci_init(struct usb_ehci *ehci, >> uint32_t stp_gpio, >> ? ? ? ? * NOTE: This violates USB specification, but otherwise, USB on >> Efika >> ? ? ? ? * doesn't work. >> ? ? ? ? */ >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, >> ? ? ? ? ? ? ? ? ? ? ? ?ULPI_OTG_CHRGVBUS); > > > This fits 80 characters, right? Can this now be on the same line? sure. > >> ?} >> >> @@ -177,9 +180,11 @@ void ehci_powerup_fixup(uint32_t *status_reg, >> uint32_t *reg) >> ? ? ? ?uint32_t port = OTG_BASE_ADDR + (0x200 * CONFIG_MXC_USB_PORT); >> ? ? ? ?struct usb_ehci *ehci = (struct usb_ehci *)port; >> ? ? ? ?struct ulpi_regs *ulpi = (struct ulpi_regs *)0; >> + ? ? ? struct ulpi_viewport ulpi_vp; >> >> - ? ? ? ulpi_write((u32)&ehci->ulpi_viewpoint,&ulpi->otg_ctrl_set, >> >> - ? ? ? ? ? ? ? ? ? ? ? ULPI_OTG_CHRGVBUS); >> + ? ? ? ulpi_vp.viewport_addr = (u32)&ehci->ulpi_viewpoint; > > > same here: > > + ? ? ? ulpi_vp.port_num = 0; > >> + >> + ? ? ? ulpi_write(&ulpi_vp,&ulpi->otg_ctrl_set, ULPI_OTG_CHRGVBUS); >> >> ? ? ? ?wait_ms(50); >> > > [...] > > >> diff --git a/drivers/usb/ulpi/Makefile b/drivers/usb/ulpi/Makefile >> index d43b229..67d5e5e 100644 >> --- a/drivers/usb/ulpi/Makefile >> +++ b/drivers/usb/ulpi/Makefile >> @@ -24,6 +24,7 @@ LIB ? := $(obj)libusb_ulpi.o >> >> ?COBJS-$(CONFIG_USB_ULPI) ? ? ? ? ? ? ?+= ulpi.o >> ?COBJS-$(CONFIG_USB_ULPI_VIEWPORT) ? ? += ulpi-viewport.o >> +COBJS-$(CONFIG_USB_OMAP_ULPI_VIEWPORT) += omap-ulpi-viewport.o > > > IMO, CONFIG_USB_ULPI_VIEWPORT_OMAP will look better here, but > you can leave it as it is - it does not really meter. > yes fine corrected. > >> >> ?COBJS := $(COBJS-y) >> ?SRCS ?:= $(COBJS:.o=.c) >> diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c >> b/drivers/usb/ulpi/omap-ulpi-viewport.c >> new file mode 100644 >> index 0000000..1718788 >> --- /dev/null >> +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c >> @@ -0,0 +1,110 @@ > > > [...] > >> +/* ULPI viewport control bits */ >> +#define OMAP_ULPI_PORT_SHIFT ? 24 >> + >> +#define OMAP_ULPI_WR_OPSEL ? ? (3<< ?21) >> +#define OMAP_ULPI_ACCESS ? ? ? (1<< ?31) >> + >> +/* >> + * Wait for the ULPI Access to complete >> + */ >> +static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) >> +{ >> + ? ? ? int timeout = CONFIG_USB_ULPI_TIMEOUT; >> + >> + ? ? ? while (--timeout) { >> + ? ? ? ? ? ? ? if ((readl(ulpi_vp->viewport_addr)& ?mask)) >> >> + ? ? ? ? ? ? ? ? ? ? ? return 0; >> + >> + ? ? ? ? ? ? ? udelay(1); >> + ? ? ? } >> + >> + ? ? ? return ULPI_ERROR; >> +} >> + >> +/* >> + * Wake the ULPI PHY up for communication >> + * >> + * returns 0 on success. >> + */ >> +static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) >> +{ >> + ? ? ? int err; >> + >> + ? ? ? if (readl(ulpi_vp->viewport_addr)& ?OMAP_ULPI_ACCESS) >> >> + ? ? ? ? ? ? ? return 0; /* already awake */ >> + >> + ? ? ? writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr); >> + >> + ? ? ? err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); >> + ? ? ? if (err) >> + ? ? ? ? ? ? ? debug("ULPI wakeup timed out\n"); >> + >> + ? ? ? return err; >> +} > > > This function looks really weird... > You write the OMAP_ULPI_ACCESS bit, but you don't specify the port... > Now, if you will specify the port, what access type (read/write) should it > be? > So, I don't really know what whould be the consequence of that access... > > TRM does not talk about waking the ULPI PHY at all or have I missed it... > I think this function is unneeded on OMAP - it looks like OMAP wakes > the ULPI PHY automatically as soon as you access it for read/write, > but the TRM does not talk too much on that... > > Have you tried without this function? > Just calling ulpi_wait() to verify that the previous access has completed, > should do the job, no? Can you, please, check that? > Actually we have to start the ulpi access first, then we can write port number and mode to be used and after writing we can check for access done bit. (checking read/write op was successful can be polled for access done bit) without ulpi_wake access done was not happening and timing out. > >> + >> +/* >> + * Issue a ULPI read/write request >> + */ >> +static int ulpi_request(struct ulpi_viewport *ulpi_vp, u32 value) >> +{ >> + ? ? ? int err; >> + >> + ? ? ? err = ulpi_wakeup(ulpi_vp); >> + ? ? ? if (err) >> + ? ? ? ? ? ? ? return err; >> + >> + ? ? ? writel(value, ulpi_vp->viewport_addr); >> + >> + ? ? ? err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); >> + ? ? ? if (err) >> + ? ? ? ? ? ? ? debug("ULPI request timed out\n"); >> + >> + ? ? ? return err; >> +} >> + >> +int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) >> +{ >> + ? ? ? u32 val = (ulpi_vp->port_num<< ?OMAP_ULPI_PORT_SHIFT) | >> + ? ? ? ? ? ? ? ? ? ? ? OMAP_ULPI_WR_OPSEL | >> + ? ? ? ? ? ? ? ? ? ? ? ((u32)reg<< ?16) | (value& ?0xff); > > > If you use OMAP_ULPI_PORT_SHIFT, > then probably 16 should be also defined in the same way? > Or... I would just drop the OMAP_ULPI_PORT_SHIFT, because > it is clear that 24 is the offset of port number... > okay, retaining as just 24 > Also, you should mask the port_num: > ulpi_vp->port_num & 0xf > as for this field is 4 bits wide. > corrected. > >> + >> + ? ? ? return ulpi_request(ulpi_vp, val); >> +} >> + >> +u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) >> +{ >> + ? ? ? int err; >> + ? ? ? u32 val = (ulpi_vp->port_num<< ?OMAP_ULPI_PORT_SHIFT) | >> + ? ? ? ? ? ? ? ? ? ? ? ?OMAP_ULPI_WR_OPSEL | >> + ? ? ? ? ? ? ? ? ? ? ? ((u32)reg<< ?16); > > > same here corrected. > >> + >> + ? ? ? err = ulpi_request(ulpi_vp, val); >> + ? ? ? if (err) >> + ? ? ? ? ? ? ? return err; >> + >> + ? ? ? return readl(ulpi_vp->viewport_addr)& ?0xff; >> >> +} >> diff --git a/drivers/usb/ulpi/ulpi-viewport.c >> b/drivers/usb/ulpi/ulpi-viewport.c >> index 490fb0e..6f03f08 100644 >> --- a/drivers/usb/ulpi/ulpi-viewport.c >> +++ b/drivers/usb/ulpi/ulpi-viewport.c >> @@ -40,13 +40,13 @@ > > > [...] > > >> -int ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value) >> +int ulpi_write(struct ulpi_viewport *ulpi_vp, u8 *reg, u32 value) >> ?{ >> ? ? ? ?u32 val = ULPI_RWRUN | ULPI_RWCTRL | ((u32)reg<< ?16) | (value& >> ?0xff); > > > You have extended the ULPI framework - now it has support for port number... > here, you should also: > val |= (ulpi_vp->port_num & 0x7) << 24; > > (yes, 24 is the correct offset and it is 3 bits wide according to the iMX35 > RM). > okay, corrected this. > >> >> - ? ? ? return ulpi_request(ulpi_viewport, val); >> + ? ? ? return ulpi_request(ulpi_vp, val); >> ?} >> >> -u32 ulpi_read(u32 ulpi_viewport, u8 *reg) >> +u32 ulpi_read(struct ulpi_viewport *ulpi_vp, u8 *reg) >> ?{ >> ? ? ? ?int err; >> ? ? ? ?u32 val = ULPI_RWRUN | ((u32)reg<< ?16); > > > same here > >> >> - ? ? ? err = ulpi_request(ulpi_viewport, val); >> + ? ? ? err = ulpi_request(ulpi_vp, val); >> ? ? ? ?if (err) >> ? ? ? ? ? ? ? ?return err; >> >> - ? ? ? return (readl(ulpi_viewport)>> ?8)& ?0xff; >> + ? ? ? return (readl(ulpi_vp->viewport_addr)>> ?8)& ?0xff; >> >> ?} >> diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c >> index 6202227..dde2585 100644 >> --- a/drivers/usb/ulpi/ulpi.c >> +++ b/drivers/usb/ulpi/ulpi.c >> @@ -37,18 +37,18 @@ > > > [...] > > >> -int ulpi_reset(u32 ulpi_viewport) >> +int ulpi_reset(struct ulpi_viewport *ulpi_vp) >> ?{ >> ? ? ? ?int err; >> >> - ? ? ? err = ulpi_write(ulpi_viewport, >> + ? ? ? err = ulpi_write(ulpi_vp, >> ? ? ? ? ? ? ? ? ? ? ? ?&ulpi->function_ctrl_set, ULPI_FC_RESET); > > > This fits 80 characters now. Please, make it on the same line. sure. > > >> ? ? ? ?if (err) { >> ? ? ? ? ? ? ? ?printf("ULPI: %s: failed writing reset bit\n", __func__); >> ? ? ? ? ? ? ? ?return err; >> ? ? ? ?} >> >> - ? ? ? return ulpi_reset_wait(ulpi_viewport); >> + ? ? ? return ulpi_reset_wait(ulpi_vp); >> ?} >> diff --git a/include/configs/omap3_beagle.h >> b/include/configs/omap3_beagle.h >> index b4d6443..2183ea6 100644 >> --- a/include/configs/omap3_beagle.h >> +++ b/include/configs/omap3_beagle.h >> @@ -130,6 +130,9 @@ >> ?#define CONFIG_CMD_USB >> ?#define CONFIG_USB_EHCI >> ?#define CONFIG_USB_EHCI_OMAP >> +#define CONFIG_USB_ULPI >> +#define CONFIG_USB_OMAP_ULPI_VIEWPORT >> + >> ?/*#define CONFIG_EHCI_DCACHE*/ /* leave it disabled for now */ >> ?#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO ? ? ?147 >> ?#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 >> diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h >> index 23c0230..0228a66 100644 >> --- a/include/configs/omap4_panda.h >> +++ b/include/configs/omap4_panda.h >> @@ -38,6 +38,8 @@ >> ?#define CONFIG_USB_HOST >> ?#define CONFIG_USB_EHCI >> ?#define CONFIG_USB_EHCI_OMAP >> +#define CONFIG_USB_ULPI >> +#define CONFIG_USB_OMAP_ULPI_VIEWPORT >> ?#define CONFIG_USB_STORAGE >> ?#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 > > > This also should apply for TAM3517 board. > Stefano, can you test this on TAM3517? > > Probably Ilya is also interested in this for HTKW mcx board. > Adding both to Cc. > > >> >> diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h >> index 802f077..1da43ae 100644 >> --- a/include/usb/ulpi.h >> +++ b/include/usb/ulpi.h >> @@ -28,12 +28,24 @@ >> ?#endif >> >> ?/* >> + * ulpi view port address and >> + * Port_number that can be passed. >> + * Any additional data to be passed can >> + * be extended from this structure >> + */ >> +struct ulpi_viewport { >> + ? ? ? u32 viewport_addr; >> + ? ? ? u8 port_num; > > > You shift this by 24 bits... > Can this be u32 instead, to remove any confusion? > It can also spare some alignment bugs with some compilers/linkers... > yes fine. > >> +}; >> + >> +/* >> ? * Initialize the ULPI transciever and check the interface integrity. >> - * @ulpi_viewport - ?the address of the ULPI viewport register. >> + * @ulpi_viewport - ?structure containing the address of the ULPI >> viewport >> + ? ? ? ? ? ? ? ? ? ? ? register and port number to access. > > > Please, do not describe here the internal fields of the structure, > it can be done better along with structure definition. > IMO, simply: > 'structure containing ULPI viewport data' > should be enough. > Okay fine. -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-02-03 12:50 ` Govindraj @ 2012-02-03 13:18 ` Igor Grinberg 0 siblings, 0 replies; 40+ messages in thread From: Igor Grinberg @ 2012-02-03 13:18 UTC (permalink / raw) To: u-boot On 02/03/12 14:50, Govindraj wrote: [...] >>> >>> COBJS := $(COBJS-y) >>> SRCS := $(COBJS:.o=.c) >>> diff --git a/drivers/usb/ulpi/omap-ulpi-viewport.c >>> b/drivers/usb/ulpi/omap-ulpi-viewport.c >>> new file mode 100644 >>> index 0000000..1718788 >>> --- /dev/null >>> +++ b/drivers/usb/ulpi/omap-ulpi-viewport.c >>> @@ -0,0 +1,110 @@ >> >> >> [...] >> >>> +/* ULPI viewport control bits */ >>> +#define OMAP_ULPI_PORT_SHIFT 24 >>> + >>> +#define OMAP_ULPI_WR_OPSEL (3<< 21) >>> +#define OMAP_ULPI_ACCESS (1<< 31) >>> + >>> +/* >>> + * Wait for the ULPI Access to complete >>> + */ >>> +static int ulpi_wait(struct ulpi_viewport *ulpi_vp, u32 mask) >>> +{ >>> + int timeout = CONFIG_USB_ULPI_TIMEOUT; >>> + >>> + while (--timeout) { >>> + if ((readl(ulpi_vp->viewport_addr)& mask)) >>> >>> + return 0; >>> + >>> + udelay(1); >>> + } >>> + >>> + return ULPI_ERROR; >>> +} >>> + >>> +/* >>> + * Wake the ULPI PHY up for communication >>> + * >>> + * returns 0 on success. >>> + */ >>> +static int ulpi_wakeup(struct ulpi_viewport *ulpi_vp) >>> +{ >>> + int err; >>> + >>> + if (readl(ulpi_vp->viewport_addr)& OMAP_ULPI_ACCESS) >>> >>> + return 0; /* already awake */ >>> + >>> + writel(OMAP_ULPI_ACCESS, ulpi_vp->viewport_addr); >>> + >>> + err = ulpi_wait(ulpi_vp, OMAP_ULPI_ACCESS); >>> + if (err) >>> + debug("ULPI wakeup timed out\n"); >>> + >>> + return err; >>> +} >> >> >> This function looks really weird... >> You write the OMAP_ULPI_ACCESS bit, but you don't specify the port... >> Now, if you will specify the port, what access type (read/write) should it >> be? >> So, I don't really know what whould be the consequence of that access... >> >> TRM does not talk about waking the ULPI PHY at all or have I missed it... >> I think this function is unneeded on OMAP - it looks like OMAP wakes >> the ULPI PHY automatically as soon as you access it for read/write, >> but the TRM does not talk too much on that... >> >> Have you tried without this function? >> Just calling ulpi_wait() to verify that the previous access has completed, >> should do the job, no? Can you, please, check that? >> > > Actually we have to start the ulpi access first, then we can write > port number and mode to be used and after writing we can check for access > done bit. (checking read/write op was successful can be polled for > access done bit) > > without ulpi_wake access done was not happening and timing out. This is really weird... because we actually don't know which port (PHY) is being wakened (may be all of them...). But if you say it does not work without it, then I'm fine with it. Thanks Govindraj. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c 2012-01-12 10:52 ` Govindraj 2012-01-17 6:10 ` Govindraj @ 2012-01-17 18:17 ` Igor Grinberg 1 sibling, 0 replies; 40+ messages in thread From: Igor Grinberg @ 2012-01-17 18:17 UTC (permalink / raw) To: u-boot Hi Govindraj, I'm sorry it took me so much time, I just was very busy these days... I've looked in the TRMs of both OMAP3 and OMAP4, please see below. On 01/12/12 12:52, Govindraj wrote: > On Thu, Jan 12, 2012 at 2:53 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >> Hi Govindraj, >> >> On 01/12/12 07:45, Govindraj wrote: >>> Hi Igor, >>> >>> On Wed, Jan 11, 2012 at 8:33 PM, Igor Grinberg <grinberg@compulab.co.il> wrote: >>>> Hi Guys, >>>> >>>> On 01/11/12 16:34, Marek Vasut wrote: >>>>>> On Wed, Jan 11, 2012 at 6:58 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>> On Wed, Jan 11, 2012 at 6:16 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >>>>>>>>>> On Wed, Jan 11, 2012 at 4:22 PM, Marek Vasut <marek.vasut@gmail.com> >>>>> wrote: >>>>>>>>>>>> Hi Marek, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for you review. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 10, 2012 at 9:37 PM, Marek Vasut >>>>>>>>>>>> <marek.vasut@gmail.com> >>>>>>> >>>>>>> wrote: >>>>>>>>>>>>>> From: "Govindraj.R" <govindraj.raja@ti.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Clean up added ehci-omap.c and make it generic for re-use >>>>>>>>>>>>>> across soc having same ehci ip block. Also pass the modes to >>>>>>>>>>>>>> be configured and configure the ports accordingly. All usb >>>>>>>>>>>>>> layers are not cache aligned till then keep cache off for usb >>>>>>>>>>>>>> ops as ehci will use internally dma for all usb ops. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Add a generic common header ehci-omap.h having common ip >>>>>>>>>>>>>> block data and reg shifts. >>>>>>>>>>>>>> * Rename and modify ehci-omap3 to ehci.h retain only >>>>>>>>>>>>>> conflicting sysc reg shifts remove others and move to common >>>>>>>>>>>>>> header file. >>>>>>>>>>>>> >>>>>>>>>>>>> Don't reimplement the ulpi stuff ... there's already some ulpi >>>>>>>>>>>>> stuff in uboot that needs fixing, so fix it and use it. Why do you keep saying that it needs fixing? Can you point to a specific problem? >>>>>>>>>>>> >>>>>>>>>>>> I am not implementing any ulpi stuff I am just configuring OMAP on >>>>>>>>>>>> soc usb host controller (ehci). All the configuration stuff >>>>>>>>>>>> is OMAP specific things which are done in ehci-omap.c file Yes, it is OMAP specific, but only the INSNREG05_ULPI register part... >>>>>>>>>>>> >>>>>>>>>>>> stuffs done are like soft-reset, port mode to be used and putting >>>>>>>>>>>> port in no -idle mode(omap specific pm implementation) etc. Well, the soft-reset, does not fit here... The soft reset is defined by the ULPI spec and there is already an implementation for this (as defined by the ULPI spec.) >>>>>>>>>>> >>>>>>>>>>> This stuff: >>>>>>>>>>> >>>>>>>>>>> +/* ULPI */ >>>>>>>>>>> +#define ULPI_SET(a) (a + 1) >>>>>>>>>>> +#define ULPI_CLR(a) (a + 2) >>>>>>>>>>> +#define ULPI_FUNC_CTRL 0x04 >>>>>>>>>>> +#define ULPI_FUNC_CTRL_RESET (1 << 5) >>>>>>>>>>> >>>>>>>>>>> is just accidentally conforming to ULPI spec? >>>>>>>>>> >>>>>>>>>> These are for configuring INSNREG05_ULPI reg in EHCI reg map >>>>>>>>>> of omap while configuring in ulpi-phy mode. By writing to the INSNREG05_ULPI register, you do not configure it, but rather initiate the ULPI transaction to the ULPI PHY. >>>>>>>>>> >>>>>>>>>> looking into struct ulpi_regs {..} >>>>>>>>>> then it doesn't map this configuration. ulpi_regs {...} provides a kind of virtual mapping (to conform to U-Boot way of accessing the registers) for the ULPI registers inside the ULPI PHY, which are accessible in a platform specific manner which is sometimes called a ULPI viewport. In case of OMAP, the ULPI viewport is the INSNREG05_ULPI register. >>>>>>>>> >>>>>>>>> Can you point me to some documentation about this please? It's not >>>>>>>>> that I don't trust you, I'd rather prefer to avoid unnecessary >>>>>>>>> duplication. >>>>>>>> >>>>>>>> Yes that would be fine. >>>>>>>> >>>>>>>> You can download the omap4460 public trm from here: >>>>>>>> >>>>>>>> http://www.ti.com/pdfs/wtbu/OMAP4460_ES.1x_PUBLIC_TRM_vM.zip >>>>>>>> >>>>>>>> Go to chapter 23.11.6.6.1 EHCI Register Summary >>>>>>>> (page number 5171 and 5186/87) >>>>>>> >>>>>>> Sure, but the macro above looks more like 23.11.6.3, doesn't it ? And for >>>>>>> that purpose, the struct ulpi_regs is fitting ok. No, Marek, there is another thing inside OMAP, which is called TLL. It provides a kind of virtual ULPI interface and can be used instead of ULPI PHY for the on-board connected devices. TLL is not related to this discussion. >>>>>>> >>>>>>> Actually ... can you check the ulpi_read and ulpi_write stuff that's >>>>>>> already in u-boot and explain why they can not be used with this port? Marek, OMAP has a different ULPI viewport register structure, so to reuse the ULPI layer, the omap-ulpi-viewport.c should be implemented with its own ULPI accessors (e.g. ulpi_{read|write}()). >>>>>> >>>>>> echi-omap.c is no where writing to those registers >>>>>> and the macro was used only to configure INSNREG05_ULPI reg in EHCI reg map This is not exactly true... Indeed, the INSNREG05_ULPI register is in EHCI registers address space. In fact it does not meter where that register is located. After those macros was written to the INSNREG05_ULPI register, the ULPI transaction is issued to write the value inside the ULPI register. >>>>>> >>>>>> reg map in 23.11.6.3 used only for a external ulpi-phy communication. >>>>>> and debug purpose(to view vid, pid etc) and to hack external phy >>>>>> configuration through ulpi commands Almost... TLL is exactly the opposite... It is a PHY-less configuration. It is the TLL ULPI pseudo registers and it is not related to the discussion. >>>>>> from omap - usb host controller point of view only needs >>>>>> INSNREG05_ULPI reg in EHCI reg configuration >>>>>> rest on soc host controller takes care of it. right, but it is the ULPI PHY access register and you do not configure it, but access the ULPI PHY registers through this register. >>>>> >>>>> Can someone else comment on this? I think I don't understand well (as I'm not >>>>> OMAP guy). >>>> >>>> Well, it is on my list, actually, >>>> but I will be able to get to it only in a couple of days. >>>> (I'm really busy right now). >>>> >>> >>> Could you please let me know what exactly that you will be >>> updating? >>> >>> So that I can accordingly post my v3 of this patch fixing comments >>> from Marek Vasut <marek.vasut@gmail.com> >> >> Well, I did not say, I'm going to update anything. >> What I meant is that I'm going to look into TI's documentation >> regarding EHCI and the ULPI to understand the dependencies and see >> how your code meets those and if the generic ULPI layer can be used >> for that. Ok, now I've done that, and commented above. So, IMO, yes the ULPI layer should be reused for the ULPI access, but we have here a problem which needs a solution: Current ULPI implementation does not support the multi-port mode of the ULPI viewport register (PORTSEL bit on OMAP or ULPIPORT bit on iMX35). Apparently, on iMX (e.g. efikamx) it is used in non-multi port mode or the port is always 0. Currently, there is no way to pass this parameter to the ULPI viewport implementation. I will send some more feedback on your latest patch tomorrow. -- Regards, Igor. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 2/4] OMAP3+: Clock: Adding ehci clock enabling 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R 2012-01-06 9:03 ` [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c Govindraj.R @ 2012-01-06 9:03 ` Govindraj.R 2012-01-06 9:04 ` [U-Boot] [PATCH v2 3/4] OMAP4: clock-common: Move the usb dppl configuration to new func Govindraj.R ` (2 subsequent siblings) 4 siblings, 0 replies; 40+ messages in thread From: Govindraj.R @ 2012-01-06 9:03 UTC (permalink / raw) To: u-boot From: "Govindraj.R" <govindraj.raja@ti.com> Adding ehci clock enabling mechanism part of clock framework. When essential clocks are enabled during init phase usb host clocks can also be enabled from clock framework. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> --- arch/arm/cpu/armv7/omap3/board.c | 4 ++++ arch/arm/cpu/armv7/omap3/clock.c | 20 ++++++++++++++++++++ arch/arm/cpu/armv7/omap4/clocks.c | 5 +++++ arch/arm/include/asm/arch-omap3/sys_proto.h | 1 + 4 files changed, 30 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c index 1f33c63..d3b25cd 100644 --- a/arch/arm/cpu/armv7/omap3/board.c +++ b/arch/arm/cpu/armv7/omap3/board.c @@ -228,6 +228,10 @@ void s_init(void) per_clocks_enable(); +#ifdef CONFIG_USB_EHCI_OMAP + ehci_clocks_enable(); +#endif + #ifdef CONFIG_SPL_BUILD preloader_console_init(); #endif diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/clock.c index e0d65c7..567817e 100644 --- a/arch/arm/cpu/armv7/omap3/clock.c +++ b/arch/arm/cpu/armv7/omap3/clock.c @@ -626,6 +626,26 @@ void prcm_init(void) sdelay(5000); } +/* + * Enable usb ehci uhh, tll clocks + */ +void ehci_clocks_enable(void) +{ + struct prcm *prcm_base = (struct prcm *)PRCM_BASE; + + /* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ + sr32(&prcm_base->iclken_usbhost, 0, 1, 1); + /* + * Enable USBHOST_48M_FCLK (USBHOST_FCLK1) + * and USBHOST_120M_FCLK (USBHOST_FCLK2) + */ + sr32(&prcm_base->fclken_usbhost, 0, 2, 3); + /* Enable USBTTL_ICLK */ + sr32(&prcm_base->iclken3_core, 2, 1, 1); + /* Enable USBTTL_FCLK */ + sr32(&prcm_base->fclken3_core, 2, 1, 1); +} + /****************************************************************************** * peripheral_enable() - Enable the clks & power for perifs (GPT2, UART1,...) *****************************************************************************/ diff --git a/arch/arm/cpu/armv7/omap4/clocks.c b/arch/arm/cpu/armv7/omap4/clocks.c index 0886f92..12e283a 100644 --- a/arch/arm/cpu/armv7/omap4/clocks.c +++ b/arch/arm/cpu/armv7/omap4/clocks.c @@ -342,6 +342,9 @@ void enable_basic_clocks(void) &prcm->cm_l4per_gpio4_clkctrl, &prcm->cm_l4per_gpio5_clkctrl, &prcm->cm_l4per_gpio6_clkctrl, + &prcm->cm_l3init_usbphy_clkctrl, + &prcm->cm_clksel_usb_60mhz, + &prcm->cm_l3init_hsusbtll_clkctrl, 0 }; @@ -352,6 +355,8 @@ void enable_basic_clocks(void) &prcm->cm_l4per_gptimer2_clkctrl, &prcm->cm_wkup_wdtimer2_clkctrl, &prcm->cm_l4per_uart3_clkctrl, + &prcm->cm_l3init_fsusb_clkctrl, + &prcm->cm_l3init_hsusbhost_clkctrl, 0 }; diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h index e5031d5..2a89e56 100644 --- a/arch/arm/include/asm/arch-omap3/sys_proto.h +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h @@ -34,6 +34,7 @@ struct emu_hal_params { void prcm_init(void); void per_clocks_enable(void); +void ehci_clocks_enable(void); void memif_init(void); void sdrc_init(void); -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 3/4] OMAP4: clock-common: Move the usb dppl configuration to new func 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R 2012-01-06 9:03 ` [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c Govindraj.R 2012-01-06 9:03 ` [U-Boot] [PATCH v2 2/4] OMAP3+: Clock: Adding ehci clock enabling Govindraj.R @ 2012-01-06 9:04 ` Govindraj.R 2012-01-06 9:04 ` [U-Boot] [PATCH v2 4/4] OMAP3+: ehci-omap: enable usb host ports for beagle/panda Govindraj.R 2012-02-26 23:13 ` [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Marek Vasut 4 siblings, 0 replies; 40+ messages in thread From: Govindraj.R @ 2012-01-06 9:04 UTC (permalink / raw) To: u-boot From: "Govindraj.R" <govindraj.raja@ti.com> usb dpll configuration is done only part of non-essential dppl configuration however if CONFIG_USB_EHCI_OMAP is defined we may have to configure usb dpll's for proper functioning of usb modules. So move the usb dppl configuration to a new func. and utilise the same during essential dpll configuration. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> --- arch/arm/cpu/armv7/omap-common/clocks-common.c | 52 ++++++++++++++--------- 1 files changed, 32 insertions(+), 20 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c index 1da90a4..770ac19 100644 --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c @@ -251,6 +251,33 @@ void configure_mpu_dpll(void) debug("MPU DPLL locked\n"); } +static void setup_usb_dpll(void) +{ + const struct dpll_params *params; + u32 sys_clk_khz, sd_div, num, den; + + sys_clk_khz = get_sys_clk_freq() / 1000; + /* + * USB: + * USB dpll is J-type. Need to set DPLL_SD_DIV for jitter correction + * DPLL_SD_DIV = CEILING ([DPLL_MULT/(DPLL_DIV+1)]* CLKINP / 250) + * - where CLKINP is sys_clk in MHz + * Use CLKINP in KHz and adjust the denominator accordingly so + * that we have enough accuracy and at the same time no overflow + */ + params = get_usb_dpll_params(); + num = params->m * sys_clk_khz; + den = (params->n + 1) * 250 * 1000; + num += den - 1; + sd_div = num / den; + clrsetbits_le32(&prcm->cm_clksel_dpll_usb, + CM_CLKSEL_DPLL_DPLL_SD_DIV_MASK, + sd_div << CM_CLKSEL_DPLL_DPLL_SD_DIV_SHIFT); + + /* Now setup the dpll with the regular function */ + do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb"); +} + static void setup_dplls(void) { u32 temp; @@ -282,13 +309,16 @@ static void setup_dplls(void) /* MPU dpll */ configure_mpu_dpll(); + +#ifdef CONFIG_USB_EHCI_OMAP + setup_usb_dpll(); +#endif } #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL static void setup_non_essential_dplls(void) { u32 sys_clk_khz, abe_ref_clk; - u32 sd_div, num, den; const struct dpll_params *params; sys_clk_khz = get_sys_clk_freq() / 1000; @@ -300,25 +330,7 @@ static void setup_non_essential_dplls(void) params = get_iva_dpll_params(); do_setup_dpll(&prcm->cm_clkmode_dpll_iva, params, DPLL_LOCK, "iva"); - /* - * USB: - * USB dpll is J-type. Need to set DPLL_SD_DIV for jitter correction - * DPLL_SD_DIV = CEILING ([DPLL_MULT/(DPLL_DIV+1)]* CLKINP / 250) - * - where CLKINP is sys_clk in MHz - * Use CLKINP in KHz and adjust the denominator accordingly so - * that we have enough accuracy and at the same time no overflow - */ - params = get_usb_dpll_params(); - num = params->m * sys_clk_khz; - den = (params->n + 1) * 250 * 1000; - num += den - 1; - sd_div = num / den; - clrsetbits_le32(&prcm->cm_clksel_dpll_usb, - CM_CLKSEL_DPLL_DPLL_SD_DIV_MASK, - sd_div << CM_CLKSEL_DPLL_DPLL_SD_DIV_SHIFT); - - /* Now setup the dpll with the regular function */ - do_setup_dpll(&prcm->cm_clkmode_dpll_usb, params, DPLL_LOCK, "usb"); + setup_usb_dpll(); /* Configure ABE dpll */ params = get_abe_dpll_params(); -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 4/4] OMAP3+: ehci-omap: enable usb host ports for beagle/panda 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R ` (2 preceding siblings ...) 2012-01-06 9:04 ` [U-Boot] [PATCH v2 3/4] OMAP4: clock-common: Move the usb dppl configuration to new func Govindraj.R @ 2012-01-06 9:04 ` Govindraj.R 2012-02-26 23:13 ` [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Marek Vasut 4 siblings, 0 replies; 40+ messages in thread From: Govindraj.R @ 2012-01-06 9:04 UTC (permalink / raw) To: u-boot From: "Govindraj.R" <govindraj.raja@ti.com> For beagle and panda enable and use the ehci-omap.c generic api's added to configure usb host ports based on data passed from board file to configure in modes as specified from board data. For panda initialise the mux pins for ehci usage. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> --- board/ti/beagle/beagle.c | 28 ++++++++++++++++++++++++++ board/ti/panda/panda.c | 41 +++++++++++++++++++++++++++++++++++++++ board/ti/panda/panda_mux_data.h | 16 +++++++------- include/configs/omap4_panda.h | 23 ++++++++++++++++++++- 4 files changed, 99 insertions(+), 9 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 3d63028..2f2e8ba 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -45,6 +45,11 @@ #include "beagle.h" #include <command.h> +#ifdef CONFIG_USB_EHCI +#include <usb.h> +#include <asm/ehci-omap.h> +#endif + #define pr_debug(fmt, args...) debug(fmt, ##args) #define TWL4030_I2C_BUS 0 @@ -438,6 +443,29 @@ void show_boot_progress(int val) if(val == 15) usb_stop(); } + +static struct omap_usbhs_board_data usbhs_bdata = { + .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY, + .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY, + .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED +}; + +int ehci_hcd_init(void) +{ + int ret = 0; + + ret = omap_ehci_hcd_init(&usbhs_bdata); + return ret; +} + +int ehci_hcd_stop(void) +{ + int ret; + + ret = omap_ehci_hcd_stop(); + return ret; +} + #endif /* CONFIG_USB_EHCI */ #ifndef CONFIG_SPL_BUILD diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c index fc8c0b4..1f8509b 100644 --- a/board/ti/panda/panda.c +++ b/board/ti/panda/panda.c @@ -26,9 +26,16 @@ #include <asm/arch/mmc_host_def.h> #include <asm/arch/clocks.h> #include <asm/arch/gpio.h> +#include <asm/gpio.h> #include "panda_mux_data.h" +#ifdef CONFIG_USB_EHCI +#include <usb.h> +#include <asm/arch/ehci.h> +#include <asm/ehci-omap.h> +#endif + #define PANDA_ULPI_PHY_TYPE_GPIO 182 DECLARE_GLOBAL_DATA_PTR; @@ -177,6 +184,40 @@ int board_mmc_init(bd_t *bis) } #endif +#ifdef CONFIG_USB_EHCI + +static struct omap_usbhs_board_data usbhs_bdata = { + .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY, + .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED, + .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED, +}; + +int ehci_hcd_init(void) +{ + int ret; + unsigned int utmi_clk; + + /* Now we can enable our port clocks */ + utmi_clk = readl((void *)CM_L3INIT_HSUSBHOST_CLKCTRL); + utmi_clk |= HSUSBHOST_CLKCTRL_CLKSEL_UTMI_P1_MASK; + sr32((void *)CM_L3INIT_HSUSBHOST_CLKCTRL, 0, 32, utmi_clk); + + ret = omap_ehci_hcd_init(&usbhs_bdata); + if (ret < 0) + return ret; + + return 0; +} + +int ehci_hcd_stop(void) +{ + int ret; + + ret = omap_ehci_hcd_stop(); + return ret; +} +#endif + /* * get_board_rev() - get board revision */ diff --git a/board/ti/panda/panda_mux_data.h b/board/ti/panda/panda_mux_data.h index 2970ccd..5b66a14 100644 --- a/board/ti/panda/panda_mux_data.h +++ b/board/ti/panda/panda_mux_data.h @@ -136,14 +136,14 @@ const struct pad_conf_entry core_padconf_array_non_essential[] = { {CAM_SHUTTER, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)}, /* cam_shutter */ {CAM_STROBE, (OFF_EN | OFF_PD | OFF_OUT_PTD | M0)}, /* cam_strobe */ {CAM_GLOBALRESET, (PTD | OFF_EN | OFF_PD | OFF_OUT_PTD | M3)}, /* gpio_83 */ - {USBB1_ULPITLL_CLK, (IEN | OFF_EN | OFF_IN | M1)}, /* hsi1_cawake */ - {USBB1_ULPITLL_STP, (IEN | OFF_EN | OFF_IN | M1)}, /* hsi1_cadata */ - {USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_IN | M1)}, /* hsi1_caflag */ - {USBB1_ULPITLL_NXT, (OFF_EN | M1)}, /* hsi1_acready */ - {USBB1_ULPITLL_DAT0, (OFF_EN | M1)}, /* hsi1_acwake */ - {USBB1_ULPITLL_DAT1, (OFF_EN | M1)}, /* hsi1_acdata */ - {USBB1_ULPITLL_DAT2, (OFF_EN | M1)}, /* hsi1_acflag */ - {USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_IN | M1)}, /* hsi1_caready */ + {USBB1_ULPITLL_CLK, (PTD | IEN | OFF_EN | OFF_PD | OFF_IN | M4)},/* usbb1_ulpiphy_clk */ + {USBB1_ULPITLL_STP, (OFF_EN | OFF_OUT_PTD | M4)}, /* usbb1_ulpiphy_stp */ + {USBB1_ULPITLL_DIR, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dir */ + {USBB1_ULPITLL_NXT, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_nxt */ + {USBB1_ULPITLL_DAT0, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat0 */ + {USBB1_ULPITLL_DAT1, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat1 */ + {USBB1_ULPITLL_DAT2, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat2 */ + {USBB1_ULPITLL_DAT3, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat3 */ {USBB1_ULPITLL_DAT4, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat4 */ {USBB1_ULPITLL_DAT5, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat5 */ {USBB1_ULPITLL_DAT6, (IEN | OFF_EN | OFF_PD | OFF_IN | M4)}, /* usbb1_ulpiphy_dat6 */ diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index e9ef2a3..23c0230 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -31,9 +31,30 @@ /* * High Level Configuration Options */ -#define CONFIG_PANDA 1 /* working with Panda */ +#define CONFIG_PANDA /* working with Panda */ + +/* 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_OMAP_EHCI_PHY1_RESET_GPIO 1 +#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 62 + +/* USB Networking options */ +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX + +#define CONFIG_UBOOT_ENABLE_PADS_ALL + +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP #include <configs/omap4_common.h> +#define CONFIG_CMD_NET /* GPIO */ #define CONFIG_CMD_GPIO -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R ` (3 preceding siblings ...) 2012-01-06 9:04 ` [U-Boot] [PATCH v2 4/4] OMAP3+: ehci-omap: enable usb host ports for beagle/panda Govindraj.R @ 2012-02-26 23:13 ` Marek Vasut 2012-02-27 6:27 ` Govindraj 4 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-02-26 23:13 UTC (permalink / raw) To: u-boot > From: "Govindraj.R" <govindraj.raja@ti.com> > > Clean up ehci-omap added and make it generic to extend support for omap4 > socs. Add ehci support for panda board. > > Patch series depends on below patch: > http://patchwork.ozlabs.org/patch/130952/ > > Patch series based commit id: > 9a420986cccc9bd2c37affd931d627b3c3e72952 > > This patch series long with above dependent patch is avialable at: > git://gitorious.org/denx_u-boot/denx_uboot_omap.git > v2_ehci_omap4 > > Fatls, ping and tftp was tested with this patch series. > Test log for Panda available here: > http://pastebin.pandaboard.org/index.php/view/55361716 > Test log for Beagle-XM available here: > http://pastebin.pandaboard.org/index.php/view/98437825 > Hi, what's the status of this patch/patchset? Thanks M ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs 2012-02-26 23:13 ` [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Marek Vasut @ 2012-02-27 6:27 ` Govindraj 2012-02-27 13:51 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Govindraj @ 2012-02-27 6:27 UTC (permalink / raw) To: u-boot Hi Marek, On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut <marex@denx.de> wrote: >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> Clean up ehci-omap added and make it generic to extend support for omap4 >> socs. Add ehci support for panda board. >> >> Patch series depends on below patch: >> ? ? ? http://patchwork.ozlabs.org/patch/130952/ >> >> Patch series based commit id: >> ? ? ? 9a420986cccc9bd2c37affd931d627b3c3e72952 >> >> This patch series long with above dependent patch is avialable at: >> ? ? ? git://gitorious.org/denx_u-boot/denx_uboot_omap.git >> ? ? ? v2_ehci_omap4 >> >> Fatls, ping and tftp was tested with this patch series. >> Test log for Panda available here: >> ? ? ? http://pastebin.pandaboard.org/index.php/view/55361716 >> Test log for Beagle-XM available here: >> ? ? ? http://pastebin.pandaboard.org/index.php/view/98437825 >> > Hi, > > what's the status of this patch/patchset? It's merged. ubnuser at ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c 49be71c OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago) 860004c OMAP4: clock-common: Move the usb dppl configuration to new func (2 weeks ago) 95f8791 OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) 43b6239 ehci-omap: Clean up added ehci-omap.c (2 weeks ago) 29321c0 ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) 928c4bd usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) 3e6e809 usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) -- Thanks, Govindraj.R ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs 2012-02-27 6:27 ` Govindraj @ 2012-02-27 13:51 ` Marek Vasut 2012-02-27 14:31 ` Tom Rini 0 siblings, 1 reply; 40+ messages in thread From: Marek Vasut @ 2012-02-27 13:51 UTC (permalink / raw) To: u-boot > Hi Marek, > > On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut <marex@denx.de> wrote: > >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> > >> Clean up ehci-omap added and make it generic to extend support for omap4 > >> socs. Add ehci support for panda board. > >> > >> Patch series depends on below patch: > >> http://patchwork.ozlabs.org/patch/130952/ > >> > >> Patch series based commit id: > >> 9a420986cccc9bd2c37affd931d627b3c3e72952 > >> > >> This patch series long with above dependent patch is avialable at: > >> git://gitorious.org/denx_u-boot/denx_uboot_omap.git > >> v2_ehci_omap4 > >> > >> Fatls, ping and tftp was tested with this patch series. > >> Test log for Panda available here: > >> http://pastebin.pandaboard.org/index.php/view/55361716 > >> Test log for Beagle-XM available here: > >> http://pastebin.pandaboard.org/index.php/view/98437825 > > > > Hi, > > > > what's the status of this patch/patchset? > > It's merged. > > ubnuser at ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c > 49be71c OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago) > 860004c OMAP4: clock-common: Move the usb dppl configuration to new > func (2 weeks ago) > 95f8791 OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) > 43b6239 ehci-omap: Clean up added ehci-omap.c (2 weeks ago) > 29321c0 ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) > 928c4bd usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) > 3e6e809 usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) That's good. Thank you. Cleaned up in patchwork M ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs 2012-02-27 13:51 ` Marek Vasut @ 2012-02-27 14:31 ` Tom Rini 2012-02-27 16:29 ` Marek Vasut 0 siblings, 1 reply; 40+ messages in thread From: Tom Rini @ 2012-02-27 14:31 UTC (permalink / raw) To: u-boot On Mon, Feb 27, 2012 at 6:51 AM, Marek Vasut <marek.vasut@gmail.com> wrote: >> Hi Marek, >> >> On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut <marex@denx.de> wrote: >> >> From: "Govindraj.R" <govindraj.raja@ti.com> >> >> >> >> Clean up ehci-omap added and make it generic to extend support for omap4 >> >> socs. Add ehci support for panda board. >> >> >> >> Patch series depends on below patch: >> >> ? ? ? http://patchwork.ozlabs.org/patch/130952/ >> >> >> >> Patch series based commit id: >> >> ? ? ? 9a420986cccc9bd2c37affd931d627b3c3e72952 >> >> >> >> This patch series long with above dependent patch is avialable at: >> >> ? ? ? git://gitorious.org/denx_u-boot/denx_uboot_omap.git >> >> ? ? ? v2_ehci_omap4 >> >> >> >> Fatls, ping and tftp was tested with this patch series. >> >> Test log for Panda available here: >> >> ? ? ? http://pastebin.pandaboard.org/index.php/view/55361716 >> >> Test log for Beagle-XM available here: >> >> ? ? ? http://pastebin.pandaboard.org/index.php/view/98437825 >> > >> > Hi, >> > >> > what's the status of this patch/patchset? >> >> It's merged. >> >> ubnuser at ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c >> 49be71c ?OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago) >> 860004c ?OMAP4: clock-common: Move the usb dppl configuration to new >> func (2 weeks ago) >> 95f8791 ?OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) >> 43b6239 ?ehci-omap: Clean up added ehci-omap.c (2 weeks ago) >> 29321c0 ?ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) >> 928c4bd ?usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) >> 3e6e809 ?usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) > > That's good. Thank you. Cleaned up in patchwork Cleaned up how? I had been (I thought...) keeping the old serieses marked as superseded/changes requested/etc and the one that made it in accepted. Thanks. -- Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs 2012-02-27 14:31 ` Tom Rini @ 2012-02-27 16:29 ` Marek Vasut 0 siblings, 0 replies; 40+ messages in thread From: Marek Vasut @ 2012-02-27 16:29 UTC (permalink / raw) To: u-boot > On Mon, Feb 27, 2012 at 6:51 AM, Marek Vasut <marek.vasut@gmail.com> wrote: > >> Hi Marek, > >> > >> On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut <marex@denx.de> wrote: > >> >> From: "Govindraj.R" <govindraj.raja@ti.com> > >> >> > >> >> Clean up ehci-omap added and make it generic to extend support for > >> >> omap4 socs. Add ehci support for panda board. > >> >> > >> >> Patch series depends on below patch: > >> >> http://patchwork.ozlabs.org/patch/130952/ > >> >> > >> >> Patch series based commit id: > >> >> 9a420986cccc9bd2c37affd931d627b3c3e72952 > >> >> > >> >> This patch series long with above dependent patch is avialable at: > >> >> git://gitorious.org/denx_u-boot/denx_uboot_omap.git > >> >> v2_ehci_omap4 > >> >> > >> >> Fatls, ping and tftp was tested with this patch series. > >> >> Test log for Panda available here: > >> >> http://pastebin.pandaboard.org/index.php/view/55361716 > >> >> Test log for Beagle-XM available here: > >> >> http://pastebin.pandaboard.org/index.php/view/98437825 > >> > > >> > Hi, > >> > > >> > what's the status of this patch/patchset? > >> > >> It's merged. > >> > >> ubnuser at ula0131859:~/clones/mainline_loaders/u-boot$ gls > >> dd54d31..49be71c 49be71c OMAP4: ehci-omap: enable ehci-omap for panda > >> boards (2 weeks ago) 860004c OMAP4: clock-common: Move the usb dppl > >> configuration to new func (2 weeks ago) > >> 95f8791 OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago) > >> 43b6239 ehci-omap: Clean up added ehci-omap.c (2 weeks ago) > >> 29321c0 ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago) > >> 928c4bd usb: ulpi: Add omap-ulpi-view port support (2 weeks ago) > >> 3e6e809 usb: ulpi: Extend the existing ulpi framework. (2 weeks ago) > > > > That's good. Thank you. Cleaned up in patchwork > > Cleaned up how? I had been (I thought...) keeping the old serieses > marked as superseded/changes requested/etc and the one that made it in > accepted. Thanks. There was a patch that was not marked in any way, so I set it to superseded. M ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2012-02-27 16:29 UTC | newest] Thread overview: 40+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-06 9:03 [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Govindraj.R 2012-01-06 9:03 ` [U-Boot] [PATCH v2 1/4] ehci-omap: Clean up added ehci-omap.c Govindraj.R 2012-01-10 16:07 ` Marek Vasut 2012-01-11 6:07 ` Govindraj 2012-01-11 10:52 ` Marek Vasut 2012-01-11 11:32 ` Govindraj 2012-01-11 12:46 ` Marek Vasut 2012-01-11 13:00 ` Govindraj 2012-01-11 13:28 ` Marek Vasut 2012-01-11 14:13 ` Govindraj 2012-01-11 14:34 ` Marek Vasut 2012-01-11 15:03 ` Igor Grinberg 2012-01-11 18:50 ` Marek Vasut 2012-01-12 5:45 ` Govindraj 2012-01-12 9:23 ` Igor Grinberg 2012-01-12 10:52 ` Govindraj 2012-01-17 6:10 ` Govindraj 2012-01-18 17:51 ` Igor Grinberg 2012-01-19 8:15 ` Govindraj 2012-01-22 12:20 ` Igor Grinberg 2012-01-25 9:04 ` Govindraj 2012-01-25 13:40 ` Igor Grinberg 2012-01-27 13:29 ` Govindraj 2012-01-29 9:42 ` Igor Grinberg 2012-01-29 11:42 ` Stefano Babic 2012-02-01 11:01 ` Igor Grinberg 2012-02-01 11:26 ` Stefano Babic 2012-02-01 13:22 ` Igor Grinberg 2012-02-03 12:52 ` Govindraj 2012-02-03 12:50 ` Govindraj 2012-02-03 13:18 ` Igor Grinberg 2012-01-17 18:17 ` Igor Grinberg 2012-01-06 9:03 ` [U-Boot] [PATCH v2 2/4] OMAP3+: Clock: Adding ehci clock enabling Govindraj.R 2012-01-06 9:04 ` [U-Boot] [PATCH v2 3/4] OMAP4: clock-common: Move the usb dppl configuration to new func Govindraj.R 2012-01-06 9:04 ` [U-Boot] [PATCH v2 4/4] OMAP3+: ehci-omap: enable usb host ports for beagle/panda Govindraj.R 2012-02-26 23:13 ` [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs Marek Vasut 2012-02-27 6:27 ` Govindraj 2012-02-27 13:51 ` Marek Vasut 2012-02-27 14:31 ` Tom Rini 2012-02-27 16:29 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox