Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757391Ab3HLQUX (ORCPT ); Mon, 12 Aug 2013 12:20:23 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:57580 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757335Ab3HLQUU (ORCPT ); Mon, 12 Aug 2013 12:20:20 -0400 Message-ID: <52090B43.9090000@codeaurora.org> Date: Mon, 12 Aug 2013 09:20:19 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?U8O2cmVuIEJyaW5rbWFubg==?= CC: Daniel Lezcano , srinivas.kandagatla@st.com, Russell King , Michal Simek , linux-kernel@vger.kernel.org, Stuart Menefy , John Stultz , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Subject: Re: Enable arm_global_timer for Zynq brakes boot References: <15e19315-ce88-4d3c-bad9-0a37d9e52f6b@CO1EHSMHS007.ehs.local> <51F99747.4060901@linaro.org> <51FA9AE8.1060004@linaro.org> <1c83c081-60c6-49e3-a85c-f64dd5be0e60@CH1EHSMHS030.ehs.local> <51FA9F54.3060704@linaro.org> <5204C54A.9020105@st.com> <5204FA5D.3060908@linaro.org> <20130809172757.GD14845@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3102 Lines: 77 On 08/12/13 09:03, Sören Brinkmann wrote: > On Fri, Aug 09, 2013 at 10:27:57AM -0700, Stephen Boyd wrote: >> On 08/09, Daniel Lezcano wrote: >>> yes, but at least the broadcast mechanism should send an IPI to cpu0 to >>> wake it up, no ? As Stephen stated this kind of configuration should has >>> never been tested before so the tick broadcast code is not handling this >>> case properly IMHO. >>> >> If you have a per-cpu tick device that isn't suffering from >> FEAT_C3_STOP why wouldn't you use that for the tick versus a >> per-cpu tick device that has FEAT_C3_STOP? It sounds like there >> is a bug in the preference logic or you should boost the rating >> of the arm global timer above the twd. Does this patch help? It >> should make the arm global timer the tick device and whatever the >> cadence timer you have into the broadcast device. > I finally got to test your patch. Unfortunately, it makes the system > hang even earlier: Sorry it had a bug depending on the registration order. Can you try this one (tabs are probably spaces, sorry)? I will go read through this thread to see if we already covered the registration order. ---8<---- diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 218bcb5..d3539e5 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -77,6 +77,9 @@ static bool tick_check_broadcast_device(struct clock_event_device *curdev, !(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) return false; + if (cpumask_equal(newdev->cpumask, cpumask_of(smp_processor_id()))) + return false; + return !curdev || newdev->rating > curdev->rating; } diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c index 64522ec..dd08f3b 100644 --- a/kernel/time/tick-common.c +++ b/kernel/time/tick-common.c @@ -244,12 +244,22 @@ static bool tick_check_preferred(struct clock_event_device *curdev, return false; } + if (!curdev) + return true; + + /* Always prefer a tick device that doesn't suffer from FEAT_C3STOP */ + if (!(newdev->features & CLOCK_EVT_FEAT_C3STOP) && + (curdev->features & CLOCK_EVT_FEAT_C3STOP)) + return true; + if ((newdev->features & CLOCK_EVT_FEAT_C3STOP) && + !(curdev->features & CLOCK_EVT_FEAT_C3STOP)) + return false; + /* * Use the higher rated one, but prefer a CPU local device with a lower * rating than a non-CPU local device */ - return !curdev || - newdev->rating > curdev->rating || + return newdev->rating > curdev->rating || !cpumask_equal(curdev->cpumask, newdev->cpumask); } -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/