summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorAlexander Sverdlin <alexander.sverdlin@siemens.com>2025-07-03 00:28:22 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-07-16 14:24:52 +0200
commit8ad6249c51d0ea41ad75d770178d8e4efdbc9948 (patch)
tree1b90ff923068b630ff9ebff162dc451b7a9c5b29 /tools/perf/scripts/python/stackcollapse.py
parent8282013b56059c34590ac0245c74ea7ed7642924 (diff)
eeprom: at25: convert to spi-mem API
Replace the RAW SPI accesses with spi-mem API. The latter will fall back to RAW SPI accesses if spi-mem callbacks are not implemented by a controller driver. Notable advantages: - read function now allocates a bounce buffer for SPI DMA compatibility, similar to write function; - the driver can now be used in conjunction with SPI controller drivers providing spi-mem API only, e.g. spi-nxp-fspi. - during the initial probe the driver polls busy/ready status bit for 25ms instead of giving up instantly and hoping that the FW didn't write the EEPROM Notes: - mutex_lock() has been dropped from fm25_aux_read() because the latter is only being called in probe phase and therefore cannot race with at25_ee_read() or at25_ee_write() Quick 4KB block size test with CY15B102Q 256KB F-RAM over spi_omap2_mcspi driver (no spi-mem ops provided, fallback to raw SPI inside spi-mem): OP | throughput, KB/s | change --------+-----------------------+------- write | 1717.847 -> 1656.684 | -3.6% read | 1115.868 -> 1059.367 | -5.1% The lower throughtput probably comes from the 3 messages per SPI transfer inside spi-mem instead of hand-crafted 2 messages per transfer in the former at25 code. However, if the raw SPI access is not preserved, then the driver doesn't grow from the lines-of-code perspective and subjectively could be considered even a bit simpler. Higher performance impact on the read operation could be explained by the newly introduced bounce buffer in read operation. I didn't find any explanation or guarantee, why would a bounce buffer be not needed on the read side, so I assume it's a pure luck that nobody read EEPROM into some variable on stack on an architecture where kernel stack would be not DMA-able. Cc: Michael Walle <mwalle@kernel.org> Cc: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/all/28ab8b72afee1af59b628f7389f0d7f5@kernel.org/ Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20250702222823.864803-1-alexander.sverdlin@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions