diff options
author | Théo Lebrun <theo.lebrun@bootlin.com> | 2024-02-16 19:42:19 +0300 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2024-02-26 16:55:15 +0300 |
commit | e63aef9c9121e5061cbf5112d12cadc9da399692 (patch) | |
tree | 2c5126cd2a7b704a359ae75fc1ff33c299f9e277 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 0f3841a5e1152eca1a58cfbd9ceb6d311aa7e647 (diff) | |
download | linux-e63aef9c9121e5061cbf5112d12cadc9da399692.tar.xz |
spi: spi-mem: add statistics support to ->exec_op() calls
Current behavior is that spi-mem operations do not increment statistics,
neither per-controller nor per-device, if ->exec_op() is used. For
operations that do NOT use ->exec_op(), stats are increased as the
usual spi_sync() is called.
The newly implemented spi_mem_add_op_stats() function is strongly
inspired by spi_statistics_add_transfer_stats(); locking logic and
l2len computation comes from there.
Statistics that are being filled: bytes{,_rx,_tx}, messages, transfers,
errors, timedout, transfer_bytes_histo_*.
Note about messages & transfers counters: in the fallback to spi_sync()
case, there are from 1 to 4 transfers per message. We only register one
big transfer in the ->exec_op() case as that is closer to reality.
This patch is NOT touching:
- spi_async, spi_sync, spi_sync_immediate: those counters describe
precise function calls, incrementing them would be lying. I believe
comparing the messages counter to spi_async+spi_sync is a good way
to detect ->exec_op() calls, but I might be missing edge cases
knowledge.
- transfers_split_maxsize: splitting cannot happen if ->exec_op() is
provided.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216-spi-mem-stats-v2-1-9256dfe4887d@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions