From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH] trace: extend trace_clock to support arch_arm clock counter Date: Fri, 2 Dec 2016 11:08:45 +0000 Message-ID: <20161202110845.GC8266@arm.com> References: <1480666495-26536-1-git-send-email-sramana@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss.arm.com ([217.140.101.70]:35520 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751731AbcLBLIq (ORCPT ); Fri, 2 Dec 2016 06:08:46 -0500 Content-Disposition: inline In-Reply-To: <1480666495-26536-1-git-send-email-sramana@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Srinivas Ramana Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote: > Extend the trace_clock to support the arch timer cycle > counter so that we can get the monotonic cycle count > in the traces. This will help in correlating the traces with the > timestamps/events in other subsystems in the soc which share > this common counter for driving their timers. I'm not sure I follow this reasoning. What's wrong with nanoseconds? In particular, the "perf" trace_clock hangs off sched_clock, which should be backed by the architected counter anyway. What does the cycle counter in isolation tell you, given that the frequency isn't architected? I think I'm missing something here. Will