On Tue, 10 Feb 2015, Felipe Balbi wrote: > 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. Ok sounds like the thing to do is to wait until you hear back from them, if they are still looking at it. - Paul -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
