linux.git/sound/soc/sof/loader.c, branch v5.16 Linux kernel source tree Merge tag 'v5.15-rc6' into asoc-5.16 2021-10-18T12:50:42+00:00 Mark Brown broonie@kernel.org 2021-10-18T12:50:42+00:00 b8f3b564937c1f3529bc4897cc41c5d95d2cdbe9 Linux 5.15-rc6 
Linux 5.15-rc6
ASoC: SOF: prepare code to allocate IPC messages in fw_ready 2021-10-08T12:51:16+00:00 Rander Wang rander.wang@intel.com 2021-10-08T09:38:36+00:00 febf5da81ea80fa01e141e3ad35526865681418b The fixed maximum size of IPC message does not allow for large transfers, e.g. for filter data. Currently such messages will be divided into smaller pieces and sent to firmware in multiple chunks. For future IPC, this strategy is not suitable. The maximum IPC message size is limited by host box size which can be known when firmware is ready, so the fw_ready callback can allocate IPC messages with platform-specific sizes instead of the current fixed-size. To be compatible with released firmware, current platforms will still use SOF_IPC_MSG_MAX_SIZE. For future platforms, there will be a new fw_ready function and the platform-specific allocation will take place there. Signed-off-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <bard.liao@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Message-Id: <20211008093836.28210-1-peter.ujfalusi@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> 
The fixed maximum size of IPC message does not allow for large
transfers, e.g. for filter data. Currently such messages will
be divided into smaller pieces and sent to firmware in multiple
chunks. For future IPC, this strategy is not suitable.

The maximum IPC message size is limited by host box size which
can be known when firmware is ready, so the fw_ready callback
can allocate IPC messages with platform-specific sizes instead
of the current fixed-size.

To be compatible with released firmware, current platforms will
still use SOF_IPC_MSG_MAX_SIZE. For future platforms, there will
be a new fw_ready function and the platform-specific allocation
will take place there.

Signed-off-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Message-Id: <20211008093836.28210-1-peter.ujfalusi@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: loader: Drop SOF_DBG_DUMP_REGS flag when firmware start fails 2021-10-07T14:45:39+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-10-06T11:06:43+00:00 f8c3ec4368df1e5051030beaeb961fd7f625d2d1 snd_sof_dsp_run() failure indicates that the DSP did not even booted up, thus asking for dumping registers at this point is not valid. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211006110645.26679-18-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
snd_sof_dsp_run() failure indicates that the DSP did not even booted up,
thus asking for dumping registers at this point is not valid.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-18-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Introduce macro to set the firmware state 2021-10-07T14:45:36+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-10-06T11:06:40+00:00 58a5c9a4aa993fe2059c1b8dbcff9bf468d722b8 Add sof_set_fw_state() macro to wrap the sdev->fw_state management to allow actions to be taken when certain state is set or when state is changing. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211006110645.26679-15-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Add sof_set_fw_state() macro to wrap the sdev->fw_state management to allow
actions to be taken when certain state is set or when state is changing.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-15-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Drop SOF_DBG_DUMP_FORCE_ERR_LEVEL and sof_dev_dbg_or_err 2021-10-07T14:45:31+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-10-06T11:06:36+00:00 23013335bc3c906e304cda507d80b8006381a4f7 The sof_dev_dbg_or_err() is only used by intel/hda.c when dumping dsp debug information. It was used to print the extended rom status in either dev_dbg (during retries) and finally with dev_err, but other lines were printed with dev_err regardless. Since we now only print the dump once, the flag and the macros is no longer needed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211006110645.26679-11-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
The sof_dev_dbg_or_err() is only used by intel/hda.c when dumping dsp
debug information.
It was used to print the extended rom status in either dev_dbg (during
retries) and finally with dev_err, but other lines were printed with
dev_err regardless.

Since we now only print the dump once, the flag and the macros is no longer
needed.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-11-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: loader: Print the DSP dump if boot fails 2021-10-07T14:45:26+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-10-06T11:06:31+00:00 247ac640739dda167a127a2ecb158595695ffd7d It can be useful to print the DSP dump from the core in case the DSP boot failed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211006110645.26679-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
It can be useful to print the DSP dump from the core in case the DSP boot
failed.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: Print the dbg_dump and ipc_dump once to reduce kernel log noise 2021-10-07T14:45:25+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-10-06T11:06:30+00:00 9ff90859b95f6c85ce2d671ecd1e95e91dbe7f15 Do not print the dump more than once to keep the kernel log cleaner in case of a firmware failure. When the DSP is rebooted due to suspend or runtime_suspend reset the flags to re-enable the dump prints. Add also a debug flag to print all dumps to get more coverage if needed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211006110645.26679-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Do not print the dump more than once to keep the kernel log cleaner in case
of a firmware failure.

