Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
From: Paul Walmsley <hidden>
Date: 2015-01-27 17:55:44
Also in:
linux-arm-kernel, linux-omap
On Tue, 27 Jan 2015, Felipe Balbi wrote:
On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote:quoted
On Tue, Jan 27, 2015 at 05:12:05PM +0000, Paul Walmsley wrote:quoted
On Tue, 27 Jan 2015, Felipe Balbi wrote:quoted
On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote:quoted
On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote:quoted
hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ?gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special.If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing?I'll try it out in a bit...nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed
OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). - Paul -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html