From patchwork Sat Jan 31 01:08:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 5753751 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 0D6309F302 for ; Sat, 31 Jan 2015 01:08:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D367E202A1 for ; Sat, 31 Jan 2015 01:08:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E71ED20270 for ; Sat, 31 Jan 2015 01:08:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757405AbbAaBIn (ORCPT ); Fri, 30 Jan 2015 20:08:43 -0500 Received: from smtp.codeaurora.org ([198.145.11.231]:55608 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757268AbbAaBIm (ORCPT ); Fri, 30 Jan 2015 20:08:42 -0500 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 6EA5E140403; Sat, 31 Jan 2015 01:08:41 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id 5C33814040B; Sat, 31 Jan 2015 01:08:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from [10.134.64.202] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A8AAA140403; Sat, 31 Jan 2015 01:08:40 +0000 (UTC) Message-ID: <54CC2B18.2070809@codeaurora.org> Date: Fri, 30 Jan 2015 17:08:40 -0800 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Marcin Jabrzyk , Russell King - ARM Linux CC: Kukjin Kim , Bartlomiej Zolnierkiewicz , Daniel Lezcano , linux-kernel@vger.kernel.org, kyungmin.park@samsung.com, linux-samsung-soc@vger.kernel.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Mark Rutland , Chander Kashyap Subject: Re: =?windows-1252?Q?PROBLEM=3A=A0BUG__appearing_when_tr?= =?windows-1252?Q?ying_to_allocate_interrupt_on_Exynos_MCT_?= =?windows-1252?Q?after_CPU_hotplug?= References: <544907D4.1020409@samsung.com> <20141023140644.GI27405@n2100.arm.linux.org.uk> <54494BEE.9020702@codeaurora.org> <544A52B0.9050901@samsung.com> <544EA810.6090502@codeaurora.org> <5450C391.2070007@samsung.com> In-Reply-To: <5450C391.2070007@samsung.com> X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Kept meaning to get back to this thread. Have you resolved it? On 10/29/14 03:38, Marcin Jabrzyk wrote: > So I've tried this patch, it resolves one problem but introduces also > new ones. As expected the BUG warning is not showing after applying > this patch but there are some interesting side effects. Well that's half good news. > I was looking on /proc/interrupts output. IRQ for CPU0 have "MCT" name > and IRQ for CPU1 has unexpectedly no name at all. This is pretty confusing. I don't see how the patch could cause this to happen. > After making hotplug cycle of CPU1 I've observed that IRQs attached > originally for that CPU are generating on really low count and not in > order with IRQ for CPU0. > What's more the interrupt for CPU1 is showing to me as being counted > for both CPUs, so it's probably not being attached to CPU1. > yeah. Can you give the output of /proc/timer_list in addition to /proc/interrupts? It may give some hints on what's going on. It may also be interesting to see if irq_force_affinity() is failing. Please check the return value and print an error diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c index 1800053b4644..3c4538e26731 100644 --- a/drivers/clocksource/exynos_mct.c +++ b/drivers/clocksource/exynos_mct.c @@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt) { struct mct_clock_event_device *mevt; unsigned int cpu = smp_processor_id(); + int ret; mevt = container_of(evt, struct mct_clock_event_device, evt); @@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct clock_event_device *evt) if (mct_int_type == MCT_INT_SPI) { evt->irq = mct_irqs[MCT_L0_IRQ + cpu]; enable_irq(evt->irq); - irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu)); + ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu)); + if (ret) + pr_err("force failed %d\n", ret); } else { enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0); }