From patchwork Fri Aug 3 06:26:24 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vaibhav Hiremath X-Patchwork-Id: 1268611 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 D3BFD3FC33 for ; Fri, 3 Aug 2012 06:29:58 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SxBLO-0007Ga-0Z; Fri, 03 Aug 2012 06:26:42 +0000 Received: from arroyo.ext.ti.com ([192.94.94.40]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1SxBLL-0007GM-2m for linux-arm-kernel@lists.infradead.org; Fri, 03 Aug 2012 06:26:39 +0000 Received: from dbdp20.itg.ti.com ([172.24.170.38]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id q736QThb025808; Fri, 3 Aug 2012 01:26:29 -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 q736QQBo004848; Fri, 3 Aug 2012 11:56:27 +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; Fri, 3 Aug 2012 11:56:26 +0530 From: "Hiremath, Vaibhav" To: Russell King - ARM Linux Subject: RE: omap_device: query on "fck" clk alias created Thread-Topic: omap_device: query on "fck" clk alias created Thread-Index: Ac1v4AUnepZ721UYSNaR6+i8glukLP//w50A//4ugbCAA1KsAP//fgng Date: Fri, 3 Aug 2012 06:26:24 +0000 Message-ID: <79CD15C6BA57404B839C016229A409A83EA7F0F2@DBDE01.ent.ti.com> References: <50191F00.1040501@ti.com> <20120801141414.GM7405@n2100.arm.linux.org.uk> <79CD15C6BA57404B839C016229A409A83EA7DF5C@DBDE01.ent.ti.com> <20120802131250.GO7405@n2100.arm.linux.org.uk> In-Reply-To: <20120802131250.GO7405@n2100.arm.linux.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.170.142] 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.40 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" , Paul Walmsley , "Cousson, Benoit" , Tony Lindgren , "Nayak, Rajendra" , "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 Thu, Aug 02, 2012 at 18:42:50, Russell King - ARM Linux wrote: > On Thu, Aug 02, 2012 at 01:04:37PM +0000, Hiremath, Vaibhav wrote: > > On Wed, Aug 01, 2012 at 19:44:14, Russell King - ARM Linux wrote: > > > On Wed, Aug 01, 2012 at 05:50:16PM +0530, Vaibhav Hiremath wrote: > > > > The clk_get() api will not work, unless we pass both the arguments (dev, > > > > con_id) properly. Now expecting driver to always label con_id with "fck" > > > > is undesirable, as the same driver can be reused on multiple platforms, > > > > which can be non-omap and/or non-ti platforms. > > > > > > Why not? > > > > > > The connection ID is defined by the driver, and the platform stuff is > > > expected to provide drivers with what they require. It's not the other > > > way around (platforms don't tell drivers what they require.) > > > > > > In other words, if the device has two clocks, one called ick and one called > > > fck, then the device _should_ use clk_get() specifying "ick" for one, and > > > "fck" for the other. > > > > > > And platforms better provide an "ick" and a "fck" for the device, even if > > > they have no respresentation for one or other of them (in which case you > > > supply a dummy clock.) > > > > > > > Russell, I completely agree with you, infact I am on the same page. > > Let me give you a real example, which I am dealing with now, > > > > On AM335x device we have integrated DCAN, this IP is not from TI. > > IP is from Bosch and doesn't follow any of the TI IP standards, like > > HighLander spec. The IP is just integrated with interconnect bus and given a > > required clocksource (in this case its one clock). > > > > The driver for this IP is generic, (drivers/net/can/c_can/c_can_platform.c) > > obviously used across non-ti devices already and driver is implemented with, > > clk_get(dev, NULL); > > So, elsewhere it only has one clock. Are there any other clocks it needs > on OMAP? > > If the answer is no, then the driver is doing the right thing, and OMAP's > clk stuff needs to be adjusted to suit the drivers requirements. > > I've said many times over the years that clock connection IDs are defined > by the device or driver and *nothing* else - they're certainly *not* source > names. > > That's why, when I modified OMAP drivers to fix them, and they take an > interface and function clock, they end up asking for "ick" and "fck" not > "blah_ick" and "blah_fck". > I am in agreement with you and I believe I came to the solution for this issue, I used "of_dev_auxdata" to manipulate dev_id and updated clock-tree table with required clock entry and it works, I tried it on BeagleBone platform. Can you please review it? diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 6f93a20..893cc0c 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -37,11 +37,24 @@ static struct of_device_id omap_dt_match_table[] __initdata = { { } }; +/* + * Lookup table for attaching a specific name and platform_data pointer to + * devices as they get created by of_platform_populate(). Ideally this table + * would not exist, but the current clock implementation depends on some devices + * having a specific name. + */ +static const struct of_dev_auxdata omap_auxdata_lookup[] __initconst = { + OF_DEV_AUXDATA("bosch,d_can", 0x481cc000, "d_can.0", NULL), + OF_DEV_AUXDATA("bosch,d_can", 0x481d0000, "d_can.1", NULL), + { }, +}; + + static void __init omap_generic_init(void) { omap_sdrc_init(NULL, NULL); - of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); + of_platform_populate(NULL, omap_dt_match_table, omap_auxdata_lookup, NULL); } #ifdef CONFIG_SOC_OMAP2420 diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c index ae27de8..f061834 100644 --- a/arch/arm/mach-omap2/clock33xx_data.c +++ b/arch/arm/mach-omap2/clock33xx_data.c @@ -1028,6 +1028,8 @@ static struct omap_clk am33xx_clks[] = { CLK(NULL, "clkdiv32k_ick", &clkdiv32k_ick, CK_AM33XX), CLK(NULL, "dcan0_fck", &dcan0_fck, CK_AM33XX), CLK(NULL, "dcan1_fck", &dcan1_fck, CK_AM33XX), + CLK("d_can.0", NULL, &dcan0_fck, CK_AM33XX), + CLK("d_can.1", NULL, &dcan1_fck, CK_AM33XX), CLK(NULL, "debugss_ick", &debugss_ick, CK_AM33XX), CLK(NULL, "pruss_ocp_gclk", &pruss_ocp_gclk, CK_AM33XX), CLK("davinci-mcasp.0", NULL, &mcasp0_fck, CK_AM33XX),