From: Steven Rostedt <rostedt@goodmis.org>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: a.zummo@towertech.it, alexandre.belloni@free-electrons.com,
mingo@redhat.com, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org, arnd@arndb.de, broonie@kernel.org
Subject: Re: [PATCH v3] rtc: Add tracepoints for RTC system
Date: Thu, 14 Dec 2017 12:49:12 -0500 [thread overview]
Message-ID: <20171214124912.3171dafd@gandalf.local.home> (raw)
In-Reply-To: <f819febcf2104918bfda1eadba021f9cc08ed866.1513221837.git.baolin.wang@linaro.org>
On Thu, 14 Dec 2017 13:31:43 +0800
Baolin Wang <baolin.wang@linaro.org> wrote:
> @@ -53,6 +56,8 @@ int rtc_read_time(struct rtc_device *rtc, struct rtc_time *tm)
>
> err = __rtc_read_time(rtc, tm);
> mutex_unlock(&rtc->ops_lock);
> +
> + trace_rtc_read_time(rtc_tm_to_time64(tm), err);
There's a possibility that gcc may put the call to rt_tm_to_time64()
outside the tracepoint area that gets nop'd out. Could you just pass in
the tm to the tracepoint, and have the call to rtc_tm_to_time64() done
within the TP_fast_assign? This would guarantee that we don't incur
overhead when tracing is off.
TP_PROTO(struct rtc_time *tm, int err),
TP_ARGS(tm, err),
TP_fast_assign(
__entry->secs = rt_tm_to_time64(tm);
-- Steve
> diff --git a/include/trace/events/rtc.h b/include/trace/events/rtc.h
> new file mode 100644
> index 0000000..621333f
> --- /dev/null
> +++ b/include/trace/events/rtc.h
> @@ -0,0 +1,206 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM rtc
> +
> +#if !defined(_TRACE_RTC_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_RTC_H
> +
> +#include <linux/rtc.h>
> +#include <linux/tracepoint.h>
> +
> +DECLARE_EVENT_CLASS(rtc_time_alarm_class,
> +
> + TP_PROTO(time64_t secs, int err),
> +
> + TP_ARGS(secs, err),
> +
> + TP_STRUCT__entry(
> + __field(time64_t, secs)
> + __field(int, err)
> + ),
> +
> + TP_fast_assign(
> + __entry->secs = secs;
> + __entry->err = err;
> + ),
> +
> + TP_printk("UTC (%lld) (%d)",
> + __entry->secs, __entry->err
> + )
> +);
> +
> +DEFINE_EVENT(rtc_time_alarm_class, rtc_set_time,
> +
> + TP_PROTO(time64_t secs, int err),
> +
> + TP_ARGS(secs, err)
> +);
> +
> +DEFINE_EVENT(rtc_time_alarm_class, rtc_read_time,
> +
> + TP_PROTO(time64_t secs, int err),
> +
> + TP_ARGS(secs, err)
> +);
> +
next prev parent reply other threads:[~2017-12-14 17:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 5:31 Baolin Wang
2017-12-14 17:49 ` Steven Rostedt [this message]
2017-12-14 18:34 ` Alexandre Belloni
2018-02-13 20:31 ` Alexandre Belloni
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=20171214124912.3171dafd@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@free-electrons.com \
--cc=arnd@arndb.de \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=mingo@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®