korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-24 04:34:08 +08:00
Code Issues Packages Projects Releases Wiki Activity
cf986e57d6
linux/include/trace/events/scmi.h

181 lines
4.6 KiB
C
Raw Normal View History

include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM scmi
#if !defined(_TRACE_SCMI_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_SCMI_H
#include <linux/tracepoint.h>
include: trace: Add SCMI fast channel tracing All the currently defined SCMI events are meant to trace only regular SCMI transfers based on SCMI messages exchanges; SCMI transactions based on fast channels, where used, are completely invisible from the tracing point of view. Add support to trace fast channel transactions; while doing that avoid exposing full shared memory location addresses. Link: https://lore.kernel.org/r/20220704102241.2988447-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04 18:22:39 +08:00
TRACE_EVENT(scmi_fc_call,
TP_PROTO(u8 protocol_id, u8 msg_id, u32 res_id, u32 val1, u32 val2),
TP_ARGS(protocol_id, msg_id, res_id, val1, val2),
TP_STRUCT__entry(
__field(u8, protocol_id)
__field(u8, msg_id)
__field(u32, res_id)
__field(u32, val1)
__field(u32, val2)
),
TP_fast_assign(
__entry->protocol_id = protocol_id;
__entry->msg_id = msg_id;
__entry->res_id = res_id;
__entry->val1 = val1;
__entry->val2 = val2;
),
firmware: arm_scmi: Harmonize SCMI tracing message format After the recently added new scmi_msg_dump traces, the general format of the various other SCMI traces are not consistent. As an example the full traces of a simple PERF_LEVEL_SET: | cpufreq-set-276 scmi_xfer_begin: transfer_id=145 msg_id=7 protocol_id=19 seq=145 poll=0 | cpufreq-set-276 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0091 s=0 pyld=000000008066ab13 | cpufreq-set-276 scmi_xfer_response_wait: transfer_id=145 msg_id=7 protocol_id=19 seq=145 tmo_ms=5000 poll=0 | <idle>-0 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0091 s=0 pyld= | <idle>-0 scmi_rx_done: transfer_id=145 msg_id=7 protocol_id=19 seq=145 msg_type=0 | cpufreq-set-276 scmi_xfer_end: transfer_id=145 msg_id=7 protocol_id=19 seq=145 status=0 ... where the same information is being reported using different names (protocol_id= vs pt=) and even worst different bases, which is hard to read and to parse. So let us unify them, using the same naming and ordering of the fields (wherever possible) and moving all the protocol related fields to base-16 while keeping in base-10 timeouts, res_id and values, so that the new traces would be like: | cpufreq-set-274 scmi_xfer_begin: pt=13 msg_id=07 seq=0092 transfer_id=92 poll=0 | cpufreq-set-274 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0092 s=0 pyld=000000008066ab13 | cpufreq-set-274 scmi_xfer_response_wait: pt=13 msg_id=07 seq=0092 transfer_id=92 tmo_ms=5000 poll=0 | cat-256 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0092 s=0 pyld= | cat-256 scmi_rx_done: pt=13 msg_id=07 seq=0092 transfer_id=92 msg_type=0 | cpufreq-set-274 scmi_xfer_end: pt=13 msg_id=07 seq=0092 transfer_id=92 s=0 Link: https://lore.kernel.org/r/20220818132309.584042-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-08-18 21:23:09 +08:00
TP_printk("pt=%02X msg_id=%02X res_id:%u vals=%u:%u",
__entry->protocol_id, __entry->msg_id,
__entry->res_id, __entry->val1, __entry->val2)
include: trace: Add SCMI fast channel tracing All the currently defined SCMI events are meant to trace only regular SCMI transfers based on SCMI messages exchanges; SCMI transactions based on fast channels, where used, are completely invisible from the tracing point of view. Add support to trace fast channel transactions; while doing that avoid exposing full shared memory location addresses. Link: https://lore.kernel.org/r/20220704102241.2988447-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-04 18:22:39 +08:00
);
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
TRACE_EVENT(scmi_xfer_begin,
TP_PROTO(int transfer_id, u8 msg_id, u8 protocol_id, u16 seq,
bool poll),
TP_ARGS(transfer_id, msg_id, protocol_id, seq, poll),
TP_STRUCT__entry(
__field(int, transfer_id)
__field(u8, msg_id)
__field(u8, protocol_id)
__field(u16, seq)
__field(bool, poll)
),
TP_fast_assign(
__entry->transfer_id = transfer_id;
__entry->msg_id = msg_id;
__entry->protocol_id = protocol_id;
__entry->seq = seq;
__entry->poll = poll;
),
firmware: arm_scmi: Harmonize SCMI tracing message format After the recently added new scmi_msg_dump traces, the general format of the various other SCMI traces are not consistent. As an example the full traces of a simple PERF_LEVEL_SET: | cpufreq-set-276 scmi_xfer_begin: transfer_id=145 msg_id=7 protocol_id=19 seq=145 poll=0 | cpufreq-set-276 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0091 s=0 pyld=000000008066ab13 | cpufreq-set-276 scmi_xfer_response_wait: transfer_id=145 msg_id=7 protocol_id=19 seq=145 tmo_ms=5000 poll=0 | <idle>-0 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0091 s=0 pyld= | <idle>-0 scmi_rx_done: transfer_id=145 msg_id=7 protocol_id=19 seq=145 msg_type=0 | cpufreq-set-276 scmi_xfer_end: transfer_id=145 msg_id=7 protocol_id=19 seq=145 status=0 ... where the same information is being reported using different names (protocol_id= vs pt=) and even worst different bases, which is hard to read and to parse. So let us unify them, using the same naming and ordering of the fields (wherever possible) and moving all the protocol related fields to base-16 while keeping in base-10 timeouts, res_id and values, so that the new traces would be like: | cpufreq-set-274 scmi_xfer_begin: pt=13 msg_id=07 seq=0092 transfer_id=92 poll=0 | cpufreq-set-274 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0092 s=0 pyld=000000008066ab13 | cpufreq-set-274 scmi_xfer_response_wait: pt=13 msg_id=07 seq=0092 transfer_id=92 tmo_ms=5000 poll=0 | cat-256 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0092 s=0 pyld= | cat-256 scmi_rx_done: pt=13 msg_id=07 seq=0092 transfer_id=92 msg_type=0 | cpufreq-set-274 scmi_xfer_end: pt=13 msg_id=07 seq=0092 transfer_id=92 s=0 Link: https://lore.kernel.org/r/20220818132309.584042-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-08-18 21:23:09 +08:00
TP_printk("pt=%02X msg_id=%02X seq=%04X transfer_id=%X poll=%u",
__entry->protocol_id, __entry->msg_id, __entry->seq,
__entry->transfer_id, __entry->poll)
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
);
include: trace: Add new scmi_xfer_response_wait event Having a new step to trace SCMI stack while it waits for synchronous responses is useful to analyze system performance when changing waiting mode between polling and interrupt completion. Link: https://lore.kernel.org/r/20211129191156.29322-5-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-11-30 03:11:44 +08:00
TRACE_EVENT(scmi_xfer_response_wait,
TP_PROTO(int transfer_id, u8 msg_id, u8 protocol_id, u16 seq,
u32 timeout, bool poll),
TP_ARGS(transfer_id, msg_id, protocol_id, seq, timeout, poll),
TP_STRUCT__entry(
__field(int, transfer_id)
__field(u8, msg_id)
__field(u8, protocol_id)
__field(u16, seq)
__field(u32, timeout)
__field(bool, poll)
),
TP_fast_assign(
__entry->transfer_id = transfer_id;
__entry->msg_id = msg_id;
__entry->protocol_id = protocol_id;
__entry->seq = seq;
__entry->timeout = timeout;
__entry->poll = poll;
),
firmware: arm_scmi: Harmonize SCMI tracing message format After the recently added new scmi_msg_dump traces, the general format of the various other SCMI traces are not consistent. As an example the full traces of a simple PERF_LEVEL_SET: | cpufreq-set-276 scmi_xfer_begin: transfer_id=145 msg_id=7 protocol_id=19 seq=145 poll=0 | cpufreq-set-276 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0091 s=0 pyld=000000008066ab13 | cpufreq-set-276 scmi_xfer_response_wait: transfer_id=145 msg_id=7 protocol_id=19 seq=145 tmo_ms=5000 poll=0 | <idle>-0 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0091 s=0 pyld= | <idle>-0 scmi_rx_done: transfer_id=145 msg_id=7 protocol_id=19 seq=145 msg_type=0 | cpufreq-set-276 scmi_xfer_end: transfer_id=145 msg_id=7 protocol_id=19 seq=145 status=0 ... where the same information is being reported using different names (protocol_id= vs pt=) and even worst different bases, which is hard to read and to parse. So let us unify them, using the same naming and ordering of the fields (wherever possible) and moving all the protocol related fields to base-16 while keeping in base-10 timeouts, res_id and values, so that the new traces would be like: | cpufreq-set-274 scmi_xfer_begin: pt=13 msg_id=07 seq=0092 transfer_id=92 poll=0 | cpufreq-set-274 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0092 s=0 pyld=000000008066ab13 | cpufreq-set-274 scmi_xfer_response_wait: pt=13 msg_id=07 seq=0092 transfer_id=92 tmo_ms=5000 poll=0 | cat-256 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0092 s=0 pyld= | cat-256 scmi_rx_done: pt=13 msg_id=07 seq=0092 transfer_id=92 msg_type=0 | cpufreq-set-274 scmi_xfer_end: pt=13 msg_id=07 seq=0092 transfer_id=92 s=0 Link: https://lore.kernel.org/r/20220818132309.584042-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-08-18 21:23:09 +08:00
TP_printk("pt=%02X msg_id=%02X seq=%04X transfer_id=%X tmo_ms=%u poll=%u",
__entry->protocol_id, __entry->msg_id, __entry->seq,
__entry->transfer_id, __entry->timeout, __entry->poll)
include: trace: Add new scmi_xfer_response_wait event Having a new step to trace SCMI stack while it waits for synchronous responses is useful to analyze system performance when changing waiting mode between polling and interrupt completion. Link: https://lore.kernel.org/r/20211129191156.29322-5-cristian.marussi@arm.com Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-11-30 03:11:44 +08:00
);
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
TRACE_EVENT(scmi_xfer_end,
TP_PROTO(int transfer_id, u8 msg_id, u8 protocol_id, u16 seq,
firmware: arm_scmi: Use signed integer to report transfer status Currently the trace event 'scmi_xfer_end' reports the status of the transfer using the unsigned status field read from the firmware which may not be easy to interpret. It may also miss to emit any timeouts that happen in the driver resulting in emitting garbage in the status field in those scenarios. Let us use signed integer so that error values are emitted out after they are mapped from firmware error formats to standard linux error codes. While at this, also include any timeouts in the driver itself. Link: https://lore.kernel.org/r/20200609134503.55860-1-sudeep.holla@arm.com Cc: Jim Quinlan <james.quinlan@broadcom.com> Cc: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-06-09 21:45:03 +08:00
int status),
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
TP_ARGS(transfer_id, msg_id, protocol_id, seq, status),
TP_STRUCT__entry(
__field(int, transfer_id)
__field(u8, msg_id)
__field(u8, protocol_id)
__field(u16, seq)
firmware: arm_scmi: Use signed integer to report transfer status Currently the trace event 'scmi_xfer_end' reports the status of the transfer using the unsigned status field read from the firmware which may not be easy to interpret. It may also miss to emit any timeouts that happen in the driver resulting in emitting garbage in the status field in those scenarios. Let us use signed integer so that error values are emitted out after they are mapped from firmware error formats to standard linux error codes. While at this, also include any timeouts in the driver itself. Link: https://lore.kernel.org/r/20200609134503.55860-1-sudeep.holla@arm.com Cc: Jim Quinlan <james.quinlan@broadcom.com> Cc: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-06-09 21:45:03 +08:00
__field(int, status)
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
),
TP_fast_assign(
__entry->transfer_id = transfer_id;
__entry->msg_id = msg_id;
__entry->protocol_id = protocol_id;
__entry->seq = seq;
__entry->status = status;
),
firmware: arm_scmi: Harmonize SCMI tracing message format After the recently added new scmi_msg_dump traces, the general format of the various other SCMI traces are not consistent. As an example the full traces of a simple PERF_LEVEL_SET: | cpufreq-set-276 scmi_xfer_begin: transfer_id=145 msg_id=7 protocol_id=19 seq=145 poll=0 | cpufreq-set-276 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0091 s=0 pyld=000000008066ab13 | cpufreq-set-276 scmi_xfer_response_wait: transfer_id=145 msg_id=7 protocol_id=19 seq=145 tmo_ms=5000 poll=0 | <idle>-0 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0091 s=0 pyld= | <idle>-0 scmi_rx_done: transfer_id=145 msg_id=7 protocol_id=19 seq=145 msg_type=0 | cpufreq-set-276 scmi_xfer_end: transfer_id=145 msg_id=7 protocol_id=19 seq=145 status=0 ... where the same information is being reported using different names (protocol_id= vs pt=) and even worst different bases, which is hard to read and to parse. So let us unify them, using the same naming and ordering of the fields (wherever possible) and moving all the protocol related fields to base-16 while keeping in base-10 timeouts, res_id and values, so that the new traces would be like: | cpufreq-set-274 scmi_xfer_begin: pt=13 msg_id=07 seq=0092 transfer_id=92 poll=0 | cpufreq-set-274 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0092 s=0 pyld=000000008066ab13 | cpufreq-set-274 scmi_xfer_response_wait: pt=13 msg_id=07 seq=0092 transfer_id=92 tmo_ms=5000 poll=0 | cat-256 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0092 s=0 pyld= | cat-256 scmi_rx_done: pt=13 msg_id=07 seq=0092 transfer_id=92 msg_type=0 | cpufreq-set-274 scmi_xfer_end: pt=13 msg_id=07 seq=0092 transfer_id=92 s=0 Link: https://lore.kernel.org/r/20220818132309.584042-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-08-18 21:23:09 +08:00
TP_printk("pt=%02X msg_id=%02X seq=%04X transfer_id=%X s=%d",
__entry->protocol_id, __entry->msg_id, __entry->seq,
__entry->transfer_id, __entry->status)
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
);
TRACE_EVENT(scmi_rx_done,
TP_PROTO(int transfer_id, u8 msg_id, u8 protocol_id, u16 seq,
u8 msg_type),
TP_ARGS(transfer_id, msg_id, protocol_id, seq, msg_type),
TP_STRUCT__entry(
__field(int, transfer_id)
__field(u8, msg_id)
__field(u8, protocol_id)
__field(u16, seq)
__field(u8, msg_type)
),
TP_fast_assign(
__entry->transfer_id = transfer_id;
__entry->msg_id = msg_id;
__entry->protocol_id = protocol_id;
__entry->seq = seq;
__entry->msg_type = msg_type;
),
firmware: arm_scmi: Harmonize SCMI tracing message format After the recently added new scmi_msg_dump traces, the general format of the various other SCMI traces are not consistent. As an example the full traces of a simple PERF_LEVEL_SET: | cpufreq-set-276 scmi_xfer_begin: transfer_id=145 msg_id=7 protocol_id=19 seq=145 poll=0 | cpufreq-set-276 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0091 s=0 pyld=000000008066ab13 | cpufreq-set-276 scmi_xfer_response_wait: transfer_id=145 msg_id=7 protocol_id=19 seq=145 tmo_ms=5000 poll=0 | <idle>-0 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0091 s=0 pyld= | <idle>-0 scmi_rx_done: transfer_id=145 msg_id=7 protocol_id=19 seq=145 msg_type=0 | cpufreq-set-276 scmi_xfer_end: transfer_id=145 msg_id=7 protocol_id=19 seq=145 status=0 ... where the same information is being reported using different names (protocol_id= vs pt=) and even worst different bases, which is hard to read and to parse. So let us unify them, using the same naming and ordering of the fields (wherever possible) and moving all the protocol related fields to base-16 while keeping in base-10 timeouts, res_id and values, so that the new traces would be like: | cpufreq-set-274 scmi_xfer_begin: pt=13 msg_id=07 seq=0092 transfer_id=92 poll=0 | cpufreq-set-274 scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0092 s=0 pyld=000000008066ab13 | cpufreq-set-274 scmi_xfer_response_wait: pt=13 msg_id=07 seq=0092 transfer_id=92 tmo_ms=5000 poll=0 | cat-256 scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0092 s=0 pyld= | cat-256 scmi_rx_done: pt=13 msg_id=07 seq=0092 transfer_id=92 msg_type=0 | cpufreq-set-274 scmi_xfer_end: pt=13 msg_id=07 seq=0092 transfer_id=92 s=0 Link: https://lore.kernel.org/r/20220818132309.584042-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-08-18 21:23:09 +08:00
TP_printk("pt=%02X msg_id=%02X seq=%04X transfer_id=%X msg_type=%u",
__entry->protocol_id, __entry->msg_id, __entry->seq,
__entry->transfer_id, __entry->msg_type)
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
);
include: trace: Add SCMI full message tracing Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-01 01:31:34 +08:00
TRACE_EVENT(scmi_msg_dump,
include: trace: Add platform and channel instance references Add the channel and platform instance indentifier to SCMI message dump traces in order to easily associate message flows to specific transport channels. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-18 20:14:17 +08:00
TP_PROTO(int id, u8 channel_id, u8 protocol_id, u8 msg_id,
unsigned char *tag, u16 seq, int status,
void *buf, size_t len),
TP_ARGS(id, channel_id, protocol_id, msg_id, tag, seq, status,
buf, len),
include: trace: Add SCMI full message tracing Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-01 01:31:34 +08:00
TP_STRUCT__entry(
include: trace: Add platform and channel instance references Add the channel and platform instance indentifier to SCMI message dump traces in order to easily associate message flows to specific transport channels. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-18 20:14:17 +08:00
__field(int, id)
__field(u8, channel_id)
include: trace: Add SCMI full message tracing Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-01 01:31:34 +08:00
__field(u8, protocol_id)
__field(u8, msg_id)
__array(char, tag, 5)
__field(u16, seq)
__field(int, status)
__field(size_t, len)
__dynamic_array(unsigned char, cmd, len)
),
TP_fast_assign(
include: trace: Add platform and channel instance references Add the channel and platform instance indentifier to SCMI message dump traces in order to easily associate message flows to specific transport channels. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-18 20:14:17 +08:00
__entry->id = id;
__entry->channel_id = channel_id;
include: trace: Add SCMI full message tracing Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-01 01:31:34 +08:00
__entry->protocol_id = protocol_id;
__entry->msg_id = msg_id;
strscpy(__entry->tag, tag, 5);
__entry->seq = seq;
__entry->status = status;
__entry->len = len;
memcpy(__get_dynamic_array(cmd), buf, __entry->len);
),
include: trace: Add platform and channel instance references Add the channel and platform instance indentifier to SCMI message dump traces in order to easily associate message flows to specific transport channels. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20230118121426.492864-9-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2023-01-18 20:14:17 +08:00
TP_printk("id=%d ch=%02X pt=%02X t=%s msg_id=%02X seq=%04X s=%d pyld=%s",
__entry->id, __entry->channel_id, __entry->protocol_id,
__entry->tag, __entry->msg_id, __entry->seq, __entry->status,
include: trace: Add SCMI full message tracing Add a distinct trace event to dump full SCMI message headers and payloads. Link: https://lore.kernel.org/r/20220630173135.2086631-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2022-07-01 01:31:34 +08:00
__print_hex_str(__get_dynamic_array(cmd), __entry->len))
);
include: trace: Add SCMI header with trace events Adding trace events would help to measure the speed of the communication channel. It can be also potentially used helpful during investigation of some issues platforms which use different transport layer. Update also MAINTAINERS file with information that the new trace events are maintained. Suggested-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-17 21:43:44 +08:00
#endif /* _TRACE_SCMI_H */
/* This part must be outside protection */
#include <trace/define_trace.h>
Reference in New Issue Copy Permalink