From patchwork Thu Sep 11 16:16:44 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 388321 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 9A0AC1400F0 for ; Fri, 12 Sep 2014 02:17:19 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752786AbaIKQRA (ORCPT ); Thu, 11 Sep 2014 12:17:00 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:46817 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755196AbaIKQQ6 (ORCPT ); Thu, 11 Sep 2014 12:16:58 -0400 Received: by mail-pa0-f54.google.com with SMTP id lj1so11035855pab.27 for ; Thu, 11 Sep 2014 09:16:58 -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=cV17zhdaQBJLtzYHUZhVJxCNwNqawTqJlYhsT//5DbA=; b=nLGGjkhT1AsfrURNFtCkVWVw1A2tCRseGWJOWif2zAXjgBx5HlVMb5EymWJ9GW5Nzj 4ODTIohvX1YBmIUI+Nt+TM3WpIIJk7WoCw36GnAHnGzFkq+xj9WXbNnZHE/4QH/lOVbN wr2NQCBPOGMBj8bK77ONsD5NC79sBpkViSDpU= 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=cV17zhdaQBJLtzYHUZhVJxCNwNqawTqJlYhsT//5DbA=; b=IjwFHV8GPmV8l702O+Tiek8HfGtwgXg/AkKB+ZNxVxs87KJVHEC+G6TeMbjwdqgKgZ LQPGFjGMPLp7Yeej1B2d5frnwLtcU8q8X8YXxl0xWMmTAkdEKECwhjzCdWJ/nnkHqqlW W0s25bIGhur80RHoTnNs2pJQH06hjk/ZXSSAa3fwaIaemDfkQc2Q0wsrH0v+bhap6wjV 86h2ZSalUQyDuSEDiI49dpvwO43a8MxK4dOvf5+5aqD8rNN6vlCph5nwoC02j+TdzWt+ BfkUeEFDmeR9YR2s26wFoKYyaA8Ypf1V6Cn5ERyuNLh1Imxcz9+74re+k4BzIAgE/NIe U/WQ== X-Gm-Message-State: ALoCoQkxKU73DDIlNNY+uFRGnIaG+zpRNijaVV8RS5oSnegbRYs3uc53nXfiF/6VBlcZgRnu0tSV X-Received: by 10.66.90.162 with SMTP id bx2mr2969744pab.39.1410452218231; Thu, 11 Sep 2014 09:16:58 -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 f3sm1565931pdk.6.2014.09.11.09.16.56 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 09:16:57 -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 , Nathan Lynch , 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 v2] clocksource: arch_timer: Allow the device tree to specify the physical timer Date: Thu, 11 Sep 2014 09:16:44 -0700 Message-Id: <1410452204-7277-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 --- Changes in v2: - Add "#ifdef CONFIG_ARM" as per Will Deacon Documentation/devicetree/bindings/arm/arch_timer.txt | 6 ++++++ drivers/clocksource/arm_arch_timer.c | 5 +++++ 2 files changed, 11 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..e7aa256 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -649,6 +649,11 @@ 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); +#ifdef CONFIG_ARM + if (of_property_read_bool(np, "arm,use-physical-timer")) + arch_timer_use_virtual = false; +#endif + /* * If HYP mode is available, we know that the physical timer * has been configured to be accessible from PL1. Use it, so