Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753446AbdDMNxS (ORCPT ); Thu, 13 Apr 2017 09:53:18 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:4932 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751378AbdDMNxQ (ORCPT ); Thu, 13 Apr 2017 09:53:16 -0400 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Thu, 13 Apr 2017 06:53:15 -0700 Date: Thu, 13 Apr 2017 16:50:45 +0300 From: Peter De Schrijver To: Stephen Boyd CC: Michael Turquette , , , Alex Frid Subject: Re: [PATCH] clk: Add requested rate to clock summary output Message-ID: <20170413135045.GW30730@tbergstrom-lnx.Nvidia.com> References: <1490188803-13034-1-git-send-email-pdeschrijver@nvidia.com> <20170412164856.GP7065@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170412164856.GP7065@codeaurora.org> X-NVConfidentiality: public User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.21.24.170] X-ClientProxiedBy: DRUKMAIL101.nvidia.com (10.25.59.19) To drukmail101.nvidia.com (10.25.59.19) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1263 Lines: 29 On Wed, Apr 12, 2017 at 09:48:56AM -0700, Stephen Boyd wrote: > On 03/22, Peter De Schrijver wrote: > > From: Alex Frid > > > > Added requested rate to clock summary output and to clock dump. This is > > useful for clock tree debugging. Also expand the clock name field in the > > clock tree debugfs output to provide room for deep multi-tier trees like > > on Tegra. > > > > Signed-off-by: Alex Frid > > Signed-off-by: Peter De Schrijver > > We should print out all the consumers (struct clks) and their > requested rates + prepare/enable counts instead. req_rate is sort > of an internal variable that records what the last aggregated > rate was. I'm not sure if we want to expose that to debugfs. > While this certainly would provide more information, I think it would also make the summary quite large. Hence the just printing the aggregate rate seems a reasonable compromise. Maybe the consumers and requested rates can be exposed in a file in the per clock directory. The prepare and enable counts are not maintained per consumer today, so that's not possible? Peter. > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project