- 24 Dec, 2021 5 commits
-
-
Pierre-Louis Bossart authored
Overloading the tx_mask with a linear value is asking for trouble and only works because the codec_dai hw_params() is called before the cpu_dai hw_params(). Move to the more generic set_stream() API to pass the hdac_stream information. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211224021034.26635-6-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
The HDAudio ASoC support relies on the set_tdm_slots() helper to store the HDaudio stream tag in the tx_mask. This only works because of the pre-existing order in soc-pcm.c, where the hw_params() is handled for codec_dais *before* cpu_dais. When the order is reversed, the stream_tag is used as a mask in the codec fixup functions: /* fixup params based on TDM slot masks */ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && codec_dai->tx_mask) soc_pcm_codec_params_fixup(&codec_params, codec_dai->tx_mask); As a result of this confusion, the codec_params_fixup() ends-up generating bad channel masks, depending on what stream_tag was allocated. We could add a flag to state that the tx_mask is really not a mask, but it would be quite ugly to persist in overloading concepts. Instead, this patch suggests a more generic get/set 'stream' API based on the existing model for SoundWire. We can expand the concept to store 'stream' opaque information that is specific to different DAI types. In the case of HDAudio DAIs, we only need to store a stream tag as an unsigned char pointer. The TDM rx_ and tx_masks should really only be used to store masks. Rename get_sdw_stream/set_sdw_stream callbacks and helpers as get_stream/set_stream. No functionality change beyond the rename. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20211224021034.26635-5-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
This patch provides both a simplification of the suspend flows and a better balanced operation during suspend/resume transition, as part of the transition of Sound Open Firmware (SOF) to dynamic pipelines: the DSP resources are only enabled when required instead of enabled on startup. The exiting code relies on a convoluted way of dealing with suspend signals. Since there is no .suspend DAI callback, we used the component .suspend and marked all the component DAI dmas as 'suspended'. The information was used in the .prepare stage to differentiate resume operations from xrun handling, and only reinitialize SHIM registers and DMA in the former case. While this solution has been working reliably for about 2 years, there is a much better solution consisting in trapping the TRIGGER_SUSPEND in the .trigger DAI ops. The DMA is still marked in the same way for the .prepare op to run, but in addition the callbacks sent to DSP firmware are now balanced. Normal operation: hw_params -> intel_params_stream hw_free -> intel_free_stream suspend -> intel_free_stream prepare -> intel_params_stream This balanced operation was not required with existing SOF firmware relying on static pipelines instantiated at every boot. With the on-going transition to dynamic pipelines, it's however a requirement to keep the use count for the DAI widget balanced across all transitions. The component suspend is not removed but instead modified to deal with a corner case: when a substream is PAUSED, the ALSA core does not throw the TRIGGER_SUSPEND. This is problematic since the refcount for all pipelines and widgets is not balanced, leading to issues on resume. The trigger callback keeps track of the 'paused' state with a new flag, which is tested during the component suspend called later to release the remaining DSP resources. These resources will be re-enabled in the .prepare step. The IPC used in the TRIGGER_SUSPEND to release DSP resources is not a problem since the BE dailink is already marked as non-atomic. Co-developed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20211224021034.26635-4-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
We don't really need to pass a substream to the callback, we only need the direction. No functionality change, only simplification to enable improve suspend with paused streams. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20211224021034.26635-3-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
We have a helper, use it to simplify widget lookup Suggested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211224021034.26635-2-yung-chuan.liao@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 23 Dec, 2021 31 commits
-
-
Mark Brown authored
Merge series from Stephan Gerhold <stephan@gerhold.net>: Some sound card setups might require extra pin switches to allow turning off certain audio components. simple-card supports this already using the "pin-switches" and "widgets" device tree property. This series makes it possible to use the same properties for the Qcom sound cards. To implement that, the function that parses the "pin-switches" property in simple-card-utils.c is first moved into the ASoC core. Then two simple function calls are added to the common Qcom sound card DT parser. Finally there is a small patch for the msm8916-wcd-analog codec to make it possible to model sound card setups used in some MSM8916 smartphones. (See PATCH 2/4 for an explanation of some real example use cases.) Using pin switches rather than patching codec drivers with switches was originally suggested by Mark Brown on a patch for the tfa989x codec: https://lore.kernel.org/alsa-devel/YXaMVHo9drCIuD3u@sirena.org.uk/
-
Stephan Gerhold authored
The analog codec has separate output paths for the left headphone channel (HPH_L) and the right headphone channel (HPH_R). While they are usually used together for actual headphones output, some devices also have an analog speaker amplifier connected to one of the headphone channels. To allow modelling that properly (and to avoid powering on the unneeded output path), HPH_L and HPH_R should be represented by separate outputs rather than a shared HEADPHONE output that always activates both paths. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20211214142049.20422-5-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
Use the DT helpers in the ASoC core to parse the "pin-switches" and "widgets" properties from the device tree. This allows adding extra mixers to disable e.g. an extra speaker amplifier that would be normally powered on automatically because it is connected to a shared output pin. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20211214142049.20422-4-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
Some sound card setups might require extra pin switches to allow turning off certain audio components. There are two real examples for this in smartphones/tablets based on MSM8916: 1. Analog speaker amplifiers connected to headphone outputs. The MSM8916 analog codec does not have a separate "Line Out" port so some devices have an analog speaker amplifier connected to one of the headphone outputs. A pin switch is necessary to allow playback on headphones without also activating the speaker. 2. External speaker codec also used as earpiece. Some smartphones have two front-facing (stereo) speakers that can be also configured to act as an earpiece during voice calls. A pin switch is needed to allow disabling the second speaker during voice calls. There are existing bindings that allow setting up such pin switches in simple-card.yaml. Document the same for Qcom sound cards. One variant of example 1 above is added to the examples in the DT schema: There is an analog speaker amplifier connected to the HPH_R (right headphone channel) output. Adding a "Speaker" pin switch and widget allows turning off the speaker when audio should be only played via the connected headphones. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211214142049.20422-3-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Stephan Gerhold authored
The ASoC core already has several helpers to parse card properties from the device tree. Move the parsing code for "pin-switches" from simple-card-utils to a shared snd_soc_of_parse_pin_switches() function so other drivers can also use it to set up pin switches configured in the device tree. Cc: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20211214142049.20422-2-stephan@gerhold.netSigned-off-by: Mark Brown <broonie@kernel.org>
-
Tzung-Bi Shih authored
The of_parse_phandle() document: >>> Use of_node_put() on it when done. The driver didn't call of_node_put(). Fixes the leak. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20211214040028.2992627-1-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Alexander Stein <alexander.stein@mailbox.org>: Following up [1] here are more fix for missing sound-name-prefix properties in the arch/arm64/boot/dts/amlogic/ subtree. [1] https://www.spinics.net/lists/devicetree/msg466125.html
-
Mark Brown authored
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: this series will improve how we are tracking the firmware's state to be able to avoid communication with it when it is not going to answer due to a panic and we will attempt to force power cycle the DSP to recover at the next runtime suspend time. The state handling brings in other improvements on the way the kernel reports errors and DSP panics to reduce the printed lines for normal users, but at the same time allowing developers (or for bug reports) to have more precise information available to track down the issue. We can now place messages easily in the correct debug level and not bound to the static ERROR for some of the print chains, causing excess amount or partial information to be printed, confusing users and machines (CI). I would have prefered to split this series up, but it was developed together to achieve a single goal to reduce the noise, but also provide the details we need to be able to rootcause issues.
-
Yang Yingliang authored
Fix the missing clk_disable_unprepare() before return from adc3xxx_i2c_probe() in the error handling case. Fixes: e9a3b57e ("ASoC: codec: tlv320adc3xxx: New codec driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20211223082212.3342184-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alexander Stein authored
This is used in meson-gx. Add the property to the binding. This fixes the dtschema warning: audio-controller@5400: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <alexander.stein@mailbox.org> Link: https://lore.kernel.org/r/20211223122434.39378-4-alexander.stein@mailbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alexander Stein authored
This is used in meson-axg, meson-g12 and meson-gx. Add the property to the binding. This fixes the dtschema warning: audio-codec-0: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <alexander.stein@mailbox.org> Link: https://lore.kernel.org/r/20211223122434.39378-3-alexander.stein@mailbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
If the user requested to see all dumps (even the optional ones) then use KERN_DEBUG level for the optional dumps as they are only for debugging purposes. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-21-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
If the user requested to see all dumps (even the optional ones) then use KERN_DEBUG level for the optional dumps as they are only for debugging purposes. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-20-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Update the comment for the global SOF level debug flags and add one for the flags used to control the DSP dump functionality. Document the expected behavior when the SOF_DBG_DUMP_OPTIONAL is passed for the DSP dump: Only print the dump if SOF_DBG_PRINT_ALL_DUMPS is set Print must use KERN_DEBUG log level Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-19-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
The snd_sof_get_status() is not the best name for a function which in fact is tasked to print out DSP oops and stack. Rename it to sof_print_oops_and_stack(). At the same time add a new parameter to specify the desired kernel log level to be used for the prints. When updating the users of the function, pass KERN_ERR for now to make sure that there is no functional change happens. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-18-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
To allow custom log level to be used for the DSP oops and stack print, add a kernel log level parameter to the two ops. Modify the xtensa oops and stack functions tom use this new log level parameter. Pass KER_ERR from snd_sof_get_status() to make sure that there is no functional change with this new parameter. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-17-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Never suppress the DSP panic dump as it is always originates from an assert() or panic() call within the firmware. Use different message for DSP panics when there will be recovery attempt going to be done compared to a definitive DSP panic. Suggested-by: Chao Song <chao.song@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Chao Song <chao.song@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-16-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Update the state flow diagram to reflect the current implementation. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-15-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Try to force the DSP to be turned off next time if the fw_state is either CRASHED or BOOT_FAILED when a suspend happens in order to attempt a clean boot to recover. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-14-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Change the fw_state to SOF_FW_BOOT_FAILED if we encountered an error during booting the firmware. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-13-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
If the state of the firmware is not BOOT_COMPLETE, it means that the firmware is not functioning, thus it is not capable of handling IPC messages. Do not try to send IPC if the state is not BOOT_COMPLETE Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-12-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Since there is nothing SND about the firmware state, rename the enum from `snd_sof_fw_state` to simply `sof_fw_state` 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> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Link: https://lore.kernel.org/r/20211223113628.18582-11-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Move the enum snd_sof_fw_state to include/sound/sof.h to be accessible outside of the core SOF stack. 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> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Link: https://lore.kernel.org/r/20211223113628.18582-10-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
The SOF_FW_BOOT_READY_OK fw_state indicates that the boot ready message has been received and there were no errors found. The SOF_FW_BOOT_COMPLETE state will be reached after the snd_sof_dsp_post_fw_run() completes without error. 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> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Link: https://lore.kernel.org/r/20211223113628.18582-9-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
The SOF_FW_CRASHED state is meant to indicate the unfortunate case when the firmware has crashed after a successful boot. IPC tx timeout is not treated as indication of a firmware crash as it tends to happen regularly while the firmware is operational. 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> Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com> Link: https://lore.kernel.org/r/20211223113628.18582-8-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
When snd_sof_dsp_dbg_dump() is called we have an explanatory message to give some hint on the reason why we have the dump on the caller level. Pass this message to snd_sof_dsp_dbg_dump() and handle the print according to the dump rules. This way we can finally print information on the HDA boot iteration if all dumps are enabled. 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-7-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Some platforms use retries during firmware boot to overcome DSP startup issues. In these cases we might receive a DSP panic message which should not be treated as fatal if it happens during boot. Pass this information to snd_sof_dsp_panic() and omit the panic print if it is not fatal or the user does not want to see all dumps. 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-6-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
The sof_debug_check_flag() is available for checking flags set in sof_core_debug. sof_core_debug can be marked static in core.c 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-5-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
The sof_debug_check_flag() can be used to check a flag or a combination of them in sof_core_debug. 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-4-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
HDA_FW_BOOT_ATTEMPTS is defined in hda.h, do not define it again locally in hda-loader.c At the same time correct the indentation for the define in hda.h 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-3-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Peter Ujfalusi authored
Catch the cases when the stored sdev->dsp_oops_offset and the offset received via the panic message differs and print a warning, but keep using the dsp_oops_offset for the oops query. 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> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20211223113628.18582-2-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 22 Dec, 2021 4 commits
-
-
Vincent Knecht authored
Don't use enums for DACL/DACR Signal Invert controls, and change them into a stereo "DAC Signal Invert Switch" control. Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20211222135403.2991657-1-vincent.knecht@mailoo.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alexander Stein authored
This is used in meson-sm1 and meson-g12 .dtsi. Add the property to the binding. This fixes the dtschema warning: audio-controller@740: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <alexander.stein@mailbox.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211218143423.18768-3-alexander.stein@mailbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alexander Stein authored
This is used in meson-gxl and meson-g12-common .dtsi. Add the property to the binding. This fixes the dtschema warning: audio-controller@32000: 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <alexander.stein@mailbox.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211218143423.18768-2-alexander.stein@mailbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alexander Stein authored
name-prefix.txt does not exist anymore, just reference the schema instead. Signed-off-by: Alexander Stein <alexander.stein@mailbox.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211218143423.18768-1-alexander.stein@mailbox.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-