From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cousson, Benoit" Subject: Re: [PATCH v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process Date: Thu, 19 Apr 2012 14:05:56 +0200 Message-ID: <4F8FFFA4.7050607@ti.com> References: <20120228053524.16278.59430.stgit@dusk> <20120228053651.16278.22844.stgit@dusk> <4F8FCB4A.3080805@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:53779 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753809Ab2DSMGB (ORCPT ); Thu, 19 Apr 2012 08:06:01 -0400 In-Reply-To: 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 On 4/19/2012 11:49 AM, Paul Walmsley wrote: > Hi Beno=EEt, > > On Thu, 19 Apr 2012, Cousson, Benoit wrote: > >> On 4/19/2012 10:17 AM, Paul Walmsley wrote: >> >>> static int __init omap_hwmod_setup_all(void) >>> { >>> - int r; >>> - >>> - if (!mpu_oh) { >>> - pr_err("omap_hwmod: %s: MPU initiator hwmod %s not yet >>> registered\n", >>> - __func__, MPU_INITIATOR_NAME); >>> - return -EINVAL; >>> - } >>> - >>> - r =3D omap_hwmod_for_each(_populate_mpu_rt_base, NULL); >>> - >>> - r =3D omap_hwmod_for_each(_init_clocks, NULL); >>> - WARN(IS_ERR_VALUE(r), >>> - "omap_hwmod: %s: _init_clocks failed\n", __func__); >>> + _ensure_mpu_hwmod_is_setup(NULL); >>> >>> + omap_hwmod_for_each(_init, NULL); >>> omap_hwmod_for_each(_setup, NULL); >> >> Does it make sense to iterate twice? Cannot we just iterate over a _= init + >> _setup single call? > > It's a good idea but I don't think we can do that until we add the co= de to > walk the hwmod data in dependency order. The DSS custom reset functi= on > accesses registers in another hwmod, which won't have its clocks > initialized yet if _init() and setup() are combined. Outch, that's unfortunate! I'm wondering if the whole automatic reset management at hwmod level=20 does make sense for such IP. In the case of the DSS, having some reset support in the driver model=20 should allow potentially a reset done at parent level to be broadcasted= =20 to every children. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: b-cousson@ti.com (Cousson, Benoit) Date: Thu, 19 Apr 2012 14:05:56 +0200 Subject: [PATCH v2 3/8] ARM: OMAP2+: hwmod: reorganize and document the setup process In-Reply-To: References: <20120228053524.16278.59430.stgit@dusk> <20120228053651.16278.22844.stgit@dusk> <4F8FCB4A.3080805@ti.com> Message-ID: <4F8FFFA4.7050607@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 4/19/2012 11:49 AM, Paul Walmsley wrote: > Hi Beno?t, > > On Thu, 19 Apr 2012, Cousson, Benoit wrote: > >> On 4/19/2012 10:17 AM, Paul Walmsley wrote: >> >>> static int __init omap_hwmod_setup_all(void) >>> { >>> - int r; >>> - >>> - if (!mpu_oh) { >>> - pr_err("omap_hwmod: %s: MPU initiator hwmod %s not yet >>> registered\n", >>> - __func__, MPU_INITIATOR_NAME); >>> - return -EINVAL; >>> - } >>> - >>> - r = omap_hwmod_for_each(_populate_mpu_rt_base, NULL); >>> - >>> - r = omap_hwmod_for_each(_init_clocks, NULL); >>> - WARN(IS_ERR_VALUE(r), >>> - "omap_hwmod: %s: _init_clocks failed\n", __func__); >>> + _ensure_mpu_hwmod_is_setup(NULL); >>> >>> + omap_hwmod_for_each(_init, NULL); >>> omap_hwmod_for_each(_setup, NULL); >> >> Does it make sense to iterate twice? Cannot we just iterate over a _init + >> _setup single call? > > It's a good idea but I don't think we can do that until we add the code to > walk the hwmod data in dependency order. The DSS custom reset function > accesses registers in another hwmod, which won't have its clocks > initialized yet if _init() and setup() are combined. Outch, that's unfortunate! I'm wondering if the whole automatic reset management at hwmod level does make sense for such IP. In the case of the DSS, having some reset support in the driver model should allow potentially a reset done at parent level to be broadcasted to every children. Regards, Benoit