When the DSP is rebooted due to suspend or runtime_suspend reset the flags
to re-enable the dump prints.

Add also a debug flag to print all dumps to get more coverage if needed.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: loader: Re-phrase the missing firmware error to avoid duplication 2021-09-16T13:01:55+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-09-16T08:53:42+00:00 25766ee44ff8db4cdf8471b587dffb28b7b9d17f In case the firmware is missing we will have the following in the kernel log: 1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2 2 | error: request firmware intel/sof/sof-tgl-h.ri failed err: -2 3 | you may need to download the firmware from https://github.com/thesofproject/sof-bin/ 4 | error: failed to load DSP firmware -2 5 | error: sof_probe_work failed err: -2 The first line is the standard, request_firmware() warning. The second and third line is printed in snd_sof_load_firmware_raw() Note that the first and second line is mostly identical. With this patch the log will be changed to: 1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2 2 | error: sof firmware file is missing, you might need to 3 | download it from https://github.com/thesofproject/sof-bin/ 4 | error: failed to load DSP firmware -2 5 | error: sof_probe_work failed err: -2 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210916085342.29993-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
In case the firmware is missing we will have the following in the kernel
log:

1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2
2 | error: request firmware intel/sof/sof-tgl-h.ri failed err: -2
3 | you may need to download the firmware from https://github.com/thesofproject/sof-bin/
4 | error: failed to load DSP firmware -2
5 | error: sof_probe_work failed err: -2

The first line is the standard, request_firmware() warning.
The second and third line is printed in snd_sof_load_firmware_raw()
Note that the first and second line is mostly identical.

With this patch the log will be changed to:
1 | Direct firmware load for intel/sof/sof-tgl-h.ri failed with error -2
2 | error: sof firmware file is missing, you might need to
3 |        download it from https://github.com/thesofproject/sof-bin/
4 | error: failed to load DSP firmware -2
5 | error: sof_probe_work failed err: -2

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210916085342.29993-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: loader: release_firmware() on load failure to avoid batching 2021-09-16T13:01:54+00:00 Marc Herbert marc.herbert@intel.com 2021-09-16T08:50:08+00:00 8a8e1813ffc35111fc0b6db49968ceb0e1615ced Invoke release_firmware() when the firmware fails to boot in sof_probe_continue(). The request_firmware() framework must be informed of failures in sof_probe_continue() otherwise its internal "batching" feature (different from caching) cached the firmware image forever. Attempts to correct the file in /lib/firmware/ were then silently and confusingly ignored until the next reboot. Unloading the drivers did not help because from their disconnected perspective the firmware had failed so there was nothing to release. Also leverage the new snd_sof_fw_unload() function to simplify the snd_sof_device_remove() function. Signed-off-by: Marc Herbert <marc.herbert@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20210916085008.28929-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Invoke release_firmware() when the firmware fails to boot in
sof_probe_continue().

The request_firmware() framework must be informed of failures in
sof_probe_continue() otherwise its internal "batching"
feature (different from caching) cached the firmware image
forever. Attempts to correct the file in /lib/firmware/ were then
silently and confusingly ignored until the next reboot. Unloading the
drivers did not help because from their disconnected perspective the
firmware had failed so there was nothing to release.

Also leverage the new snd_sof_fw_unload() function to simplify the
snd_sof_device_remove() function.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20210916085008.28929-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: SOF: loader: Use the generic ops for region debugfs handling 2021-09-15T15:25:08+00:00 Peter Ujfalusi peter.ujfalusi@linux.intel.com 2021-09-15T12:21:15+00:00 55dfc2a74d8e8d34d6f562a1e4173e711bbd916d Do not access the sdev->bar[] directly to make the code generic, use the new generic ops for handing the regions for debugfs. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Link: https://lore.kernel.org/r/20210915122116.18317-12-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> 
Do not access the sdev->bar[] directly to make the code generic, use the
new generic ops for handing the regions for debugfs.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@gmail.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20210915122116.18317-12-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>