Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753787Ab3HVRkJ (ORCPT ); Thu, 22 Aug 2013 13:40:09 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:36526 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753373Ab3HVRkI (ORCPT ); Thu, 22 Aug 2013 13:40:08 -0400 Message-ID: <52164CF5.20705@codeaurora.org> Date: Thu, 22 Aug 2013 10:40:05 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Santosh Shilimkar CC: Daniel Lezcano , Russell King , srinivas.kandagatla@st.com, Michal Simek , linux-kernel@vger.kernel.org, Stuart Menefy , John Stultz , =?ISO-8859-1?Q?S=F6ren_Brinkmann?= , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/2] clockevents: Prefer clockevents that don't suffer from FEAT_C3_STOP References: <52138784.7050703@linaro.org> <1377191201-14696-1-git-send-email-sboyd@codeaurora.org> <1377191201-14696-2-git-send-email-sboyd@codeaurora.org> <52164B5B.5010902@ti.com> In-Reply-To: <52164B5B.5010902@ti.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2784 Lines: 64 On 08/22/13 10:33, Santosh Shilimkar wrote: > On Thursday 22 August 2013 01:06 PM, Stephen Boyd wrote: >> On some ARM systems there are two sets of per-cpu timers: the TWD >> timers and the global timers. The TWD timers are rated at 350 and >> the global timers are rated at 300 but the TWD timers suffer from >> FEAT_C3_STOP while the arm global timers don't. The tick device >> selection logic doesn't consider the FEAT_C3_STOP flag so we'll >> always end up with the TWD as the tick device although we don't >> want that. >> >> Extend the preference logic to take the FEAT_C3_STOP flag into >> account and always prefer tick devices that don't suffer from >> FEAT_C3_STOP even if their rating is lower than tick devices that >> do suffer from FEAT_C3_STOP. This will remove the need to do any >> broadcasting on such ARM systems. >> >> Signed-off-by: Stephen Boyd >> --- >> kernel/time/tick-common.c | 14 ++++++++++++-- >> 1 file changed, 12 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c >> index 64522ec..3ae437d 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; >> + > I don't think preferring the clock-event which doesn't suffer > from FEAT_C3STOP is a good idea if the quality of the time source > is not same. Generally the global timers are slow and far away from > CPU(cycle cost). So as long as we don't get impacted because of low power > states, the tick should run out of local timers which are faster access > as well as high resolution. > Fair enough. I have no data either way to convince anyone that this is a good or bad idea so this patch should have probably been an RFC. Are you hinting at something like switching to a per-cpu timer that doesn't suffer from FEAT_C3_STOP when a CPU goes into a deep idle state? Interesting idea but I think I'll leave that to someone else if they really care to do that. -- 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/