> -----Original Message----- > From: Jokiniemi Kalle (Nokia-MS/Tampere) > > -----Original Message----- > > From: ext Cousson, Benoit [mailto:b-cousson@xxxxxx] > > > > In theory, you should not have to disable the interface clock at all. > > Assuming that the smartidle is working properly, the iclk should be > > gated during clock domain transition automagically. > > The only thing that can prevent that is potentially a wrong setting in > > the clockactivity bits? It should be 0x2, meaning fclk is active but iclk can be > gated. > > Just trying that out now :) Nope, did not work. Tried this with both paul's second patch and without: --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -1251,6 +1251,7 @@ static struct omap_hwmod_class_sysconfig omap3xxx_wd_timer_sysc = { SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY), .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .clockact = CLOCKACT_TEST_ICLK, .sysc_fields = &omap_hwmod_sysc_type1, }; I am quite puzzled why it does not just work as it is. The GPTIMER1 is very similar to this (uses same interface clock: wkup_l4_ick) and it has iclk usecount of 1 in the clock tree same as the wdtimer2 iclk. So the clock framework allows the gptimer1 to disable interface clock on idle transition, but not for wdtimer2. HW bug? I wonder what is different with direct iclk control, since the iclk bit is still enabled with this approach as well. Maybe the clock framework does some different tricks in case there are no users for a certain clock... - Kalle > > - Kalle > > > > > Regards, > > Benoit -- 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
