Date: Fri, 2 Dec 2016 11:08:45 +0000
From: Will Deacon <will.deacon@arm.com>
To: Srinivas Ramana <sramana@codeaurora.org>
Cc: catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] trace: extend trace_clock to support arch_arm clock
 counter
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
Content-Disposition: inline
In-Reply-To: <1480666495-26536-1-git-send-email-sramana@codeaurora.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 682
Lines: 15

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