From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cousson, Benoit" Subject: Re: [PATCH v3 02/11] OMAP3: PM: Adding voltage driver support for OMAP3 Date: Fri, 15 Oct 2010 15:47:32 +0200 Message-ID: <4CB85B74.7020907@ti.com> References: <1285166719-19352-1-git-send-email-thara@ti.com> <1285166719-19352-3-git-send-email-thara@ti.com> <87bp7gm3dq.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from arroyo.ext.ti.com ([192.94.94.40]:49887 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755947Ab0JONrg (ORCPT ); Fri, 15 Oct 2010 09:47:36 -0400 In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Paul Walmsley Cc: "Gopinath, Thara" , Kevin Hilman , "linux-omap@vger.kernel.org" , "Sripathy, Vishwanath" , "Sawant, Anand" Hi Paul, On 9/30/2010 7:39 PM, Paul Walmsley wrote: > Hi Beno=EEt, Thara, > > On Wed, 29 Sep 2010, Kevin Hilman wrote: > >> Also, I'm still seeing this on boot: >> >> omap_hwmod: sr1_fck: missing clockdomain for sr1_fck. >> omap_hwmod: sr2_fck: missing clockdomain for sr2_fck. >> >> We need a final solution for this problem as a prerequisite for this >> series as well. > > I guess we need to figure out the appropriate clockdomains for sr1_fc= k and > sr2_fck. > > Probably the strictly correct thing to do, vis-a-vis the hardware, is= to > place them into their own SmartReflex clockdomain/powerdomain. But t= he > PRCM doesn't export separate control registers for those, and as I > understand it, that clockdomain/powerdomain follows the CORE > clockdomains/powerdomain. More or less. In theory the smartreflex power domain goes to OFF only=20 when the device goes to OFF. In device RET the SR power domain is still= =20 active. That's why the FCLK is marked as always ON. > Another option would be to place them into the WKUP clockdomain. The > source of these functional clocks in SR_ALWON_FCLK which in turn is > generated by the PRM from SYS_CLK. But that won't increment the CORE > clockdomains' use-counter when the SR functional clocks are running, = which > seems desirable if the SmartReflex clockdomain/powerdomain really doe= s > follow CORE. > > So it seems to me that the best thing to do might be to place these c= locks > into the CORE_L4 clockdomain. But perhaps you might have a different > view? That's should be the proper place, but after several discussion with=20 Vincent then Leo, it appears that the gating of the CORE_L4 interface=20 clock is triggered by a transition of the WKUP clock domain to idle... Yeah, that's a mess... that IP does not follow any PRCM standard :-) Originally I thought the SR_EN bits were located in the wkup register=20 because Vincent was too lazy to create a new register for these 2 bits = :-). But in fact because of that hidden dependency with the wkup, it is=20 almost normal to put these bits there. Bottom-line is that we should tie them to the "wkup_clkdm". Another important point we already discussed a little bit, but that wil= l=20 require more thoughts, is that the clock domain definition is first:=20 quite fuzzy and then does not belong do the clock itself, but to the=20 modules that are sharing the same interface clock. It means that some clocks will not belong to any clock domains, and thi= s=20 is fine. On OMAP4, that definition is clearly tied to the modules, and thus=20 should be an hwmod attribute more than a clock node attribute. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html