Hi Santosh, On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote: [...] > > > > A few questions based on the description given in the commit message. > > > >> 1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module, > >> which constantly stays in "in transition" state. Value of register > >> CM_WKUP_WDTIMER2_CLKCTRL is always 0x00010000 in this case. > >> Issue occurs immediately after first idle, when hwmod framework tries > >> to disable WDTIMER2 functional clock - "wd_timer2_fck". After this > >> module falls to "in transition" state, and SYSCLK gating is blocked. > >> > > > > From what I know, a value of 0x00010000 for timers (WDT or DMTIMERs) > > indicates that the iclk is gated but the fclk is running. In fact, > > if the IP supports swakeup mechanism this is the value expected in the > > *_CLKCTRL registers of the timers for the swakeup to work. > > > Nope. That case will be 0x00020000 > > Read 0x1: Module is performing transition: wakeup, or > sleep, or sleep abortion > Read 0x2: Module is in idle mode (only INTRCONN part). > It is functional if using separate functional clock > Read 0x3: Module is disabled and cannot be accessed > What you mentioned is obviously correct :) I somehow recall seeing something else but mostly likely I am wrong here. > > Sounds like on OMAP4 the WDT needs to be stopped first and then the > > PRCM idle request sent otherwise SYSCLK gating will be blocked. > > > Any module stuck in-transition will get the clock-domain from idle. > Yes agreed. > >> 2. Due to runtime PM, watchdog timer may be completely disabled. > >> In current code base watchdog timer is not disabled only because of > >> issue 1. Otherwise state of WDTIMER2 module will be "Disabled", and there > >> will be no interrupts from omap_wdt. In other words watchdog will not > >> work at all. > > > > But the current driver doesn't make use of any interrupts, right? > > > How is the interrupt related. You enable that when you enable WDT > petting using delay_interrupt() > Even I don't understand the interrupt part here. > > If the WDT was never started, runtime PM handling for the WDT should be > > able to get the IP to a "disabled" state. Is the issue over here due > > to the WDT counter incrementing and still the PRCM idle request being > > sent for disabling it? If so, perhaps a better solution would be have > > a custom runtime PM handling for WDT which checks if the counter > > is incrementing or not. If it is not incrementing then it can just > > go ahead and disable the clocks. However, if the counter is incrementing > > then the runtime PM activities on the driver should be forbidden till > > an entry to a low power state where SYSCLK needs to be gated is required. > > > If you look at the test case mentioned, the watchdong is started. Your > first observation is not as per the hardware behavior, so other points > becomes not relevant. > Ok. I'll double-check my observations on AM335x on Monday. Regards, Vaibhav B. -- 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
