Hello Jouni, On Wed, 15 Oct 2008, Högander Jouni wrote: > "ext Tony Lindgren" <tony@xxxxxxxxxxx> writes: > > > * Igor Stoppa <igor.stoppa@xxxxxxxxx> [081014 14:12]: > >> On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: > >> > >> > And that we can use same naming in the driver no matter which omap :) > >> > >> Wasn't that one of the main features of the clock FW, when it was > >> designed? > > > > Yes. But we adding separate ick and fck during omap2420 confused > > that. > > Why this was originally done? I mean we have possibility to autogate > interface clocks. AFAIK those could be just fine be enabled on boot and let > the hw to take care of them. Richard is really the best person to ask about this, so he's been added to the cc. My current understanding is below. Perhaps he can respond with more detail and correct any errors. In terms of original motivation, you might want to look at 34xx TRM 4.12.2.4.3. I don't think this actually works in practice on OMAP3. Current practical use is different. Autogating only takes effect during sleep & wakeup transitions for the entire CORE_Lx clockdomain (34xx TRM 4.12.2.4.4). So even if a module's functional clocks are disabled, the PRCM won't autogate the module's interface clock until the entire CORE_Lx clockdomain transitions to inactive. The theory here is that this wastes power and that manually disabling the interface clock when the device is known to be inactive should save some power. There also was some discussion last year that modules like GPTIMER can have their functional clocks enabled, but their interface clocks disabled when register access is not needed. Wakeups from the module are still sent asynchronously to the PRCM. Again the motivation is to save power. I don't think the current code tries to do this. - Paul
