From patchwork Thu Sep 11 15:52:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 388313 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 8A60F14010C for ; Fri, 12 Sep 2014 01:52:37 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756845AbaIKPwS (ORCPT ); Thu, 11 Sep 2014 11:52:18 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:62607 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756713AbaIKPwP (ORCPT ); Thu, 11 Sep 2014 11:52:15 -0400 Received: by mail-pa0-f51.google.com with SMTP id kx10so10155194pab.38 for ; Thu, 11 Sep 2014 08:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=H+GObuDs5bHAw6NKOGI2z4eyqcyZzSwM+zJcphw5pCE=; b=NQWlFr1KPAsqp7e12mp7AtOMNdBbZuDti1a+N7RhoLwAHL4Jzf/6S5ty9C60iV2UfQ bnxwB8rsk4hFwPk2UG8MVATS1uOOcGAix98t2MN7/a6LnTtoqGSmG9a6xGVSpTq5P5gG ejWpMqIx/7/MH7zXT+gq8g4SndPR6x1MmnDIQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=H+GObuDs5bHAw6NKOGI2z4eyqcyZzSwM+zJcphw5pCE=; b=m3udM11bhYCBGj8neNJVSM5M9/V1Jj9+iHQPNg00IU/lhr/awhLUnnsxAyShpkiUff hZ9ADdJenoleBEJAYlMYcblNm1em8RylMIVx+6eAwadhbso6EOJ6k3AHoOCCmsdG/f8o MpZUPqyxxK46AOBr4cttTqnOu7jMyau1rP4g09ZrcqXpx0JAkpt3l+CccAEnw24MCtNx VTHM8lHjqMxDpDd0gRy724jWC3jQvZ3F9pfhhrsleCoHYQsqE0Hb3/aRr7lHRfJkBB9Y qKZpGxXGW2LUvLKwT4MwWuVZevEMbVIdvmkCw20R89C+xi8ncMFmaebwiDAv42P9MrBI MHWg== X-Gm-Message-State: ALoCoQlPHSXXyMIF5ZVkB0t3+Ig3qzb080z+dcZZiecgED6n5X0rtKzCaspSDgSTVu5yHTBaCdHk X-Received: by 10.70.36.138 with SMTP id q10mr1460053pdj.88.1410450735098; Thu, 11 Sep 2014 08:52:15 -0700 (PDT) Received: from tictac.mtv.corp.google.com (tictac.mtv.corp.google.com [172.22.162.15]) by mx.google.com with ESMTPSA id v1sm1386137pdn.93.2014.09.11.08.52.13 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 08:52:14 -0700 (PDT) From: Doug Anderson To: olof@lixom.net Cc: Sonny Rao , Will Deacon , Catalin Marinas , Mark Rutland , Stephen Boyd , Marc Zyngier , Sudeep Holla , Christopher Covington , Lorenzo Pieralisi , Thomas Gleixner , Daniel Lezcano , linux-arm-kernel@lists.infradead.org, Doug Anderson , robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] clocksource: arch_timer: Allow the device tree to specify the physical timer Date: Thu, 11 Sep 2014 08:52:07 -0700 Message-Id: <1410450727-8182-1-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.1.0.rc2.206.gedb03e5 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Some 32-bit (ARMv7) systems are architected like this: * The firmware doesn't know and doesn't care about hypervisor mode and we don't want to add the complexity of hypervisor there. * The firmware isn't involved in SMP bringup or resume. * The ARCH timer come up with an uninitialized offset between the virtual and physical counters. Each core gets a different random offset. On systems like the above, it doesn't make sense to use the virtual counter. There's nobody managing the offset and each time a core goes down and comes back up it will get reinitialized to some other random value. Let's add a property to the device tree to say that we shouldn't use the virtual timer. Firmware could potentially remove this property before passing the device tree to the kernel if it really wants the kernel to use a virtual timer. Note that it's been said that ARM64 (ARMv8) systems the firmware and kernel really can't be architected as described above. That means using the physical timer like this really only makes sense for ARMv7 systems. In order for this patch to do anything useful, we also need Sonny's patch at Signed-off-by: Doug Anderson Signed-off-by: Sonny Rao --- Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ drivers/clocksource/arm_arch_timer.c | 3 +++ 2 files changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 37b2caf..876d32b 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -22,6 +22,12 @@ to deliver its interrupts via SPIs. - always-on : a boolean property. If present, the timer is powered through an always-on power domain, therefore it never loses context. +** Optional properties: + +- arm,use-physical-timer : Don't ever use the virtual timer, just use the + physical one. Not supported for ARM64. + + Example: timer { diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 5163ec1..8ca07a9 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -649,6 +649,9 @@ static void __init arch_timer_init(struct device_node *np) arch_timer_ppi[i] = irq_of_parse_and_map(np, i); arch_timer_detect_rate(NULL, np); + if (of_property_read_bool(np, "arm,use-physical-timer")) + arch_timer_use_virtual = false; + /* * If HYP mode is available, we know that the physical timer * has been configured to be accessible from PL1. Use it, so