aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/scripting-engines/trace-event-python.c
diff options
context:
space:
mode:
authorMark Brown <[email protected]>2024-08-22 20:19:38 +0100
committerMark Brown <[email protected]>2024-08-22 20:19:38 +0100
commitca39fab8b7bc6c5a38c48c7bdf2b3c47792af9dd (patch)
treeadc6b757a87b32b16c3e491c94bd1463a3e91d01 /tools/perf/util/scripting-engines/trace-event-python.c
parent90dc34da02aca2fe529ae1ed1822e8fc2a0d9ebc (diff)
parent61e1f74f739546415570ccc1ac14e1b26afe4705 (diff)
ASoC: grace time for DPCM cleanup
Merge series from Kuninori Morimoto <[email protected]>: As we discussed in [1], we don't need to use dpcm_playback/capture flag, so we remove it. But we have been using it for 10 years, some driver might get damage. The most likely case is that the device/driver can use both playback/capture, but have only one flag, and not using xxx_only flag. [1/3] patch indicates warning in such case. These adds grace time for DPCM cleanup. I'm not sure when dpcm_xxx will be removed, and Codec check bypass will be error, but maybe v6.12 or v6.13 ? Please check each driver by that time. Previous patch-set try to check both CPU and Codec in DPCM, but we noticed that there are some special DAI which we can't handle today [2]. So I will escape it in this patch-set. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions