summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorMark Brown <broonie@kernel.org>2026-07-31 20:57:18 +0100
committerMark Brown <broonie@kernel.org>2026-07-31 20:57:18 +0100
commita56338f229401cfe5cd485805ef38f44dc1dd516 (patch)
treef28510f9e38c4b172e29a78db0891ec880b6e74d /tools/perf/scripts/python/stackcollapse.py
parent13dd6c1f73104512550e681df06e6912020c338b (diff)
parent34d466aaa0d533f082b35629f8fd91cb8c260296 (diff)
ASoC: SOF: Intel: Handle ACE2+ link DMA allocation restrictions
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says: We have seen cases when the delay reporting unexpectedly behaves incorrectly, counters are not counting in hardware registers under seemingly random conditions. It turned out that there are few cases that the driver must handle in order to make sure that LLP, PPLC counters are working correctly: - non-alt links must not be reset during probe - Concurrent (cross-direction) hazard: when SoundWire shares a physical link DMA stream index with HDaudio, iDisp or UAOL across the two directions, the LLP and timestamp values for the affected stream are wrong. SSP and DMIC are not affected because every DMA request from those links carries one sample block. - Sequential (playback only) hazard: once a HDaudio or iDisp link has used a playback stream index, that index cannot drive any non HDA/iDisp link in the same direction until the next controller reset (CRST#). For users the impact was not visible as the link counter issue only affected the delay reporting which already have defensive path to filter out incorrect delays and the DSP caused delay for normal PCMs are negligible to cause A/V sync issues for example. Link: https://patch.msgid.link/20260730125130.29887-1-peter.ujfalusi@linux.intel.com
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions