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>
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>
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>
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>
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>
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>
Cristian Marussi