From patchwork Thu Aug 28 17:03:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 36251 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yh0-f70.google.com (mail-yh0-f70.google.com [209.85.213.70]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 583752054F for ; Thu, 28 Aug 2014 17:04:06 +0000 (UTC) Received: by mail-yh0-f70.google.com with SMTP id b6sf6081343yha.9 for ; Thu, 28 Aug 2014 10:04:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :references:mime-version:in-reply-to:user-agent:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe :content-type:content-disposition; bh=q9XPAvCzAEKrMYu3dPSFl1mpIyRP9RNKsem4k83R+gs=; b=BKGrX2VmmPJaP1EciKox8iQzEYWXSJXFN6SC0B5rnwu/sHIAGd3O4XZ1kToybN/Kqg ULEB53zeUAI5CWe3yWChHeKhyUdS442svL3vRJ2ZErLPZDFqRK5kSe+IQmvLUfFzX8EE Rt6/5sInwFfImUK/7uYmI36NzTlYFwH6chuzfLffhWwWZynvGCleyBg93EMbCwTIkHvz zKKy+TZ3j15QP6vks1UN/u6J+rRqk1JMyEEQyVq4vM39UQ/OIGms6VfrVkpM/zTCYaE4 931ADg8OzqjW/GPekJo61XwczChTDWv1hZXWi1mWBPeelpUQ0QNk/5lSf0f5zzvg94ua B2mw== X-Gm-Message-State: ALoCoQlsjsEmVZ/EJaoxEsBckhlwZX3egTBUPFcNZr85RH3iebllpqm8iUb6i989SJUuKnbaGrme X-Received: by 10.224.7.198 with SMTP id e6mr2646378qae.1.1409245446146; Thu, 28 Aug 2014 10:04:06 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.37.237 with SMTP id r100ls737320qgr.49.gmail; Thu, 28 Aug 2014 10:04:06 -0700 (PDT) X-Received: by 10.220.77.65 with SMTP id f1mr2468743vck.48.1409245446011; Thu, 28 Aug 2014 10:04:06 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by mx.google.com with ESMTPS id ty1si4263375vcb.101.2014.08.28.10.04.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 10:04:05 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.170 as permitted sender) client-ip=209.85.220.170; Received: by mail-vc0-f170.google.com with SMTP id la4so1187759vcb.29 for ; Thu, 28 Aug 2014 10:04:05 -0700 (PDT) X-Received: by 10.220.169.72 with SMTP id x8mr2464789vcy.45.1409245445765; Thu, 28 Aug 2014 10:04:05 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.45.67 with SMTP id uj3csp268672vcb; Thu, 28 Aug 2014 10:04:05 -0700 (PDT) X-Received: by 10.70.56.101 with SMTP id z5mr7708082pdp.47.1409245444772; Thu, 28 Aug 2014 10:04:04 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pc10si945244pbc.211.2014.08.28.10.04.04 for ; Thu, 28 Aug 2014 10:04:04 -0700 (PDT) Received-SPF: none (google.com: linux-samsung-soc-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751540AbaH1RED (ORCPT + 6 others); Thu, 28 Aug 2014 13:04:03 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:38622 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbaH1REC (ORCPT ); Thu, 28 Aug 2014 13:04:02 -0400 Received: from leverpostej (leverpostej.cambridge.arm.com [10.1.205.151]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id s7SH3Bwo002769; Thu, 28 Aug 2014 18:03:11 +0100 (BST) Date: Thu, 28 Aug 2014 18:03:06 +0100 From: Mark Rutland To: Olof Johansson , marc.zyngier@arm.com Cc: Naveen Krishna Chatradhi , Catalin Marinas , "naveenkrishna.ch@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" , "devicetree@vger.kernel.org" , "cpgs@samsung.com" , Thomas Abraham , Rob Herring Subject: Re: [PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7 Message-ID: <20140828170306.GQ14650@leverpostej> References: <1409132660-1898-1-git-send-email-ch.naveen@samsung.com> <1409132660-1898-3-git-send-email-ch.naveen@samsung.com> <20140828035639.GB4972@localhost> <20140828094846.GD14650@leverpostej> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: mark.rutland@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.170 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , Content-Disposition: inline On Thu, Aug 28, 2014 at 05:28:22PM +0100, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 2:48 AM, Mark Rutland wrote: > > Hi, > > > >> > + cpus { > >> > + #address-cells = <2>; > >> > + #size-cells = <0>; > >> > >> Why size-cells=2? Can you not fit a cpuid in 32 bits? > > > > As of commit 72aea393a2e7 (arm64: smp: honour #address-size when parsing > > CPU reg property) Linux can handle single-cell cpu node reg entries > > where /cpus/#address-cells = <1>. > > > > I can't make any guarantees about other code (e.g. bootloaders) which > > might try to do things with cpu nodes, YMMV. > > Ok. If address-cells is kept at 2 the unit address needs to be changed > to "0,0". So one or the other has to be changed. I'm happy either way. I'm not sure the rest of the tree had "0," prefixes on all of the unit-addresses for 64-bit addresses that were under 4GB, and I'm not sure that existing dts consistently do that either. Do we want to enforce that for all 64-bit unit-addresses? > > [...] > > > >> > + hsi2c_2: hsi2c@14E60000 { > >> > >> I much prefer lowercase hex in unit addresses (and reg entries) below. I > >> know 32-bit uses uppercase, but let's switch going forward here. > > > > My preference also; I'm happy to enforce that on new dts. > > > > [...] > > > >> > + timer { > >> > + compatible = "arm,armv8-timer"; > >> > + interrupts = <1 13 0xff01>, > >> > + <1 14 0xff01>, > >> > + <1 11 0xff01>, > >> > + <1 10 0xff01>; > >> > + clock-frequency = <24000000>; > >> > + use-clocksource-only; > >> > + use-physical-timer; > >> > >> These two properties are not standard, and I would expect any 64-bit > >> platform to come with PSCI such that you have a way to initialize the > >> virtual timers. > > > > Likewise with clock-frequency. It's not a full workaround, and it's not > > hard to initialise CNTFRQ on each CPU. > > Technically clock-frequency is documented, but not recommended to be > used unless needed for working around firmware that doesn't setup the > register value. :) True. > In this case it's likely a cargo cult carry over from 5250 where the > CNTFRQ requirement happened around the same time as we were working on > it so that generation firmware lacked support for it -- it should > since then have been fixed properly. It's probably unhelpful that the documentation isn't explicit about that. On that front, how about the patch below? Mark. ---->8---- >From 67104ad5a56e4c18f9c41f06af028b7561740afd Mon Sep 17 00:00:00 2001 From: Mark Rutland Date: Thu, 28 Aug 2014 17:41:03 +0100 Subject: [PATCH] Doc: dt: arch_timer: discourage clock-frequency use The ARM Generic Timer (AKA the architected timer, arm_arch_timer) features a CPU register (CNTFRQ) which firmware is intended to initialize, and non-secure software can read to determine the frequency of the timer. On CPUs with secure state, this register cannot be written from non-secure states. The firmware of early SoCs featuring the timer did not correctly initialize CNTFRQ correctly on all CPUs, requiring the frequency to be described in DT as a workaround. This workaround is not complete however as CNTFRQ is exposed to all software in a privileged non-secure mode, including KVM guests. The firmware and DTs for recent SoCs have followed the example set by these early SoCs. This patch updates the arch timer binding documentation to make it clearer that the use of the clock-frequency property is a poor work-around. The MMIO generic timer binding is similarly updated, though this is less of a concern as there is generally no need to expose the MMIO timers to guest OSs. Signed-off-by: Mark Rutland Cc: Marc Zyngier Acked-by: Olof Johansson Acked-by: Marc Zyngier --- Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 37b2caf..5ca3f95 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -17,7 +17,10 @@ to deliver its interrupts via SPIs. - interrupts : Interrupt list for secure, non-secure, virtual and hypervisor timers, in that order. -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only where necessary to work around BROKEN firmware which does not configure + CNTFRQ on all CPUs to a uniform correct value. Use of this property is + STRONGLY DISCOURAGED; fix your firmware unless absolutely impossible. - always-on : a boolean property. If present, the timer is powered through an always-on power domain, therefore it never loses context. @@ -38,7 +41,8 @@ Example: - compatible : Should at least contain "arm,armv7-timer-mem". -- clock-frequency : The frequency of the main counter, in Hz. Optional. +- clock-frequency : The frequency of the main counter, in Hz. Should be present + only when firmware has not configured the MMIO CNTFRQ registers. - reg : The control frame base address.