Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
* Felipe Balbi ba...@ti.com [140729 09:36]:
Hi,
On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote:
On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140729 07:18]:
Hi,
On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [140728 14:19]:
now that we don't need to support legacy board-files,
we can completely switch over to a linear irq domain
and make use of irq_alloc_domain_generic_chips() to
allocate all generic irq chips for us.
This patch seems to somehow break off-idle for omap3
where it no longer wakes up.
Sure your bisection is correct ? This patch just switches from legacy
irq domain to linear irq domain.
Yes, I tried it a few times. Just enabling
retention idle hangs too with this patch.
Maybe it's omap3_prcm_irq_setup that relies on
11 + OMAP_INTC_START? There may be other such issues
lol.
OMAP4 has the same nonsense.
made me think why (if) OMAP4 works with that same setup. Does wake from
OFF work with OMAP4 ?
Not without similar changes, omap4+ has the same issue.. There's a RFC
series from Nishant to fix some of this, and Tero is moving the PRCM
into a driver.
Anyway, here's a quick little hack to check if that's the reason for the
regression:
OK yeah that's along the same lines with Nishant's RFC series in thread
[RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of
interrupts
FYI, it did not compile, needs to include linux/of_irq.h. But yes,
it fixes the regression for me, Also now the whole series works for
me :)
Regards,
Tony
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ff953c9..c234b98 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -97,6 +97,7 @@
prm: prm@48306000 {
compatible = ti,omap3-prm;
reg = 0x48306000 0x4000;
+ interrupts = 11;
prm_clocks: clocks {
#address-cells = 1;
diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 25e8b82..3d11377 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -242,6 +242,11 @@ void omap_prcm_irq_complete(void)
prcm_irq_setup-restore_irqen(prcm_irq_setup-saved_mask);
}
+static struct of_device_id tmp[] = {
+ { .compatible = ti,omap3-prm },
+ { }
+};
+
/**
* omap_prcm_register_chain_handler - initializes the prcm chained interrupt
* handler based on provided parameters
@@ -254,17 +259,24 @@ void omap_prcm_irq_complete(void)
*/
int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
{
+ struct device_node *node;
int nr_regs;
u32 mask[OMAP_PRCM_MAX_NR_PENDING_REG];
int offset, i;
+ int irq;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
if (!irq_setup)
return -EINVAL;
+ irq = irq_setup-irq;
nr_regs = irq_setup-nr_regs;
+ node = of_find_matching_node(NULL, tmp);
+ if (node)
+ irq = of_irq_get(node, 0);
+
if (prcm_irq_setup) {
pr_err(PRCM: already initialized; won't reinitialize\n);
return -EINVAL;
@@ -298,7 +310,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
1 (offset 0x1f);
}
- irq_set_chained_handler(irq_setup-irq, omap_prcm_irq_handler);
+ irq_set_chained_handler(irq, omap_prcm_irq_handler);
irq_setup-base_irq = irq_alloc_descs(-1, 0, irq_setup-nr_regs * 32,
0);
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
* Felipe Balbi ba...@ti.com [140729 09:42]: Hi, On Tue, Jul 29, 2014 at 02:38:24PM +0200, Laurent Pinchart wrote: On Wednesday 23 July 2014 14:29:36 Kishon Vijay Abraham I wrote: On Monday 21 July 2014 08:45 PM, Felipe Balbi wrote: On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote: Hi Felipe, What happened to these two patches ? looks like I lost them. On Monday 16 December 2013 17:48:29 Felipe Balbi wrote: On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy Kishon, are these still valid ? Looks like board-2430sdp.c got removed. Apart from that the reset of the patch series is still applicable for non-dt boot. Felipe, do you plan to apply the patch without the baord-2430sdp.c change, or would you like Kishon to rebase and resubmit it ? Not sure if Tony still wants board-* modifications. Tony ? Well omap2 is DT only already, so sounds like you can just ignore board-2430sdp.c as it no longer exists. If there are other minimal board-*.c file changes needed, then that's fine as long as they fix things or are needed to keep things working. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.16-rc4
On Tue, 29 Jul 2014, Tony Lindgren wrote: The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one? 3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others). http://www.pwsan.com/omap/testlogs/next_20140729/20140730010841/pm/3530es3beagle/3530es3beagle_log.txt Adding the patch you sent doesn't change that, but now some extra warning messages appear (PRM: I/O chain clock line assertion timed out): http://www.pwsan.com/omap/testlogs/next_20140729_beagle_pm/20140730004856/pm/3530es3beagle/3530es3beagle_log.txt - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3/AM3517 EHCI USB Issue
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 enabled? Is this a flag in an entry in the devicetree? there is a pm_debug file on debugfs which you can use. Set autosuspend delay to UART (it's set to -1 by default, IIRC), then leave the board
Re: [PATCH v2] ARM: AM43xx: hwmod: add DSS hwmod data
On 23/07/14 00:14, Paul Walmsley wrote: On Tue, 17 Jun 2014, Tomi Valkeinen wrote: From: Sathya Prakash M R sath...@ti.com Add DSS hwmod data for AM43xx. Signed-off-by: Sathya Prakash M R sath...@ti.com [tomi.valkei...@ti.com: added missing dispc flags] Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Acked-by: Rajendra Nayak rna...@ti.com This one didn't compile on an AM43xx-only build: arch/arm/mach-omap2/built-in.o:(.data+0x3f2c): undefined reference to `omap2_dss_hwmod_class' arch/arm/mach-omap2/built-in.o:(.data+0x405c): undefined reference to `omap2_rfbi_hwmod_class' make: *** [vmlinux] Error 1 test_build: Tue Jul 22 13:48:50 MDT 2014: FAILED on omap2plus_defconfig_am43xx_only hwmod-a-v3.17 Have queued the following patch instead. Thanks. Tested on AM437x GP EVM with today's linux-next. Works fine for me. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest rate
On 23/07/14 13:44, Paul Walmsley wrote: Change the behavior of omap2_dpll_round_rate() to round to either the exact rate requested, or the next lowest rate that the clock is able to provide. This is not an ideal fix, but is intended to provide a relatively safe way for drivers to set PLL rates, until a better solution can be implemented. For the time being, omap3_noncore_dpll_set_rate() is still allowed to set its rate to something other than what the caller requested; but will warn when this occurs. Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Mike Turquette mturque...@linaro.org Signed-off-by: Paul Walmsley p...@pwsan.com Tested on AM437x GP EVM with today's linux-next + this patch. Without the patch I was only able to use certain pixel clocks, but with this patch I can select the pixel clock freely (they end up rounded, of course). So looks good to me. Thanks for working on this! Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? -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
Re: [PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
On 07/16/2014 03:29 AM, Laurent Pinchart wrote:
Hi Stefan,
Thank you for the patch.
On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tero, could you please process it for v3.17 if time still permits ?
This is too late for 3.17 merge window as I was on holiday last few
weeks. Queued for 3.17-rc early fixes though.
-Tero
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
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 07/30/2014 03:06 AM, Laurent Pinchart wrote:
Hi Grygorii and Grant,
On Monday 28 July 2014 23:52:34 Grant Likely wrote:
On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
On 07/28/2014 05:05 PM, Grant Likely wrote:
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote:
Use clkops-clocks property to specify clocks handled by
clock_ops domain PM domain. Only clocks defined in clkops-clocks
set of clocks will be handled by Runtime PM through clock_ops
Pm domain.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/of/of_clk.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_clk.c b/drivers/of/of_clk.c
index 35f5e9f..5f9b90e 100644
--- a/drivers/of/of_clk.c
+++ b/drivers/of/of_clk.c
@@ -86,11 +86,8 @@ int of_clk_register_runtime_pm_clocks(struct
device_node *np,
struct clk *clk;
int error;
-for (i = 0; (clk = of_clk_get(np, i)) !IS_ERR(clk); i++) {
-if (!clk_may_runtime_pm(clk)) {
-clk_put(clk);
-continue;
-}
+for (i = 0; (clk = of_clk_get_from_set(np, clkops, i))
+ !IS_ERR(clk); i++) {
This really looks like an ABI break to me. What happens to all the
existing platforms who don't have this new clkops-clocks in their device
tree?
Agree. This patch as is will break such platforms.
As possible solution for above problem - the NULL can be used as clock's
prefix by default and platform code can configure new value of clock's
prefix during initialization.
In addition, to make this solution full the of_clk_get_by_name() will
need to be modified too.
But note pls, this is pure RFC patches which I did to find out the answer
on questions: - What is better: maintain Runtime PM clocks configuration
in DT or in code?
In code. I don't think it is workable to embed runtime PM behaviour
into the DT bindings. I think there will be too much variance in what
hardware requires. We can create helpers to make this simpler, but I
don't think it is a good idea to set it up automatically without any
control from the driver itself.
- Where and when to call of_clk_register_runtime_pm_clocks()?
Bus notifier/ platform core/ device drivers
I would say in device drivers.
I tend to agree with that.
It will help here to take a step back and remember what the problem we're
trying to solve is.
At the root is clock management. Our system comprise many clocks, and they
need to be handled. The Common Clock Framework nicely models the clocks, and
offers an API for drivers to retrieve device clocks and control them. Drivers
can thus implement clock management manually without much pain.
A clock can be managed in roughly three different ways :
- it can be enabled at probe time and disabled at remove time ;
- it can be enabled right before the device leaves its idle state and disabled
when the device goes back to idle ; or
- it can be enabled and disabled in a more fine-grained, device-specific
manner.
The selected clock management granularity depends on constraints specific to
the device and on how aggressive power saving needs to be. Enabling the clocks
at probe time and disabling them at remove time is enough for most devices,
but leads to a high power consumption. For that reason the second clock
management scheme is often desired.
Managing clocks manually in the driver is a valid option. However, when adding
runtime PM to the equation, and realizing that the clocks need to be enabled
in the runtime PM resume handler and disabled in the suspend handler, the
clock management code starts looking very similar in most drivers. We're thus
tempted to factorize it away from the drivers into a shared location.
It's important to note at this point that the goal here is only to simplify
drivers. Moving clock management code out of the drivers doesn't (unless I'm
missing something) open the door to new possibilities, it just serves as a
simplification.
Now, as Grygorii mentioned, differences between how a given IP core is
integrated in various SoCs can make clock management SoC-dependent. In the
vast majority of cases (which is really what we need to target, given that our
target is simplifying drivers) SoC integration can be described as a list of
clocks that must be managed. That list can be common to all devices in a given
SoC, or can be device-dependent as well.
That's actually a problem - now we have static list of managed clocks per-SoC
and
not per device.
Few locations can be used to express a per-device list of per-SoC clocks. We
can have clocks lists in a per-SoC and per-device location, per-device clocks
lists in an SoC-specific location, or per-SoC clocks lists in a device-
specific location.
The first option would require listing clocks to be managed by runtime PM in
DT nodes, as proposed by this patch set. I don't think
Re: [PATCH] ARM: dts: set 'ti,set-rate-parent' for dpll4_m5x2 clock
On Wednesday 30 July 2014 15:40:33 Tero Kristo wrote:
On 07/16/2014 03:29 AM, Laurent Pinchart wrote:
On Tuesday 15 July 2014 12:02:35 Stefan Herbrechtsmeier wrote:
Set 'ti,set-rate-parent' property for the dpll4_m5x2_ck clock, which
is used for the ISP functional clock. This fixes the OMAP3 ISP driver's
clock rate configuration on OMAP34xx, which needs the rate to be
propagated properly to the divider node (dpll4_m5_ck).
Signed-off-by: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-me...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Tero, could you please process it for v3.17 if time still permits ?
This is too late for 3.17 merge window as I was on holiday last few
weeks. Queued for 3.17-rc early fixes though.
Kiitos.
---
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
b/arch/arm/boot/dts/omap3xxx-clocks.dtsi index e47ff69..5c37500 100644
--- a/arch/arm/boot/dts/omap3xxx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3xxx-clocks.dtsi
@@ -467,6 +467,7 @@
ti,bit-shift = 0x1e;
reg = 0x0d00;
ti,set-bit-to-disable;
+ ti,set-rate-parent;
};
dpll4_m6_ck: dpll4_m6_ck {
--
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: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. cheers -- balbi signature.asc Description: Digital signature
[PATCH v4 0/3] Add ST dwc3 glue layer driver
This series adds support for the ST glue logic which wraps the DWC3 controller on STiH407 SoC family chipsets. Changes since v3 - Various formating nits Changes since v2 - Use dr_mode for host/device static configuration - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy - Remove DT checks and make driver depend on OF - Change some #define to use BIT macro - Make some comments clearer - Use kerneldoc for struct documentation - Remove udelay - Let DT create platform_devices, and remove legacy alloc - Change some logging levels to dev_dbg - Various whitespace and formatting cleanup - Use SIMPLE_DEV_PM_OPS() - Add const to of_device struct - Reorder header files alphabetically - Use devm_ioremap_resource instead of devm_request_and_ioremap - Remove of_match_ptr() Changes since v1 - Fix Kconfig mistake Peter Griffin (3): usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture Documentation/devicetree/bindings/usb/dwc3-st.txt | 69 + MAINTAINERS | 1 + drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-st.c| 336 ++ 5 files changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt create mode 100644 drivers/usb/dwc3/dwc3-st.c -- 1.9.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
[PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 336 +
3 files changed, 346 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8eb996e..6c85c43 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
+ default USB_DWC3_HOST
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment Debugging features
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..227698f
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,336 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ * Contributors: Aymen Bouattay aymen.bouat...@st.com
+ * Peter Griffin peter.grif...@linaro.org
+ *
+ * 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.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/reset.h
+#include linux/usb/of.h
+
+#include core.h
+#include io.h
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_signal_name from usb3_top is selected
+ * 2’b10 : pipew_signal_name from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG 0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n) (n 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n 4)
+#define SEL_OVERRIDE_BVALID(n) (n 8)
+
+/* Static DRD configuration */
+#define USB_HOST_DEFAULT_MASK 0xffe
+#define USB_SET_PORT_DEVICE0x1
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst: reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+ void __iomem *glue_base;
+ struct regmap *regmap;
+ int syscfg_reg_off;
+ enum usb_dr_mode dr_mode;
+ struct reset_control *rstc_pwrdn;
+ struct reset_control *rstc_rst;
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+ return readl_relaxed(base + offset);
+}
+
+static inline void st_dwc3_writel(void __iomem *base, u32
[PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 69 +++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..de3fea3
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,69 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be st,stih407-dwc3
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be reg-glue and syscfg-reg
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be powerdown and
softreset
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named default must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
+is otg, which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either host
+or device.
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = disabled;
+ compatible = st,stih407-dwc3;
+ reg = 0x08f94000 0x1000, 0x110 0x4;
+ reg-names = reg-glue, syscfg-reg;
+ st,syscfg = syscfg_core;
+ resets = powerdown STIH407_USB3_POWERDOWN;
+ softreset STIH407_MIPHY2_SOFTRESET;
+ reset-names = powerdown,
+ softreset;
+ #address-cells = 1;
+ #size-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usb3;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = snps,dwc3;
+ reg = 0x0990 0x10;
+ interrupts = GIC_SPI 155 IRQ_TYPE_NONE;
+ dr_mode = host
+ usb-phy = usb3_phy;
+ phy-names = usb2-phy;
+ phys= usb2_picophy2;
+ };
+};
--
1.9.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
[PATCH v4 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
Signed-off-by: Peter Griffin peter.grif...@linaro.org Acked-by: Lee Jones lee.jo...@linaro.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 702ca10..269ad3b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c F: drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek ker...@wantstofly.org -- 1.9.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: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. -- --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
Hi, On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote: On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. That'd be great. It would be ever greater if you could add support for OMAP3 on that too. cheers -- balbi signature.asc Description: Digital signature
Re: OMAP3/AM3517 EHCI USB Issue
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 enabled?
[PATCH] ARM: dts: DRA7: fix interrupt-cells for GPIO
GPIO modules are also interrupt sources. However, they require both the
GPIO number and IRQ type to function properly.
By declaring that GPIO uses interrupt-cells=1, we essentially do not
allow users of the nodes to use the interrupt property appropritely.
With this change, the following now works:
interrupt-parent = gpio6;
interrupts = 5 IRQ_TYPE_LEVEL_LOW;
Fixes: 6e58b8f1daaf ('ARM: dts: DRA7: Add the dts files for dra7 SoC and
dra7-evm board')
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on v3.16-rc7
arch/arm/boot/dts/dra7.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8012763..f21ef39 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -172,7 +172,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@48055000 {
@@ -183,7 +183,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@48057000 {
@@ -194,7 +194,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@48059000 {
@@ -205,7 +205,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@4805b000 {
@@ -216,7 +216,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@4805d000 {
@@ -227,7 +227,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio7: gpio@48051000 {
@@ -238,7 +238,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio8: gpio@48053000 {
@@ -249,7 +249,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
uart1: serial@4806a000 {
--
1.7.9.5
--
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] ARM: dts: dra7-evm: add parallel NOR flash support
Hi Roger,
On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros rog...@ti.com wrote:
On 07/23/2014 01:58 PM, Pekon Gupta wrote:
This patch adds support for parallel NOR device (S29GL512S10) present on
J6-EVM.
The Flash device is connected to GPMC controller on chip-select[0] and
accessed
as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits)
and
is CFI compatible.
As multiple devices are share GPMC pins on this board, so following board
settings are required to detect NOR device:
SW5.1 (NAND_BOOTn) = OFF (logic-1)
SW5.2 (NOR_BOOTn) = ON (logic-0) /* Active-low */
SW5.3 (eMMC_BOOTn) = OFF (logic-1)
SW5.4 (QSPI_BOOTn) = OFF (logic-1)
Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
If you see the schematics of J6-EVM, GPMC data and control lines are shared
between NAND, NOR, eMMC (and probably QSPI also).
I don't have access to TI's hardaware or board schematics anymore, so
please double check.
Also to maintain NAND Boot functionality, following setting are kept as
default
- NAND status=enabled
- NOR status=disabled
Too bad they designed the hardware so that either NOR or NAND can be used at
a time.
Better to mention about this limitation by stating that CS0 is shared between
NOR and NAND
and only one can be used at a time.
NAND/NOR/eMMC/QSPI effectively all are storage devices, so users may
not use all of
them at once, so may be to optimize usage of pins they added multiple
devices on CS0.
Sorry, I may not be able to re-spin this patch anytime soon, as I have
no access to TI
resources so request you to please re-send it with appropriate commit
log change as you wish.
Signed-off-by: Pekon Gupta pe...@ti.com
---
/* Flash read/write access tested after enabling NOR sub-node in DT */
linux# flash_erase /dev/mtd9 0 0
linux# dd if=/dev/urandom of=/tmp/source.hex bs=1c count=2048
linux# mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
linux# mtd_debug read /dev/mtd9 0x0 2048 /tmp/destination.hex
linux# diff /tmp/source.hex /tmp/destination.hex
arch/arm/boot/dts/dra7-evm.dts | 141
-
1 file changed, 140 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..1ee9727 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,66 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ nor_flash_x16: nor_flash_x16 {
+ /* On DRA7 EVM, NOR_BOOTn comes from DIP switch
+ * So NOR flash requires following switch settings:
+ * SW5.1 (NAND_BOOTn) = OFF (logic-1)
+ * SW5.2 (NOR_BOOTn) = ON (logic-0) Active-low
+ * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
+ * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
+ */
The only requirement for NOR_BOOTn is SW5.2 = ON and SW5.1 (NAND_BOOTn) = OFF.
As mentioned above, please check board schematics
IIRC, GPMC lines pass through various levels of on-board
bi-directional multiplexers,
And 'select' lines of these multiplexers are controlled indirectly via
these xxx_BOOTn switches.
[...]
i2c1 {
@@ -417,8 +477,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nand_flash_x16;
- ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ ranges = 0 0 0x0800 0x0400; /* address offset=128MB,
range=512Mb=64MB */
nand@0,0 {
+ status = okay;
Not needed. If it is not explicitly disabled it is always enabled by default.
Yes, but good to have clarity in DTS, as most users will just copy-paste TI-EVM
DTS and then tweak it for their own custom board DTS. So better to have this
mentioned explicitely.
with regards, pekon
--
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] clk: ti: clk-7xx: Correct ABE DPLL configuration
Quoting Tero Kristo (2014-07-30 05:27:07) On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? I've picked it manually and applied on top of 3.16-rc7 for a last minute fix. I can add your Ack if you like. Regards, Mike -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
Re: OMAP3/AM3517 EHCI USB Issue
On Wed, Jul 30, 2014 at 1:59 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
-- Re: Very Urgent............
Greetings from gulf region Thanks for the e-mail. I am very interested on funding lucrative business partnership with you acting as the manager and sole controller of the investment while i remain a silent investor for a period of ten yrs , though I am only looking at investment opportunities within the range you specified for a start. You can reply me here (fmoris...@yahoo.com) Let me know your thought asap Regards Financial Consultant Mr.Fabian Morision -- 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
