Re: [PATCH 1/3] clk: introduce omap_clk_associate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"ext Paul Walmsley" <paul@xxxxxxxxx> writes:

> 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.

L3 and L4 are anyway on when not in wfi, because of sleep/wkdep, so no
power save. This is the case at least with OMAP3 not sure about OMAP2.

>
> 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.
>

In many modules there is also possibility to gate ick by HW when not
in wfi (see AUTOIDLE in SYCONFIG). I'm not sure about this but
extremely also fcks could be taken care by HW (see CLOCKACTIVITY in
SYSCONFIG).

>
> - Paul

-- 
Jouni Högander

--
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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux