Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1433183 > unrolled thread

Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output Stephen Boyd <sboyd@codeaurora.org> - 2016-06-28 19:50 +0200
    Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output Rhyland Klein <rklein@nvidia.com> - 2016-06-30 22:20 +0200

#1433183 — Re: [PATCH v2 10/11] clk: Show CRITICAL clks in clk_summary output

On 06/22, Rhyland Klein wrote:
> On 6/22/2016 8:24 AM, Thierry Reding wrote:
> > 
> > Maybe output " " instead of "" for CLK_IS_CRITICAL, that way you can
> > omit the second conditional.
> > 
> > I wonder if it might be easier to read if this flag was at the end of
> > the line. There's also the fact that someone may have written a script
> > that expects the clock name as the first word on the line and may get
> > confused by this change. If you put it at the very end of the line the
> > likelihood of upsetting scripts will be reduced.
> 
> Yah we can put the mark at the end of the line. I wasn't sure if there
> was a strong motivation to avoid extending the the width of each line,
> as sometimes people prefer to try to keep it close to 80 char as
> possible. I think right now, it was close to that, but might be a little
> over already. I can switch to that though, as it is less likely to break
> any automatic parsing scripts.
> 

Nak. clk_summary is about taking a snapshot of the system state
for things that may be changing rapidly, like consumers (which
sounds fun to add!), rates, enable/prepare state. Flags are not
changing. If you want to add flag info into some summary then a
script should be able to augment clk_summary info (really should
use the clk_dump in this case though) with whatever flags can be
read through debugfs already.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [next] | [standalone]

#1434831

On 6/28/2016 1:40 PM, Stephen Boyd wrote:
> On 06/22, Rhyland Klein wrote:
>> On 6/22/2016 8:24 AM, Thierry Reding wrote:
>>>
>>> Maybe output " " instead of "" for CLK_IS_CRITICAL, that way you can
>>> omit the second conditional.
>>>
>>> I wonder if it might be easier to read if this flag was at the end of
>>> the line. There's also the fact that someone may have written a script
>>> that expects the clock name as the first word on the line and may get
>>> confused by this change. If you put it at the very end of the line the
>>> likelihood of upsetting scripts will be reduced.
>>
>> Yah we can put the mark at the end of the line. I wasn't sure if there
>> was a strong motivation to avoid extending the the width of each line,
>> as sometimes people prefer to try to keep it close to 80 char as
>> possible. I think right now, it was close to that, but might be a little
>> over already. I can switch to that though, as it is less likely to break
>> any automatic parsing scripts.
>>
> 
> Nak. clk_summary is about taking a snapshot of the system state
> for things that may be changing rapidly, like consumers (which
> sounds fun to add!), rates, enable/prepare state. Flags are not
> changing. If you want to add flag info into some summary then a
> script should be able to augment clk_summary info (really should
> use the clk_dump in this case though) with whatever flags can be
> read through debugfs already.
> 

That is fine with me. This was more of something I was using locally to
verify things and thought it might be useful in some manner upstream.
However, a script which read the clk_flags from debugfs for each clk
could do the same thing without changing the summary.

-rhyland

-- 
nvpublic

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web