From patchwork Thu Nov 22 05:30:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vaibhav Hiremath X-Patchwork-Id: 1786231 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 57A2E3FC23 for ; Thu, 22 Nov 2012 19:21:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162Ab2KVTVn (ORCPT ); Thu, 22 Nov 2012 14:21:43 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:56334 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965142Ab2KVTSL (ORCPT ); Thu, 22 Nov 2012 14:18:11 -0500 Received: from dbdp20.itg.ti.com ([172.24.170.38]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id qAM5UGDV024144; Wed, 21 Nov 2012 23:30:17 -0600 Received: from DBDE71.ent.ti.com (localhost [127.0.0.1]) by dbdp20.itg.ti.com (8.13.8/8.13.8) with ESMTP id qAM5UDcn021525; Thu, 22 Nov 2012 11:00:14 +0530 (IST) Received: from dbdp32.itg.ti.com (172.24.170.251) by DBDE71.ent.ti.com (172.24.170.149) with Microsoft SMTP Server id 14.1.323.3; Thu, 22 Nov 2012 11:00:13 +0530 Received: from [172.24.133.105] (smtpvbd.itg.ti.com [172.24.170.250]) by dbdp32.itg.ti.com (8.13.8/8.13.8) with ESMTP id qAM5U8kv020200; Thu, 22 Nov 2012 11:00:08 +0530 Message-ID: <50ADB860.2090707@ti.com> Date: Thu, 22 Nov 2012 11:00:08 +0530 From: Vaibhav Hiremath User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Jon Hunter CC: Joel A Fernandes , Joel A Fernandes , , Russ Dill , Matt Porter , Steve Kipisz , Jason Kridner , Tony Lindgren , Paul Walmsley Subject: Re: [PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot References: <1353109482-26478-1-git-send-email-joelagnel@ti.com> <50A6D672.1020104@ti.com> <50AA5B14.6010909@ti.com> In-Reply-To: <50AA5B14.6010909@ti.com> Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On 11/19/2012 9:45 PM, Jon Hunter wrote: > > On 11/16/2012 08:44 PM, Joel A Fernandes wrote: >> Hi Jon, >> >> On Fri, Nov 16, 2012 at 6:12 PM, Jon Hunter wrote: >>>> diff --git a/arch/arm/mach-omap2/clock33xx_data.c >>>> b/arch/arm/mach-omap2/clock33xx_data.c >>>> index b7b7995..d0b4313 100644 >>>> --- a/arch/arm/mach-omap2/clock33xx_data.c >>>> +++ b/arch/arm/mach-omap2/clock33xx_data.c >>>> @@ -585,6 +585,7 @@ static struct clk debugss_ick = { >>>> .clkdm_name = "l3_aon_clkdm", >>>> .parent = &dpll_core_m4_ck, >>>> .ops = &clkops_omap2_dflt, >>>> + .flags = ENABLE_ON_INIT, >>>> .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, >>>> .enable_bit = AM33XX_MODULEMODE_SWCTRL, >>>> .recalc = &followparent_recalc, >>> >>> Does this mean this clock will always be enabled, even when not using >>> JTAG? If so, is that what you want? >> >> Yes, the clock will always be on, because some times we connect JTAG >> on a running Linux system without powering it down. I can't comment >> without doing measurements if keeping the clock on has significant >> impact on power, but I see what you mean. Definitely low power is a >> parameter and folks who want lowest possible power might need to turn >> off the clock and not have JTAG in production, but that depends on the >> user's requirement. I personally don't care about power as much as I >> care about not being able to JTAG, and I think there are other folks >> who suffer from the same JTAG problem who wouldn't necessarily want >> lowest power. > > I can't say I am that familiar with the AM33xx architecture, but I know > that on OMAP this would keep on the debugss clock and power domain. > > Do you need this change to connect JTAG after the kernel has booted or > just to maintain JTAG during kernel boot? > > I am wondering if you should implement a new flag such as > "DONT_DISABLE_ON_INIT" so if the clock is on it is not disabled, but if > it is not enabled, you don't enabled it. Then that would be the best of > both worlds. > Joel, The it should be handled is, on kernel_debug option we should keep it enabled and default it should be disabled. Something similar to, Can you please test above change?? Thanks, Vaibhav >>> I was not sure if you are concerned about power at all. Or if having >>> that always enabled can inhibit low power states for suspend/idle etc. >> >> Maybe, suspend/resume code can turn off clock on suspend and enable it >> on resume. > > Yes, but not ideal for a product assuming they are power sensitive. > > Cheers > Jon > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c index 17e3de5..60e0b53 100644 --- a/arch/arm/mach-omap2/clock33xx_data.c +++ b/arch/arm/mach-omap2/clock33xx_data.c @@ -584,6 +584,9 @@ static struct clk debugss_ick = { .clkdm_name = "l3_aon_clkdm", .parent = &dpll_core_m4_ck, .ops = &clkops_omap2_dflt, +#ifdef CONFIG_DEBUG_KERNEL + .flags = ENABLE_ON_INIT, +#endif .enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, .enable_bit = AM33XX_MODULEMODE_SWCTRL, .recalc = &followparent_recalc,