From patchwork Fri Aug 3 09:27:19 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Santosh Shilimkar X-Patchwork-Id: 1270091 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 E96D03FCFC for ; Fri, 3 Aug 2012 09:27:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753144Ab2HCJ1m (ORCPT ); Fri, 3 Aug 2012 05:27:42 -0400 Received: from na3sys009aog105.obsmtp.com ([74.125.149.75]:59480 "EHLO na3sys009aog105.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753110Ab2HCJ1l (ORCPT ); Fri, 3 Aug 2012 05:27:41 -0400 Received: from mail-yx0-f170.google.com ([209.85.213.170]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUBuZjP+d8xLhXR6pbLaDd2tvKnFFTBuq@postini.com; Fri, 03 Aug 2012 02:27:40 PDT Received: by yenl12 with SMTP id l12so645952yen.29 for ; Fri, 03 Aug 2012 02:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=j0zpWMcN90Ekj2tMylvPPwqzKk19fgStQ5cJ7N2jesM=; b=YVGDkJu/v8qvWGjoFWAzp0gS0SzS/uiyhYiEf0EewkaKdJzcS4luaPBaC53LgObtN5 ra5t39gmkfk0tN8WLIQwwU2TP2peELB16gtFaw3ScL9JVCSkeNNlS3DpwZ3CQ5zwwGX1 vE583PWUA3UouENxy19HRJ7H54zdB1V/Iye7ZwQTzHxBk4t4DBFpjtRPIWqreqh4hXhh 9c5GaCtJlfstNWBzVZ0m5VpVwAD8BPi13gXLezqTDqMdJI3ASgD+vGisbY2hC6phLEOA 3ntsfILMMsqgdkLGD6cj0p4NtEGwqmbHCl9+Ivc2ezctQ/K9m74U10mFi13lqBMZPyHv 3kYQ== Received: by 10.50.100.129 with SMTP id ey1mr2161642igb.35.1343986059395; Fri, 03 Aug 2012 02:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.65.85 with HTTP; Fri, 3 Aug 2012 02:27:19 -0700 (PDT) In-Reply-To: References: <1333114048-26136-1-git-send-email-santosh.shilimkar@ti.com> <1333114048-26136-2-git-send-email-santosh.shilimkar@ti.com> <501B7AE6.8080405@gmail.com> <76308EBE-F802-411A-973A-7BBC7575FE5A@dominion.thruhere.net> From: "Shilimkar, Santosh" Date: Fri, 3 Aug 2012 14:57:19 +0530 Message-ID: Subject: Re: [PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus To: Koen Kooi Cc: Daniel Mack , linux-omap@vger.kernel.org, khilman@ti.com, linux-arm-kernel@lists.infradead.org, ccross@android.com, Paul Walmsley , "Hiremath, Vaibhav" X-Gm-Message-State: ALoCoQlKmmbAs68uH8xwnjPuUJ7thQnMEOVh3CTP5ZIRNcrDYhi12sfi7L+gm4bPWUbbM1KLXoIR Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Fri, Aug 3, 2012 at 2:00 PM, Koen Kooi wrote: > > Op 3 aug. 2012, om 09:21 heeft Koen Kooi het volgende geschreven: > >> >> Op 3 aug. 2012, om 09:16 heeft Daniel Mack het volgende geschreven: >> >>> On 30.03.2012 15:27, Santosh Shilimkar wrote: >>>> For coupled cpuidle to work when both cpus are active, it needs a global timer >>>> that can handle events for both cpus. This timer is used as the broadcast >>>> clock-event when the per-cpu timer hardware stop in low power states. >>>> Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and >>>> set the irq to allow the clockevent core to determine the affinity of the >>>> timer. >>> >>> These patches made it to mainline now, shortly befor 3.6-rc1, and it >>> breaks boot on my AM33xx board. >>> >>> Once I revert 1/3, the board boots again but crashes with the Ooops >>> below. With the entire series reverted, everything works again as >>> expected. Any idea? >>> >>> The upstream commit ids are >>> >>> 11d6ec2e "ARM: OMAP: timer: allow gp timer clock-event to be used on >>> both cpus" >>> 5b4d5bcc "ARM: OMAP4: CPUidle: add synchronization for coupled idle states" >>> b93d70ae "ARM: OMAP4: CPUidle: Open broadcast clock-event device." >> >> I've had boot problems with cpuidle enabled as well, what happens if you disable it? Is the revert still needed in that case? > > To answer my own question: No, the reverts aren't needed if you disable cpuidle. This is really strange since CPUIDLE code is really OMAP4 specific. obj-$(CONFIG_ARCH_OMAP4) += cpuidle44xx.o May be omap2plus build some how the code gets executed on AMXX Can you try below and see if the boot with CPUIDLE enabled goes away on AMXX Regards Ssantosh --- 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/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index ea24174..195e756 100644 --- a/arch/arm/mach-omap2/pm44xx.c +++ b/arch/arm/mach-omap2/pm44xx.c @@ -147,6 +147,9 @@ int __init omap4_pm_init(void) struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup; struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm; + if (!cpu_is_omap44xx()) + return -ENODEV; + if (omap_rev() == OMAP4430_REV_ES1_0) { WARN(1, "Power Management not supported on OMAP4430 ES1.0\n"); return -ENODEV;