kernel/linux.git/sound/soc/sof/debug.c, branch v6.19.11

ASoC: SOF: Remove redundant pm_runtime_mark_last_busy() calls

2025-07-04T18:28:22+00:00

pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus Acked-by: Peter Ujfalusi Link: https://patch.msgid.link/20250704075459.3222908-1-sakari.ailus@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Intel: clarify Copyright information

2024-05-06T14:59:35+00:00

For some reason a number of files included the "All rights reserved" statement. Good old copy-paste made sure this mistake proliferated. Remove the "All rights reserved" in all Intel-copyright to align with internal guidance. Reviewed-by: Cezary Rojewski Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20240503140359.259762-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: Constify local snd_sof_dsp_ops

2024-04-30T14:34:51+00:00

Merge series from Krzysztof Kozlowski : The core code does not modify the 'struct snd_sof_dsp_ops' passed via pointer in various places, so this can be made pointer to const in few places. This in turn allows few drivers to have the local (usually static) 'struct snd_sof_dsp_ops' as const which increased code safety, as it is now part of rodata. Not all drivers can be made safer that way. Intel and AMD rely on customizing that 'struct snd_sof_dsp_ops' before passing to SOF, so they won't benefit. They don't lose anything., either.

ASoC: SOF: debug: Constify local snd_sof_dsp_ops

2024-04-29T15:16:47+00:00

Constify the pointer to 'struct snd_sof_dsp_ops' to annotate that functioon does not modify pointed data. Tested-by: Pierre-Louis Bossart Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240426-n-const-ops-var-v2-1-e553fe67ae82@kernel.org Signed-off-by: Mark Brown

ASoC: SOF: debug: Handle cases when fw_lib_prefix is not set, NULL

2024-04-29T15:16:33+00:00

The firmware libraries are not supported by IPC3, the fw_lib_path is not a valid parameter and it is always NULL. Do not create the debugfs file for IPC3 at all as it is not applicable. With IPC4 some vendors/platforms might not support loadable libraries and the fw_lib_prefix is left to NULL to indicate this. Handle such case with allocating "Not supported" string. Reviewed-by: Marc Herbert Fixes: 17f4041244e6 ("ASoC: SOF: debug: show firmware/topology prefix/names") Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20240426153902.39560-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: Merge up fixes

2024-04-29T15:15:57+00:00

Some new SOF changes depend on the fixes there.

ASoC: SOF: debug: show firmware/topology prefix/names

2024-04-09T13:03:35+00:00

The SOF driver has multiple profiles to select firmware/topology prefix/names depending on the platform and ipc_type, and each of those fields can be overridden with kernel parameters. This results in some cases in confusion on what configuration is actually used in a given test. We currently log the firmware and topology names in the kernel logs, but there's been an ask to add the information in debugfs to simplify test scripts used by developers and CI. This isn't meant to be a stable ABI used by apps, changes will be allowed as needed. Closes: https://github.com/thesofproject/linux/issues/3867 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Link: https://msgid.link/r/20240408194147.28919-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: Disable pointless writes to debugfs file

2024-04-04T15:24:28+00:00

The permissions on this debugfs file are 0444 so it can't be written to. And writing to the file hasn't done anything since commit 6e9548cdb30e ("ASoC: SOF: Convert the generic IPC flood test into SOF client"). Delete the write function. Signed-off-by: Dan Carpenter Acked-by: Peter Ujfalusi Link: https://msgid.link/r/9d2477cf-25aa-4d12-818f-fdafc9aaa28a@moroto.mountain Signed-off-by: Mark Brown

ASoC: SOF: Fix runtime pm usage counter balance after fw exception

2024-02-13T14:22:57+00:00

If the retain context is enabled we will unconditionally increment the device's pm use count on each exception and when the drivers are unloaded we do not correct this (as we don't know how many times we 'prevented d3 entry'). Introduce a flag to make sure that we do not increment the use count more than once and on module unload decrement the use count if needed to balance it. Signed-off-by: Peter Ujfalusi Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://msgid.link/r/20240213114729.7055-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown

ASoC: SOF: debug: conditionally bump runtime_pm counter on exceptions

2023-05-15T01:20:57+00:00

When a firmware IPC error happens during a pm_runtime suspend, we ignore the error and suspend anyways. However, the code unconditionally increases the runtime_pm counter. This results in a confusing configuration where the code will suspend, resume but never suspend again due to the use of pm_runtime_get_noresume(). The intent of the counter increase was to prevent entry in D3, but if that transition to D3 is already started it cannot be stopped. In addition, there's no point in that case in trying to prevent anything, the firmware error is handled and the next resume will re-initialize the firmware completely. This patch changes the logic to prevent suspend when the device is pm_runtime active and has a use_count > 0. Signed-off-by: Pierre-Louis Bossart