On 05/04/2016 08:59 AM, Ryan wrote: > Hi Nishanth, > > On Wed, May 4, 2016 at 6:54 PM, Nishanth Menon <nm@xxxxxx> wrote: >> On 05/04/2016 06:20 AM, Ryan wrote: >>> Hello, >>> >>> I am still seeing core domain to be ON on a 4460 board. The following >>> is the prcm debug output. >>> >>> I am not sure whats keeping the core domain to be ON. I compared with >>> a system on which core has hit retention. But could not find anything >>> different other than some are IDLE vs Disabled. >>> >>> Can anyone help me on this please? >> >> Does not look like upstream kernel for sure.. and the kernel patch >> which optimized the log does not seem merged (3.4ish I think).. >> PD_CORE curr=ON prev=ON logic=ON >> >> On a quick glance, All the sub PDs look to be at least in retention - >> which is the entry criteria for OFF mode on O4. >> >> There are many reasons that prevent this, the best debug I have >> personally done is with h/w observability signals. Typically, there'd >> be a pending interrupt etc that prevent from going to off mode. One >> other time I have hit MR4 event from EMIF for PoP memory generating >> EMIF temp event another was a bad AVS irq disable (pending interrupt >> again)... other times I had seen clk_out active, so off entry gets >> started, but stops short of osc stop prior to off entry, and OFF is >> not triggered by PRCM. >> >> There should be a timing diagram in TRM for off mode sequence. if >> voltages never transitioned, then it is probably way ahead of DEV_OFF >> entry condition in PRCM state machine.. JTAG and h/w observability >> will be your best bet. >> > > Been trying to achieve retention state. Are there any more prcm registers > which might help assist in debugging? PRCM regs wont tell you much more, it is matching the statemachine state as entry into dev_off (which I think you are matching), to the state when PRCM triggers the off voltage commands.. things are backing off somewhere in that path.. as I said, once you have h/w observability, then you can kind of know around what steps failed, then try to look at registers related to that.. For example if there is EMIF MR4 event pending it is an internal signal to GIC via core pd, GIC is off (obviously), so you cant read the signal-even if GIC enable is not set and obviously not set up via wakeup gen to wake things up.. clkout had some weird control module bits (from a 4 odd year old memory).. I dont recollect exactly which one.. but there were quiet some hurdles to cross before the oscillator switched off and off voltage command is send over i2c to PMIC - i think VC/VP configuration needs to be right as well.. sorry, been so long that I dont remember all the details now... > >> it is a pretty hard state to achieve, once achieved, even more harder >> to recover from - when I used to work in product kernels, we had >> significant burden in getting this to work due to the complex >> interactions involved. >> >> I doubt folks in the list will be able to debug based on basic log.. >> If you do not have a TI support person already involved, I suggest >> using e2e.ti.com for further discussion >> > > e2e is closed for omap4 discussions. Sorry, I did not realize that. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
