Re: OMAP3/AM3517 EHCI USB Issue
On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is
Re: [PATCH 1/1] clk: ti: add support for external clock provider
On 08/01/2014 04:15 PM, Tero Kristo wrote: External clock provider can now be used to register external clocks under it. This is needed as the TI clock driver only registers clocks hierarchically under clock providers, and external clocks do not belong under any of the current ones. Signed-off-by: Tero Kristo t-kri...@ti.com Tested-by: Jyri Sarha jsa...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Laurent,
On Wed, Jul 30, 2014 at 2:06 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
The third option would require storing the clocks lists in device drivers. I
believe this is our best option, as a trade-off between simplicity and
versatility. Drivers that use runtime PM already need to enable it explicitly
when probing devices. Passing a list of clock names to runtime PM at that
point wouldn't complicate drivers much. When the clocks list isn't SoC-
dependent it could be stored as static information. Otherwise it could be
derived from DT (or any other source of hardware description) using C code,
offering all the versatility we need.
The only drawback of this solution I can think of right now is that the
runtime PM core couldn't manage device clocks before probing the device.
Specifically device clocks couldn't be managed if no driver is loaded for that
device. I somehow recall that someone raised this as being a problem, but I
can't remember why.
Perhaps you're thinking of clocks that were enabled (by the boot loader or
implicit reset state) before running Linux, and aren't disabled?
That was fixed by commit bb178da701382a230e26d90cf94e8a24b280e0d9
(clk: shmobile: mstp: Fix the is_enabled() operation).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
On 08/01/2014 04:15 PM, Tero Kristo wrote: Hi, This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips. Just one question to Mike and Tero: would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)). This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] remoteproc: use a flag to detect the presence of IOMMU
On Tue, Jul 29, 2014 at 7:10 PM, Suman Anna s-a...@ti.com wrote: We are trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend/resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. That's perfect, thanks. Can you please add this use case description to the commit log? This way we'll be able to recover it easily one day if needed. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
On 08/04/2014 02:37 PM, Peter Ujfalusi wrote: On 08/01/2014 04:15 PM, Tero Kristo wrote: Hi, This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips. Just one question to Mike and Tero: would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)). Other platforms initialize their clocks in different manner, they can use generic of_clk_init I believe. If they can't use that for some reason, then they need to implement something similar to this. -Tero This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- 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
[PATCH] ARM: OMAP2+: omap_device: remove warning that clk alias already exists
When an alias for a clock already exists the warning is printed. For
every module with a main_clk defined, a clk alias for fck is added.
There are some components that have the same main_clk defined, so this
is a really normal situation.
For example the am33xx edma device has 4 components using the same main
clock. So there are three warnings in the boot log for this already
existing clock alias:
platform 4900.edma: alias fck already exists
platform 4900.edma: alias fck already exists
platform 4900.edma: alias fck already exists
As this is only interesting for developers, this patch changes the
message to a debug message.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/mach-omap2/omap_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 01ef59def44b..d22c30d3ccfa 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -56,7 +56,7 @@ static void _add_clkdev(struct omap_device *od, const char
*clk_alias,
r = clk_get_sys(dev_name(od-pdev-dev), clk_alias);
if (!IS_ERR(r)) {
- dev_warn(od-pdev-dev,
+ dev_dbg(od-pdev-dev,
alias %s already exists\n, clk_alias);
clk_put(r);
return;
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain
Hi Geert, On Monday 04 August 2014 13:28:32 Geert Uytterhoeven wrote: On Wed, Jul 30, 2014 at 2:06 AM, Laurent Pinchart wrote: The third option would require storing the clocks lists in device drivers. I believe this is our best option, as a trade-off between simplicity and versatility. Drivers that use runtime PM already need to enable it explicitly when probing devices. Passing a list of clock names to runtime PM at that point wouldn't complicate drivers much. When the clocks list isn't SoC- dependent it could be stored as static information. Otherwise it could be derived from DT (or any other source of hardware description) using C code, offering all the versatility we need. The only drawback of this solution I can think of right now is that the runtime PM core couldn't manage device clocks before probing the device. Specifically device clocks couldn't be managed if no driver is loaded for that device. I somehow recall that someone raised this as being a problem, but I can't remember why. Perhaps you're thinking of clocks that were enabled (by the boot loader or implicit reset state) before running Linux, and aren't disabled? That wasn't the reason, I know that clk_disable_unused() takes care of that problem (provided the clock drivers behave correctly, the commit you mention below shows that's not always the case, but that's an unrelated issue). That was fixed by commit bb178da701382a230e26d90cf94e8a24b280e0d9 (clk: shmobile: mstp: Fix the is_enabled() operation). -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3/AM3517 EHCI USB Issue
On Mon, Aug 04, 2014 at 12:34:16PM +0300, Roger Quadros wrote: On 08/02/2014 02:51 AM, Michael Welling wrote: On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling mwell...@emacinc.com wrote: On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: On 07/29/2014 06:20 PM, Michael Welling wrote: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a
Re: [PATCH 1/2] remoteproc: use a flag to detect the presence of IOMMU
On 08/04/2014 06:50 AM, Ohad Ben-Cohen wrote: On Tue, Jul 29, 2014 at 7:10 PM, Suman Anna s-a...@ti.com wrote: We are trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend/resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. That's perfect, thanks. Can you please add this use case description to the commit log? I kept the current description generic, but sure, I can add this specific usecase examples to the commit log. I will post the revised patches once rc1 is out. regards Suman -- 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
