- 23 Dec, 2021 19 commits
-
-
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>
-
- 21 Dec, 2021 11 commits
-
-
Vincent Knecht authored
AK4375 is a 32-bit stereo DAC with headphones amplifier. There's no documentation for it on akm.com, and only a brief datasheet can be found floating on the internets [1]. Thanks to Oriane BAYERD <obayerd@eurocomposant.fr> for finally answering my inquiries through akm.com, if only to tell me that this chip is EOL following AKM factory burning in october 2020 and thus no detailed documentation is available anymore... AK4331 is advertised [2] as pin and register compatible with AK4375 so some scraps of its datasheet were used and this driver might be used as a base for it, but this is totally untested. So this driver is mainly based on downstream code [3] and [4] by Hu Jin from AKM (no known email). Tested on msm8916-alcatel-idol347 and msm8939-alcatel-idol3, which both use PLL driven clock with bypass of SRC (sample rate converter), so only this setup is supported for now. [1] https://datasheetspdf.com/pdf-file/1400317/AKM/AK4375A/1 [2] https://www.akm.com/content/dam/documents/products/audio/audio-dac/ak4331ecb/ak4331ecb-en-datasheet.pdf [3] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/alcatel-idol347/sound/soc/codecs/idol347/ak4375.c [4] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/alcatel-idol347/sound/soc/codecs/ak4375.cSigned-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20211220193725.2650356-2-vincent.knecht@mailoo.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Vincent Knecht authored
AK4375 is an audio DAC with headphones amplifier controlled via I2C. Add simple device tree bindings that describe how to set it up. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20211220193725.2650356-1-vincent.knecht@mailoo.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Lad Prabhakar authored
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). While at it also drop "r_irq" member from struct bcm_i2s_priv as there are no users of it. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211221170100.27423-3-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Lad Prabhakar authored
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20211221170100.27423-2-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ajit Kumar Pandey authored
Remove duplicate depends on statement in Kconfig file. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20211221171912.237792-1-AjitKumar.Pandey@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dan Carpenter authored
This code frees "graph" and then dereferences to save the error code. Save the error code first and then use gotos to unwind the allocation. Fixes: 59716aa3 ("ASoC: qdsp6: Fix an IS_ERR() vs NULL bug") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211217150007.GB16611@kiliSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
cppcheck warning: sound/soc/sof/amd/acp.c:222:9: warning: Identical condition and return expression 'ret', return value is always 0 [identicalConditionAfterEarlyExit] return ret; ^ sound/soc/sof/amd/acp.c:213:6: note: If condition 'ret' is true, the function will return/exit if (ret) ^ sound/soc/sof/amd/acp.c:222:9: note: Returning identical expression 'ret' return ret; ^ Just return 0; on success. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Link: https://lore.kernel.org/r/20211221165802.236843-1-AjitKumar.Pandey@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Osipenko authored
Remove non-existent properties from the example of the binding. These properties were borrower from the old txt binding, but they were never used in practice and aren't documented in the new binding. They aren't reported by the binding checker because dtschema needs extra patch that hasn't been upstreamed yet to make unevaluatedProperties work properly. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211216160229.17049-1-digetx@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ajit Kumar Pandey authored
SOF machines support different codec end points and hence required different topologies configuration. Update tplg filename in machine struct to load different topology files for SOF machines. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Reviewed-by: Curtis Malainey <curtis@malainey.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20211221161814.236318-3-AjitKumar.Pandey@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ajit Kumar Pandey authored
We need to support sof audio on different variants of Google boards. Add new entry in dmi table to enable SOF flag on Google chrome boards. Also add newer machines to sof_machines list with codecs and amps acpi id check to register sof sound cards on different variants. Signed-off-by: Ajit Kumar Pandey <AjitKumar.Pandey@amd.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@intel.com> Link: https://lore.kernel.org/r/20211221161814.236318-2-AjitKumar.Pandey@amd.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: This patch-set tries to use dev_err_probe() helper function instead of manual dev_err() code. I hope ASoC will be more clean code by this patch-set.
-
- 20 Dec, 2021 6 commits
-
-
Tzung-Bi Shih authored
Eliminates error messages if snd_soc_register_card() failed. Kernel emits messages if device probe error anyway. This is mainly for removing the following error messages during boot. >>> snd_soc_register_card fail -517 Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20211220093408.207206-1-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ricard Wanderlof authored
New codec driver for Texas Instruments TLV320ADC3001 and TLV320ADC3101 audio ADCs. Signed-off-by: Ricard Wanderlof <ricardw@axis.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2112151801370.27889@lap5cg0092dnk.se.axis.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ricard Wanderlof authored
DT bindings for Texas Instruments TLV320ADC3001 and TLV320ADC3101 audio ADCs. Signed-off-by: Ricard Wanderlof <ricardw@axis.com> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2112151759170.27889@lap5cg0092dnk.se.axis.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20211214020843.2225831-23-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20211214020843.2225831-22-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
Use the dev_err_probe() helper, instead of open-coding the same operation. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20211214020843.2225831-21-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-