Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
Hi Roger, On Mon, 5 May 2014, Roger Quadros wrote: Add the sysconfig class bits for the Super Speed USB controllers CC: Paul Walmsley p...@pwsan.com Signed-off-by: Roger Quadros rog...@ti.com As with the previous DRA7 hwmod patch, I'd like to get a Reviewed-by: and a Tested-by: before merging this one. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
On Wed, 12 Mar 2014, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140307 02:18]:
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
Paul, does this look OK to you?
I didn't go over every entry with a magnifying glass, but did take a
quick look at the sysc_offs and the clkdms - the basics look OK.
Acked-by: Paul Walmsley p...@pwsan.com
- Paul
Regards,
Tony
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if
*omap54xx_hwmod_ocp_ifs[] __initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
Hi Benoît,
On Tue, 3 Dec 2013, Roger Quadros wrote:
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Will you pick this up for the -rc series, or do you want me or Tony to?
Roger writes that this one's pretty important.
- Paul
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
-SYSC_HAS_SOFTRESET),
+SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
- * During system boot; If the hwmod framework resets the module
- * the module will have smart idle settings; which can lead to deadlock
- * (above Errata Id:i660); so, dont reset the module during boot;
- * Use HWMOD_INIT_NO_RESET.
- */
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
-SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
- * During system boot; If the hwmod framework resets the module
- * the module will have smart idle settings; which can lead to deadlock
- * (above Errata Id:i660); so, dont reset the module during boot;
- * Use HWMOD_INIT_NO_RESET.
- */
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3init_60m_fclk,
.prcm = {
.omap4 = {
--
1.8.3.2
- Paul
Re: [PATCH 2/3] ARM: OMAP2+: hwmod: Fix RESET logic
Hi Roger,
On Tue, 3 Dec 2013, Roger Quadros wrote:
In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.
This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.
Doh :-(
Nice catch. Renamed _clr_softreset() to _clear_softreset() and queued
the following for v3.13-rc.
- Paul
From: Roger Quadros rog...@ti.com
ARM: OMAP2+: hwmod: Fix SOFTRESET logic
In _ocp_softreset(), after _set_softreset() + write_sysconfig(),
the hwmod's sysc_cache will always contain SOFTRESET bit set
so all further writes to sysconfig using this cache will initiate
a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like
platforms that have RESET_DONE status in the SYSSTATUS register and
so the the SOFTRESET bit in SYSCONFIG is not automatically cleared.
It is not a problem for OMAP4 like platforms that indicate RESET
completion by clearing the SOFTRESET bit in the SYSCONFIG register.
This repeated SOFTRESET is undesired and was the root cause of
USB host issues on OMAP3 platforms when hwmod was allowed to do the
SOFTRESET for the USB Host module.
To fix this we clear the SOFTRESET bit and update the sysconfig
register + sysc_cache using write_sysconfig().
Signed-off-by: Roger Quadros rog...@ti.com
[p...@pwsan.com: renamed _clr_softreset() to _clear_softreset()]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 43 +++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e3f0ecaf87dd..cacc0c7e8634 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -399,7 +399,7 @@ static int _set_clockactivity(struct omap_hwmod *oh, u8
clockact, u32 *v)
}
/**
- * _set_softreset: set OCP_SYSCONFIG.CLOCKACTIVITY bits in @v
+ * _set_softreset: set OCP_SYSCONFIG.SOFTRESET bit in @v
* @oh: struct omap_hwmod *
* @v: pointer to register contents to modify
*
@@ -427,6 +427,36 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
}
/**
+ * _clear_softreset: clear OCP_SYSCONFIG.SOFTRESET bit in @v
+ * @oh: struct omap_hwmod *
+ * @v: pointer to register contents to modify
+ *
+ * Clear the SOFTRESET bit in @v for hwmod @oh. Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int _clear_softreset(struct omap_hwmod *oh, u32 *v)
+{
+ u32 softrst_mask;
+
+ if (!oh-class-sysc ||
+ !(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET))
+ return -EINVAL;
+
+ if (!oh-class-sysc-sysc_fields) {
+ WARN(1,
+omap_hwmod: %s: sysc_fields absent for sysconfig class\n,
+oh-name);
+ return -EINVAL;
+ }
+
+ softrst_mask = (0x1 oh-class-sysc-sysc_fields-srst_shift);
+
+ *v = ~softrst_mask;
+
+ return 0;
+}
+
+/**
* _wait_softreset_complete - wait for an OCP softreset to complete
* @oh: struct omap_hwmod * to wait on
*
@@ -1911,6 +1941,12 @@ static int _ocp_softreset(struct omap_hwmod *oh)
ret = _set_softreset(oh, v);
if (ret)
goto dis_opt_clks;
+
+ _write_sysconfig(v, oh);
+ ret = _clear_softreset(oh, v);
+ if (ret)
+ goto dis_opt_clks;
+
_write_sysconfig(v, oh);
if (oh-class-sysc-srst_udelay)
@@ -3169,6 +3205,11 @@ int omap_hwmod_softreset(struct omap_hwmod *oh)
goto error;
_write_sysconfig(v, oh);
+ ret = _clear_softreset(oh, v);
+ if (ret)
+ goto error;
+ _write_sysconfig(v, oh);
+
error:
return ret;
}
--
1.8.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: OMAP2+: USB Host bug fixes for 3.13 rc
On Wed, 4 Dec 2013, Tomi Valkeinen wrote: Tested on Panda and Beagle xM. Works fine for me. Thanks, added your Tested-by's to both patches that I've queued. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
On Sun, 8 Dec 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [131208 17:27]: On Tue, 3 Dec 2013, Roger Quadros wrote: Without this, the USB devices are sometimes not detected on OMAP4 Panda with u-boot v2013.10. Unlike what the comment states, errata i660 does not state that we can't RESET the USB host module. Instead it states that RESET is the only way to recover from a deadlock situation. RESET ensures that the module is in a known good state irrespective of what bootloader does with the module, so it must be done at boot. Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Will you pick this up for the -rc series, or do you want me or Tony to? Roger writes that this one's pretty important. I suggest that you just queue this with your other fixes so we get things working. I'm going to wait until tomorrow anyway to see if Sathya responds to my other E-mail, so maybe Benoît will let us know by then. - Paul
Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda
On Mon, 2 Dec 2013, Roger Quadros wrote: It won't be done by omap_hwmod as we set HWMOD_INIT_NO_RESET flag in the hwmod data [1]. Question is do we do it in the driver of leave it to hwmod? It should be done by hwmod (or more broadly, some OMAP bus code). That way the device can be brought to a known state even if there's no driver present (e.g., if the driver was built as a module). The other concern about i660 is in this comment [1] /* * During system boot; If the hwmod framework resets the module * the module will have smart idle settings; which can lead to deadlock * (above Errata Id:i660); so, dont reset the module during boot; * Use HWMOD_INIT_NO_RESET. */ But if you look at the errata document [2], Advisory 1.108, it doesn't say that we can't be in smart-idle, but only that we should put the module in force-idle, before cutting the module's functional clock. Yes, that looks to be correct. There shouldn't be any problem with the module being in smart-idle mode if the PRCM doesn't try to put it into a low-power mode. It already has the HWMOD_SWSUP_SIDLE flag set, so seems to me it should work fine without HWMOD_INIT_NO_RESET, if i660 is the only issue. Most of the IP blocks that are marked with HWMOD_INIT_NO_RESET are only that way due to laziness, or lack of time, etc., and should be closely reviewed. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: host: tegra: CONFIG_USB_EHCI_TEGRA requires ULPI and ULPI viewport support
Selecting CONFIG_USB_EHCI_TEGRA requires CONFIG_USB_ULPI_VIEWPORT. Otherwise the build can break with: drivers/usb/phy/phy-tegra-usb.c: In function 'ulpi_open': drivers/usb/phy/phy-tegra-usb.c:689:31: error: 'ulpi_viewport_access_ops' undeclared (first use in this function) drivers/usb/phy/phy-tegra-usb.c:689:31: note: each undeclared identifier is reported only once for each function it appears in if CONFIG_USB_ULPI_VIEWPORT is not manually selected. Fix by forcing CONFIG_USB_ULPI_VIEWPORT to be selected when CONFIG_USB_EHCI_TEGRA is selected. Then, since CONFIG_USB_ULPI_VIEWPORT requires CONFIG_USB_ULPI to be selected, add that too. N.B.: ULPI is deprecated on this controller for T114, so it might make sense to split the ULPI support code into a separate file, compiled only if a ULPI PHY is selected. Signed-off-by: Paul Walmsley pwalms...@nvidia.com Cc: sta...@vger.kernel.org --- Observed while building the stable kernels v3.11.[123] with a T114-only Kconfig. drivers/usb/host/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 4263d01..81b9d34 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -202,6 +202,8 @@ config USB_EHCI_TEGRA depends on ARCH_TEGRA select USB_EHCI_ROOT_HUB_TT select USB_PHY + select USB_ULPI + select USB_ULPI_VIEWPORT help This driver enables support for the internal USB Host Controllers found in NVIDIA Tegra SoCs. The controllers are EHCI compliant. -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: host: tegra: CONFIG_USB_EHCI_TEGRA requires ULPI and ULPI viewport support
On 10/04/2013 09:04 AM, Stephen Warren wrote: On 10/04/2013 12:02 AM, Paul Walmsley wrote: Selecting CONFIG_USB_EHCI_TEGRA requires CONFIG_USB_ULPI_VIEWPORT. Otherwise the build can break with: drivers/usb/phy/phy-tegra-usb.c: In function 'ulpi_open': drivers/usb/phy/phy-tegra-usb.c:689:31: error: 'ulpi_viewport_access_ops' undeclared (first use in this function) drivers/usb/phy/phy-tegra-usb.c:689:31: note: each undeclared identifier is reported only once for each function it appears in if CONFIG_USB_ULPI_VIEWPORT is not manually selected. Fix by forcing CONFIG_USB_ULPI_VIEWPORT to be selected when CONFIG_USB_EHCI_TEGRA is selected. Then, since CONFIG_USB_ULPI_VIEWPORT requires CONFIG_USB_ULPI to be selected, add that too. N.B.: ULPI is deprecated on this controller for T114, so it might make sense to split the ULPI support code into a separate file, compiled only if a ULPI PHY is selected. This was fixed at least in 3.13 (perhaps 3.12 too?) by: config ARCH_TEGRA ... select USB_ARCH_HAS_EHCI if USB_SUPPORT select USB_ULPI if USB_PHY select USB_ULPI_VIEWPORT if USB_PHY I think it'd be better to back-port that patch to stable, for consistency. Yep agreed. Want to cc that patch to linux-stable instead? The v3.13.x -stable builds are breaking here for T114-only Kconfigs... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
Hi Roger, On Tue, 5 Feb 2013, Roger Quadros wrote: On 01/21/2013 05:03 PM, Paul Walmsley wrote: Hi On Mon, 21 Jan 2013, Roger Quadros wrote: On 01/18/2013 10:27 PM, Paul Walmsley wrote: On Fri, 18 Jan 2013, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@linaro.com Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Per Tony's earlier request, you can drop this patch and patch 20 from your series now. I've got them queued for 3.10 or late 3.9 merge window. Should have mentioned it earlier, but just this patch without the rest of the cleanup patches will break USB Host on OMAP3, as the old driver bails out if optional clock nodes are missing. Including patch 20 doesn't seem to cause a problem with OMAP4 though. I've got these two patches queued for merging after your other patches go upstream -- e.g., probably 3.10. Do you foresee any problems with that? FYI, the usbhost patches are already in linux-next. Queued this patch for v3.11; looks like I missed it for v3.10. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
Hi On Mon, 21 Jan 2013, Roger Quadros wrote: On 01/18/2013 10:27 PM, Paul Walmsley wrote: On Fri, 18 Jan 2013, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@linaro.com Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Paul Walmsley p...@pwsan.com Per Tony's earlier request, you can drop this patch and patch 20 from your series now. I've got them queued for 3.10 or late 3.9 merge window. Should have mentioned it earlier, but just this patch without the rest of the cleanup patches will break USB Host on OMAP3, as the old driver bails out if optional clock nodes are missing. Including patch 20 doesn't seem to cause a problem with OMAP4 though. I've got these two patches queued for merging after your other patches go upstream -- e.g., probably 3.10. Do you foresee any problems with that? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
Hi Roger, On Thu, 17 Jan 2013, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130117 03:34]: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. It's best that Paul queues this and the next patch as these clock alias clean-up patches can be done separately. That way the dependency between arch/arm/*omap* code is cut away as these files should be moved to live under drivers/clk/omap. Per Tony's request, I'll queue these two cleanup patches for 3.10 -- or whatever Linus will call it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
On Thu, 17 Jan 2013, Felipe Balbi wrote: do you mean v3.9 ? It sounds like the other patches need to be merged first before these cleanups can be merged. So rather than adding a merge order dependency during 3.9, it seems best to queue the non-essential clock cleanup side for 3.10. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
On Thu, 17 Jan 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [130117 14:33]: On Thu, 17 Jan 2013, Felipe Balbi wrote: do you mean v3.9 ? It sounds like the other patches need to be merged first before these cleanups can be merged. So rather than adding a merge order dependency during 3.9, it seems best to queue the non-essential clock cleanup side for 3.10. How about let's do it in a late cleanup branch towards the end of the v3.9 merge window? That's fine with me too if the arm-soc folks are willing. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On Mon, 17 Dec 2012, Benoit Cousson wrote: It was done for legacy reason but should disappear once the modulemode will be be removed from the clock nodes. Here's a start at taking care of the low-hanging fruit: http://marc.info/?l=linux-omapm=135577685007813w=2 Only lightly tested, so tests with Kconfigs with lots of OMAP drivers enabled would be appreciated. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 21/23] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
On Mon, 10 Dec 2012, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks and neither the dummy clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@gmail.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 22/23] ARM: OMAP4: clock data: get rid of unused USB host clock aliases
On Mon, 10 Dec 2012, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks so remove them. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com CC: Mike Turquette mturque...@gmail.com Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
+ Benoît, Mike Hi Roger, On Tue, 4 Dec 2012, Roger Quadros wrote: There is no such clock as utmi_p1_gfclk. It is only a clock selector bit to select th the parent of usb_host_hs_utmi_p1_clk. So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively. CC: Paul Walmsley p...@pwsan.com CC: Rajendra Nayak rna...@ti.com CC: Benoit Cousson b-cous...@ti.com Signed-off-by: Roger Quadros rog...@ti.com This one needs careful review from Benoît; these were originally autogenerated, and it would be nice to return to an autogenerated clock tree for OMAP4... - Paul
Re: [PATCH v2 21/22] ARM: OMAP2+: clock data: get rid of unused USB host clock aliases
On Wed, 28 Nov 2012, Roger Quadros wrote: We don't need multiple aliases for the OMAP USB host clocks so remove them. Also use NULL dev_id for 'usb_tll_hs_usb_ch0_clk' and 'usb_tll_hs_usb_ch1_clk' Signed-off-by: Roger Quadros rog...@ti.com CC: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/clock3xxx_data.c | 11 --- 1 files changed, 0 insertions(+), 11 deletions(-) Looks okay to me, but this will need to be updated to apply after the common clock framework conversion patches are merged. Maybe respin this against what's in arm-soc/for-next ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
On Fri, 26 Oct 2012, Benoit Cousson wrote: On 10/26/2012 05:16 PM, Roger Quadros wrote: I still can't get musb to work on 3.7-rc2. Apparently it is still missing the patches from Benoit's for_3.7/dts_part2. Maybe I just need to wait for it to be merged? They are now in a for_3.8/dts. Unfortunately, one patch that was adding ctrl_module address in the USB data was rejected and thus I'm not sure it will work without that. For v3.7-rc timeframe, looks like it's waiting on an ack from you: http://www.spinics.net/lists/arm-kernel/msg201028.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: USB problem on beagleboard clone
On Wed, 19 Sep 2012, Maximilian Schwerin wrote: They're BeagleBoard XM clones. We're still trying to find out what the real problem is. The problem persists across three separate layouts using the same USB device and application. We're currently trying to see if this is related to MUSB only by using an EHCI port on the same board with the same device and application. Perhaps you might try this patch: http://marc.info/?l=linux-omapm=132976109928744w=2 Background is here: http://comments.gmane.org/gmane.linux.ports.arm.omap/71633 The patch is for an EHCI issue, but MUSB is clocked from the same DPLL. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] ARM: OMAP: Add the USB TLL clocks device name
On Mon, 16 Jul 2012, Keshava Munegowda wrote: The platform device name usbhs_tll is added for the functional, interface and channel clocks of the TLL module. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Thanks, queued this patch for 3.7. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 5/5] ARM: OMAP: Remove older device name of the USB TLL clocks
Hi On Mon, 16 Jul 2012, Keshava Munegowda wrote: The usbhs device name of the functional, interface and channel clocks of the TLL module is removed. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Reviewed-by: Partha Basak part...@india.ti.com Please re-send this one separately once patches 2-4 of this series have been merged. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation
Hi Samuel, I've queued patch 1 of this series for 3.7, which should go upstream via the OMAP - arm-soc path. Also asked Keshava to re-send patch 5 to me once patches 2-4 have been merged. It's up to you how to handle patches 2-4. The series is a good step forward for us in terms of cleanup. But what is probably worthwhile at some point is for that USB TLL phy code (added in patch 2) to be moved into some place like drivers/usb/phy, since it's not MFD-related. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB problem on beagleboard clone
Hi On Fri, 14 Sep 2012, Maximilian Schwerin wrote: we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Are these BeagleBoard 3530 or BeagleBoard XM 3730 clones? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
