Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

Hi,

On Tue, Feb 10, 2015 at 11:12:40PM +0000, Paul Walmsley wrote:
> > > > > > > > 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 2
> > > > > > 
> > > > > > just 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).
> 
> Just checking on this.  Heard anything from the hardware team?  If not I'd 
> say the HWMOD_CANNOT_DISABLE approach is probably the right one for now...

nothing from HW team yet. Last I heard is that they can reproduce the
issue, and are now digging through documentation (and maybe RTL, but I'm
speculating) to see if that should be supported or not.

From my point of view, however, the thing idles, it just doesn't report
it.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]