From patchwork Thu Aug 28 06:55:35 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Horman X-Patchwork-Id: 4801731 Return-Path: X-Original-To: patchwork-ltsi-dev@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C84FE9F375 for ; Thu, 28 Aug 2014 09:04:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9E8C820123 for ; Thu, 28 Aug 2014 09:04:23 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 69A9B20122 for ; Thu, 28 Aug 2014 09:04:22 +0000 (UTC) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id DD78617E2; Thu, 28 Aug 2014 07:38:34 +0000 (UTC) X-Original-To: ltsi-dev@lists.linuxfoundation.org Delivered-To: ltsi-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3A52815FC for ; Thu, 28 Aug 2014 07:38:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from kirsty.vergenet.net (kirsty.vergenet.net [202.4.237.240]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B94062022F for ; Thu, 28 Aug 2014 07:37:59 +0000 (UTC) Received: from ayumi.isobedori.kobe.vergenet.net (p4222-ipbfp1605kobeminato.hyogo.ocn.ne.jp [114.154.95.222]) by kirsty.vergenet.net (Postfix) with ESMTP id 337BD267218; Thu, 28 Aug 2014 17:07:57 +1000 (EST) Received: by ayumi.isobedori.kobe.vergenet.net (Postfix, from userid 7100) id B719DEDEAE6; Thu, 28 Aug 2014 16:07:55 +0900 (JST) From: Simon Horman To: ltsi-dev@lists.linuxfoundation.org Date: Thu, 28 Aug 2014 15:55:35 +0900 Message-Id: <1409209620-24487-210-git-send-email-horms+renesas@verge.net.au> X-Mailer: git-send-email 2.0.1 In-Reply-To: <1409209620-24487-1-git-send-email-horms+renesas@verge.net.au> References: <1409209620-24487-1-git-send-email-horms+renesas@verge.net.au> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org Cc: Magnus Damm Subject: [LTSI-dev] [PATCH LTSI-3.14 209/894] clocksource: sh_cmt: Set cpumask to cpu_possible_mask X-BeenThere: ltsi-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "A list to discuss patches, development, and other things related to the LTSI project" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: ltsi-dev-bounces@lists.linuxfoundation.org Errors-To: ltsi-dev-bounces@lists.linuxfoundation.org X-Virus-Scanned: ClamAV using ClamSMTP From: Laurent Pinchart The CMT is a global timer not restricted to a single CPU. It has a lower rating than the TMU or ARM architected timer, but is still useful on systems where the other timers are stopped during CPU sleep. When multiple timers are available the timers core selects which timer to use based on timer ratings. On SMP systems where timer broadcasting is required, one dummy timer is instantiated per CPU with a rating of 100. On those systems the CMT timer has a rating of 80, which makes the dummy timer selected by default on all CPUs. The CMT is then available, and will be used as a broadcast timer. On UP systems no dummy timer is instantiated. The CMT timer has a rating of 125 on those systems and is used directly as a clock event device for CPU0 without broadcasting. The CMT rating shouldn't depend on whether we boot a UP or SMP system. We can't raise the CMT rating to 125 on SMP systems. This would select CMT as the clock event device for CPU0 as its rating is higher than the dummy timer rating, and would leave the system without a broadcast timer. We could instead lower the rating to 80 on all systems, but that wouldn't reflect reality as ratings between 1 and 99 are documented as "unfit for real use". We should raise the rating above 99 and still have the CMT selected as a broadcast timer. This can be done by changing the cpumask from cpumask_of(0) to cpu_possible_mask. In that case the timer selection logic will prefer the previously probed and already selected dummy timer for all CPUs based on the fact that already selected per-cpu timers are preferred over new global timers, regardless of their respective ratings. This also better reflects reality, as the CMT is not tied to the boot CPU. Ideally the timer selection logic should realize that the CMT needs to be used as a broadcast timer on SMP systems as no other broadcast timer is available, regardless of the cpumask and rating. Signed-off-by: Laurent Pinchart (cherry picked from commit f1ebe1e47e1979393a8492bfe751176908a830ae) Signed-off-by: Simon Horman --- drivers/clocksource/sh_cmt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c index ce00baa..926abe2 100644 --- a/drivers/clocksource/sh_cmt.c +++ b/drivers/clocksource/sh_cmt.c @@ -776,7 +776,7 @@ static void sh_cmt_register_clockevent(struct sh_cmt_channel *ch, ced->features = CLOCK_EVT_FEAT_PERIODIC; ced->features |= CLOCK_EVT_FEAT_ONESHOT; ced->rating = rating; - ced->cpumask = cpumask_of(0); + ced->cpumask = cpu_possible_mask; ced->set_next_event = sh_cmt_clock_event_next; ced->set_mode = sh_cmt_clock_event_mode; ced->suspend = sh_cmt_clock_event_suspend;