All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette@linaro.org>
To: Stephen Boyd <sboyd@codeaurora.org>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: Add tracepoints for hardware operations
Date: Tue, 01 Jul 2014 20:44:20 -0700	[thread overview]
Message-ID: <20140702034420.32686.53303@quantum> (raw)
In-Reply-To: <53B209E5.1050701@codeaurora.org>

Quoting Stephen Boyd (2014-06-30 18:07:49)
> On 06/30/14 17:52, Steven Rostedt wrote:
> > On Mon, 30 Jun 2014 16:56:39 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> >> @@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
> >>              return;
> >>  
> >>      if (__clk_is_prepared(clk)) {
> >> +            trace_clk_unprepare(clk);
> > Does it make sense to do these when clk->ops->unprepared_unused or
> > uprepare is not set?
> >
> > You can use DEFINE_EVENT_CONDITIONAL() and add as condition:
> >
> >    clk->ops->unprepared_unused || clk->ops->unprepare
> >
> 
> Neat. I don't know if we actually want to do that though. If we always
> record an event even when the hardware doesn't support the operation we
> get information about events happening to the clock from a software
> perspective. If that isn't important, then we can probably just put it
> under the if conditions.

+1 for recording the tree walk even if no hardware operation is backing
it.

Regards,
Mike

> 
> >
> >>              if (clk->ops->enable) {
> >>                      ret = clk->ops->enable(clk->hw);
> >>                      if (ret) {
> >> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
> >>                              return ret;
> > It may make even more sense to add the tracepoints within the if
> > statement. Especially if you have a return on error.
> >
> >
> 
> Right. I was thinking that no "clk*_complete" event would mean there was
> some error. Detecting that case is not so easy though. It may be better
> to always have the completion event so we know how long hardware
> operations take and so that error handling is simpler.
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 

WARNING: multiple messages have this Message-ID (diff)
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: Add tracepoints for hardware operations
Date: Tue, 01 Jul 2014 20:44:20 -0700	[thread overview]
Message-ID: <20140702034420.32686.53303@quantum> (raw)
In-Reply-To: <53B209E5.1050701@codeaurora.org>

Quoting Stephen Boyd (2014-06-30 18:07:49)
> On 06/30/14 17:52, Steven Rostedt wrote:
> > On Mon, 30 Jun 2014 16:56:39 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> >> @@ -483,10 +486,12 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
> >>              return;
> >>  
> >>      if (__clk_is_prepared(clk)) {
> >> +            trace_clk_unprepare(clk);
> > Does it make sense to do these when clk->ops->unprepared_unused or
> > uprepare is not set?
> >
> > You can use DEFINE_EVENT_CONDITIONAL() and add as condition:
> >
> >    clk->ops->unprepared_unused || clk->ops->unprepare
> >
> 
> Neat. I don't know if we actually want to do that though. If we always
> record an event even when the hardware doesn't support the operation we
> get information about events happening to the clock from a software
> perspective. If that isn't important, then we can probably just put it
> under the if conditions.

+1 for recording the tree walk even if no hardware operation is backing
it.

Regards,
Mike

> 
> >
> >>              if (clk->ops->enable) {
> >>                      ret = clk->ops->enable(clk->hw);
> >>                      if (ret) {
> >> @@ -945,6 +965,7 @@ static int __clk_enable(struct clk *clk)
> >>                              return ret;
> > It may make even more sense to add the tracepoints within the if
> > statement. Especially if you have a return on error.
> >
> >
> 
> Right. I was thinking that no "clk*_complete" event would mean there was
> some error. Detecting that case is not so easy though. It may be better
> to always have the completion event so we know how long hardware
> operations take and so that error handling is simpler.
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 

  parent reply	other threads:[~2014-07-02  3:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 23:56 [PATCH] clk: Add tracepoints for hardware operations Stephen Boyd
2014-06-30 23:56 ` Stephen Boyd
2014-07-01  0:52 ` Steven Rostedt
2014-07-01  0:52   ` Steven Rostedt
2014-07-01  1:07   ` Stephen Boyd
2014-07-01  1:07     ` Stephen Boyd
2014-07-01  1:11     ` Steven Rostedt
2014-07-01  1:11       ` Steven Rostedt
2014-07-02  3:44     ` Mike Turquette [this message]
2014-07-02  3:44       ` Mike Turquette
  -- strict thread matches above, loose matches on Subject: below --
2015-01-31  0:16 Stephen Boyd
2015-02-02 16:00 ` Steven Rostedt
2015-02-02 19:05   ` Mike Turquette
2015-02-02 19:41   ` Stephen Boyd
2015-02-02 20:00     ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140702034420.32686.53303@quantum \
    --to=mturquette@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.