From patchwork Wed Aug 15 09:10:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vaibhav Hiremath X-Patchwork-Id: 1324811 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork1.kernel.org (Postfix) with ESMTP id 2E62A3FC66 for ; Wed, 15 Aug 2012 09:13:52 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1T1Zd7-0007SJ-Sz; Wed, 15 Aug 2012 09:11:09 +0000 Received: from bear.ext.ti.com ([192.94.94.41]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1T1Zd3-0007Qn-Kr for linux-arm-kernel@lists.infradead.org; Wed, 15 Aug 2012 09:11:06 +0000 Received: from dbdp20.itg.ti.com ([172.24.170.38]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id q7F9B1H9028530; Wed, 15 Aug 2012 04:11:02 -0500 Received: from DBDE70.ent.ti.com (localhost [127.0.0.1]) by dbdp20.itg.ti.com (8.13.8/8.13.8) with ESMTP id q7F9AxKM029858; Wed, 15 Aug 2012 14:41:00 +0530 (IST) Received: from DBDE01.ent.ti.com ([fe80::d5df:c4b5:9919:4e10]) by DBDE70.ent.ti.com ([fe80::2141:513f:409:315a%21]) with mapi id 14.01.0323.003; Wed, 15 Aug 2012 14:40:59 +0530 From: "Hiremath, Vaibhav" To: Tony Lindgren , Paul Walmsley Subject: RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data Thread-Topic: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data Thread-Index: AQHNalWs0vwJjVxenUi7aLiJ4FH46pc6GtAAgAGHgYCAHRqTAIABxI9g Date: Wed, 15 Aug 2012 09:10:57 +0000 Message-ID: <79CD15C6BA57404B839C016229A409A83EA8F4CD@DBDE01.ent.ti.com> References: <1343214422-28718-1-git-send-email-hvaibhav@ti.com> <20120814082911.GG11011@atomide.com> In-Reply-To: <20120814082911.GG11011@atomide.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.133.105] MIME-Version: 1.0 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [192.94.94.41 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "Hilman, Kevin" , "Mohammed, Afzal" , "Cousson, Benoit" , "Nayak, Rajendra" , "Bedia, Vaibhav" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote: > Hi, > > * Paul Walmsley [120726 13:07]: > > On Wed, 25 Jul 2012, Paul Walmsley wrote: > > > > > These IP blocks and the ECAP IP blocks have periods in their names. > > > The rest of the IP block named in the file don't use periods -- which > > > is also the style used by the rest of the OMAP SoCs. Is there > > > some reason that these have periods in their names? > > > > I've changed those to match the rest of the names, and queued the > > following for 3.7. > > > > Thanks again for all the hard work you all put into this. I realize that > > with all the upstream changes, this was probably a little painful for you. > > But from my perspective you've been a pleasure to work with through the > > process. > > As am33xx and omap5 are DT only, we should start moving towards getting > rid of grep -E "irq|pa_start|pa_end|dma" in this patch and get the standard > data from .dtsi files instead. > It may not be so straight, given the fact that hwmod layer requires these resources, as hwmod is responsible to configure SYSCONF register of the device (happens very early at core_init level). Somehow we have to have some mechanism to initialize " _mpu_rt_va" before core_init call, which will take DT resources and initialize accordingly. Another dependency we will have is on system timers, Jon has already done some initial work on this, but I believe we did not concluded on the it. I will re-start the thread again, since in any case DT support in timer is required. > Alternatively we could get rid of the names and match the module based on > pa_start and pa_end. > Just FYI, from resource perspective, I have changed omap_device layer for DT resources only (still need hwmod resources as explained above) and patch looks something like (and it works) - Thanks, Vaibhav diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index c490240..cb481fe 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -528,10 +528,15 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev, * HACK: Ideally the resources from DT should match, and hwmod * should just add the missing ones. Since the name is not * properly populated by DT, stick to hwmod resources only. + * + * But in case of all new devices, like AM33XX and OMAP5, where + * only DT boot is supported, stick to DT resources only. */ - if (pdev->num_resources && pdev->resource) + if (pdev->num_resources && pdev->resource) { dev_warn(&pdev->dev, "%s(): resources already allocated %d\n", __func__, pdev->num_resources); + goto skip_res_override; + } res_count = omap_device_count_resources(od); if (res_count > 0) { @@ -550,6 +555,7 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev, goto oda_exit3; } +skip_res_override: if (!pm_lats) { pm_lats = omap_default_latency; pm_lats_cnt = ARRAY_SIZE(omap_default_latency);