Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757255Ab3HLQxP (ORCPT ); Mon, 12 Aug 2013 12:53:15 -0400 Received: from mail-we0-f171.google.com ([74.125.82.171]:62106 "EHLO mail-we0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756707Ab3HLQxO (ORCPT ); Mon, 12 Aug 2013 12:53:14 -0400 Message-ID: <520912F6.402@linaro.org> Date: Mon, 12 Aug 2013 18:53:10 +0200 From: Daniel Lezcano User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Boyd CC: srinivas.kandagatla@st.com, S??ren Brinkmann , 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: <51F97CE3.9030306@linaro.org> <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> <5208BEC4.7090700@linaro.org> <52090C0A.2000105@codeaurora.org> In-Reply-To: <52090C0A.2000105@codeaurora.org> 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: 3442 Lines: 82 On 08/12/2013 06:23 PM, Stephen Boyd wrote: > On 08/12/13 03:53, Daniel Lezcano wrote: >> On 08/09/2013 07:27 PM, 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. >>> >>> ---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; >> Yes, that makes sense to prevent local timer devices to be a broadcast one. >> >> In the case of the arm global timer, each cpu will register their timer, >> so the test will be ok but is it possible the cpu0 registers the timers >> for the other cpus ? > > As far as I know every tick device has to be registered on the CPU that > it will be used on. See tick_check_percpu(). Ah, ok I see. Thx for the pointer. >>> return !curdev || newdev->rating > curdev->rating; >>> } >>> >>> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c >>> index 64522ec..1628b9f 100644 >>> --- a/kernel/time/tick-common.c >>> +++ b/kernel/time/tick-common.c >>> @@ -245,6 +245,15 @@ static bool tick_check_preferred(struct clock_event_device *curdev, >>> } >>> >>> /* >>> + * Prefer tick devices that don't suffer from FEAT_C3_STOP >>> + * regardless of their rating >>> + */ >>> + if (curdev && cpumask_equal(curdev->cpumask, newdev->cpumask) && >>> + !(newdev->features & CLOCK_EVT_FEAT_C3STOP) && >>> + (curdev->features & CLOCK_EVT_FEAT_C3STOP)) >>> + return true; >> That sounds reasonable, but what is the acceptable gap between the >> ratings ? I am wondering if there isn't too much heuristic in the tick >> code... > > Yes I wonder if we should just change the ratings of the clockevents. > But it feels to me like the rating should only matter if the two are > equal in features. Otherwise we can use the features to determine what > we want. Is it desirable for real time system ? (I am not expert in this area, so may be this question has no sense :) -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/