summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorMark Brown <broonie@kernel.org>2026-09-21 14:15:07 +0200
committerMark Brown <broonie@kernel.org>2026-09-21 14:15:07 +0200
commita124a7c33d24dff2ee4311b560424209098ea78e (patch)
treefdc2e0f08f5399575b47fb9f7bf164d4666670ce /tools/perf/scripts/python/stackcollapse.py
parent3c82e199d411af3a0fff00ca3c54baaf04abbbb3 (diff)
parent38d4b42e4a2af5066b602867042c10c699bd08ad (diff)
spi: Better specification for rx-sample-delay-ns and core parsing
Frieder Schrempf <frieder@fris.de> says: "rx-sample-delay-ns" has been a generic SPI peripheral property since it was moved to spi-peripheral-props.yaml, but the core has never looked at it, and what it is meant to describe has become blurred along the way. It was introduced in 2015 for Rockchip, to compensate "boards with high-capacitance SPI lines". The wording now in the generic schema came later, from a description of a DesignWare register, and lost its controller-specific qualifier on the way. It says what the value does to the controller, but not what a board should measure to arrive at it. Patch 1 says what the property describes. Patch 2 parses it in the core, so that a controller driver can act on it without open-coding the property name, and patch 3 converts spi-dw, its only user that reads it from the peripheral node as the binding intends. Deliberately not converted: spi-rockchip and spi-mtk-snfi read "rx-sample-delay-ns" from the *controller* node rather than the peripheral node, which contradicts the binding but is what their device trees rely on. Converting them would break those boards, so they keep their private parsing. The controller-wide default that spi-dw reads from its own node is left in place for the same reason - it lives in a different node, which is not what the core parses when it looks at a peripheral. This is groundwork for letting SPI devices declare their datasheet clock-to-output-valid time so that controllers can move their sampling point instead of forcing a lower spi-max-frequency, posted as an RFC at https://lore.kernel.org/r/20260303-fsl-qspi-rx-sampling-delay-v1-0-9326bbc492d6@kontron.de Nothing in that work is needed to read this series, and nothing here depends on it: the chip side is a separate quantity that composes with this one, which is why patch 1 spends a paragraph on keeping them apart. Link: https://patch.msgid.link/20260921-spi-sample-delay-cleanup-v2-0-b460d572fd32@kontron.de
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions