From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cousson, Benoit" Subject: Re: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks Date: Mon, 11 Jun 2012 18:28:04 +0200 Message-ID: <4FD61C94.4030004@ti.com> References: <20120611004502.20034.8840.stgit@dusk> <20120611004623.20034.52760.stgit@dusk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:39041 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754006Ab2FKQ2K (ORCPT ); Mon, 11 Jun 2012 12:28:10 -0400 In-Reply-To: <20120611004623.20034.52760.stgit@dusk> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Paul Walmsley Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Rajendra Nayak Hi Paul, On 6/11/2012 2:46 AM, Paul Walmsley wrote: > Until the OMAP4 code is converted to disable the use of the clock > framework-based clockdomain enable/disable sequence, any clock used a= s > a hwmod main_clk must have a clockdomain associated with it. But why? The clock domain information is already present in every hwmod= =20 nodes for OMAP4. > This > patch populates some clock structure clockdomain names to resolve the > following warnings during kernel init: > > omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. > omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_c= k. > omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck. > omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck. > > Signed-off-by: Paul Walmsley > Cc: Rajendra Nayak > Cc: Beno=C3=AEt Cousson > --- > arch/arm/mach-omap2/clock44xx_data.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-oma= p2/clock44xx_data.c > index 2172f66..e2b701e 100644 > --- a/arch/arm/mach-omap2/clock44xx_data.c > +++ b/arch/arm/mach-omap2/clock44xx_data.c > @@ -84,6 +84,7 @@ static struct clk slimbus_clk =3D { > > static struct clk sys_32k_ck =3D { > .name =3D "sys_32k_ck", > + .clkdm_name =3D "prm_clkdm", In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4= :-(. I've just realized that you introduced that for 3.5, but this is wrong.= =20 We should not start adding some fake clock domains just because the fmw= k=20 is not smart enough to allow a NULL clock domain. The clkdomain should be optional, at least for clock nodes. There is no need to enforce the presence of the clock domain in the=20 structure. We should remove the warning and test the clkdm attribute=20 before de-referencing it inside the clock core code. This is the only proper fix for that issue for my point of view. In a period of data size reduction, adding some fake information does=20 not seems to be the right approach. Don't you think so? Regards, Benoit PS: I think we should revert 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c=20 (ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common) and fix the=20 OMAP4 hwmod data. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: b-cousson@ti.com (Cousson, Benoit) Date: Mon, 11 Jun 2012 18:28:04 +0200 Subject: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks In-Reply-To: <20120611004623.20034.52760.stgit@dusk> References: <20120611004502.20034.8840.stgit@dusk> <20120611004623.20034.52760.stgit@dusk> Message-ID: <4FD61C94.4030004@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Paul, On 6/11/2012 2:46 AM, Paul Walmsley wrote: > Until the OMAP4 code is converted to disable the use of the clock > framework-based clockdomain enable/disable sequence, any clock used as > a hwmod main_clk must have a clockdomain associated with it. But why? The clock domain information is already present in every hwmod nodes for OMAP4. > This > patch populates some clock structure clockdomain names to resolve the > following warnings during kernel init: > > omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. > omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck. > omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck. > omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck. > > Signed-off-by: Paul Walmsley > Cc: Rajendra Nayak > Cc: Beno?t Cousson > --- > arch/arm/mach-omap2/clock44xx_data.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c > index 2172f66..e2b701e 100644 > --- a/arch/arm/mach-omap2/clock44xx_data.c > +++ b/arch/arm/mach-omap2/clock44xx_data.c > @@ -84,6 +84,7 @@ static struct clk slimbus_clk = { > > static struct clk sys_32k_ck = { > .name = "sys_32k_ck", > + .clkdm_name = "prm_clkdm", In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 :-(. I've just realized that you introduced that for 3.5, but this is wrong. We should not start adding some fake clock domains just because the fmwk is not smart enough to allow a NULL clock domain. The clkdomain should be optional, at least for clock nodes. There is no need to enforce the presence of the clock domain in the structure. We should remove the warning and test the clkdm attribute before de-referencing it inside the clock core code. This is the only proper fix for that issue for my point of view. In a period of data size reduction, adding some fake information does not seems to be the right approach. Don't you think so? Regards, Benoit PS: I think we should revert 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c (ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common) and fix the OMAP4 hwmod data.