aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-12-23platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCsHenning Schild1-21/+33
Siemens industrial PCs unfortunately can not always be properly identified the way we used to. An earlier commit introduced code that allows proper identification without looking at DMI strings that could differ based on product branding. Switch over to that proper way and revert commits that used to collect the machines based on unstable strings. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Fixes: e8796c6c69d1 ("platform/x86: pmc_atom: Add Siemens CONNECT ...") Fixes: f110d252ae79 ("platform/x86: pmc_atom: Add Siemens SIMATIC ...") Fixes: ad0d315b4d4e ("platform/x86: pmc_atom: Add Siemens SIMATIC ...") Tested-by: Michael Haener <michael.haener@siemens.com> Signed-off-by: Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20211213120502.20661-5-henning.schild@siemens.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCsHenning Schild3-0/+240
This driver adds initial support for several devices from Siemens. It is based on a platform driver introduced in an earlier commit. One of the supported machines does access a GPIO pin to enable the watchdog. Here we poke GPIO memory because pinctrl does not come up. Signed-off-by: Henning Schild <henning.schild@siemens.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20211213120502.20661-4-henning.schild@siemens.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23leds: simatic-ipc-leds: add new driver for Siemens Industial PCsHenning Schild5-0/+221
This driver adds initial support for several devices from Siemens. It is based on a platform driver introduced in an earlier commit. One of the supported machines has GPIO connected LEDs, here we poke GPIO memory directly because pinctrl does not come up. Signed-off-by: Henning Schild <henning.schild@siemens.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20211213120502.20661-3-henning.schild@siemens.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23platform/x86: simatic-ipc: add main driver for Siemens devicesHenning Schild5-0/+292
This mainly implements detection of these devices and will allow secondary drivers to work on such machines. The identification is DMI-based with a vendor specific way to tell them apart in a reliable way. Drivers for LEDs and Watchdogs will follow to make use of that platform detection. There is also some code to allow secondary drivers to find GPIO memory, that needs to be in place because the pinctrl drivers do not come up. Signed-off-by: Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20211213120502.20661-2-henning.schild@siemens.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23platform/x86/intel: Remove X86_PLATFORM_DRIVERS_INTELAndy Shevchenko2-16/+1
While introduction of this menu brings a nice view in the configuration tools, it brought more issues than solves, i.e. it prevents to locate files in the intel/ subfolder without touching non-related Kconfig dependencies elsewhere. Drop X86_PLATFORM_DRIVERS_INTEL altogether. Note, on x86 it's enabled by default and it's quite unlikely anybody wants to disable all of the modules in this submenu. Fixes: 8bd836feb6ca ("platform/x86: intel_skl_int3472: Move to intel/ subfolder") Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211222194941.76054-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23platform/x86: system76_acpi: Guard System76 EC specific functionalityTim Crawford1-28/+30
Certain functionality or its implementation in System76 EC firmware may be different to the proprietary ODM EC firmware. Introduce a new bool, `has_open_ec`, to guard our specific logic. Detect the use of this by looking for a custom ACPI method name used in System76 firmware. Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211222185154.4560-1-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23platform/x86/intel: Remove X86_PLATFORM_DRIVERS_INTELAndy Shevchenko2-16/+1
While introduction of this menu brings a nice view in the configuration tools, it brought more issues than solves, i.e. it prevents to locate files in the intel/ subfolder without touching non-related Kconfig dependencies elsewhere. Drop X86_PLATFORM_DRIVERS_INTEL altogether. Note, on x86 it's enabled by default and it's quite unlikely anybody wants to disable all of the modules in this submenu. Fixes: 8bd836feb6ca ("platform/x86: intel_skl_int3472: Move to intel/ subfolder") Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211222194941.76054-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23platform/x86: system76_acpi: Guard System76 EC specific functionalityTim Crawford1-28/+30
Certain functionality or its implementation in System76 EC firmware may be different to the proprietary ODM EC firmware. Introduce a new bool, `has_open_ec`, to guard our specific logic. Detect the use of this by looking for a custom ACPI method name used in System76 firmware. Signed-off-by: Tim Crawford <tcrawford@system76.com> Link: https://lore.kernel.org/r/20211222185154.4560-1-tcrawford@system76.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23gpio: regmap: Switch to use fwnode instead of of_nodeAndy Shevchenko1-5/+1
GPIO library now accepts fwnode as a firmware node, so switch the driver to use it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-12-23gpio: tegra186: Add support for Tegra241Akhil R1-0/+52
Extend the existing Tegra186 GPIO controller driver with support for the GPIO controller found on Tegra241 (Grace). While the programming model remains the same, the number of pins has slightly changed. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-12-23dt-bindings: gpio: Add Tegra241 supportAkhil R1-0/+42
Add the port definitions for the main and AON GPIO controllers found on Tegra241 (Grace). Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-12-23gpio: brcmstb: Use local variable to access OF nodeAndy Shevchenko1-1/+1
We already have a local variable that contains a copy of OF node pointer. Use it instead of dereferencing it again from struct device. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-12-23dt-bindings: crypto: convert Qualcomm PRNG to yamlDavid Heidelberg2-19/+43
Convert Qualcomm PRNG documentation to yaml format. Signed-off-by: David Heidelberg <david@ixit.cz> Acked-By: Vinod Koul <vkoul@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211220184355.86582-1-david@ixit.cz
2021-12-23dt-bindings: msm: disp: remove bus from dpu bindingsDavid Heidelberg1-4/+1
Driver and dts has been already adjusted and bus moved out of dpu, let's update also dt-bindings. Fixes warnings as: arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: mdss @ae00000: clock-names: ['iface', 'core'] is too short From schema: Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml Ref: https://lore.kernel.org/all/20210803101657.1072358-1-dmitry.baryshkov@linaro.org/ Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211220184220.86328-1-david@ixit.cz
2021-12-23dt-binding: soc: qcom: convert Qualcomm Command DB documentation to yamlDavid Heidelberg2-37/+46
Convert Qualcomm Command DB documentation into yaml format. Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211218184617.19923-1-david@ixit.cz
2021-12-23dt-binding: soc: qcom: convert rmtfs documentation to yamlDavid Heidelberg2-51/+53
Convert Qualcomm Remote File System Memory binding to the yaml format. Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211218182816.17151-1-david@ixit.cz
2021-12-23powercap/drivers/dtpm: Reduce trace verbosityDaniel Lezcano1-3/+3
The traces when registering a powerzone is at the pr_info level and should be changed to pr_debug as requested by Greg-KH. Cc: Greg KH <gregkh@linuxfoundation.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lkml.kernel.org/r/YGAnRx8SiZHFPpY6@kroah.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20211123101601.2433340-2-daniel.lezcano@linaro.org
2021-12-23powercap/drivers/dtpm: Remove unused function definitionDaniel Lezcano1-2/+0
The dtpm.h header file is exporting a function which is not implemented neither needed. Remove it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20211123101601.2433340-1-daniel.lezcano@linaro.org
2021-12-23ext4: fix i_version handling on remountLukas Czerner1-25/+18
i_version mount option is getting lost on remount. This is because the 'i_version' mount option differs from the util-linux mount option 'iversion', but it has exactly the same functionality. We have to specifically notify the vfs that this is what we want by setting appropriate flag in fc->sb_flags. Fix it and as a result we can remove *flags argument from __ext4_remount(); do the same for __ext4_fill_super(). In addition set out to deprecate ext4 specific 'i_version' mount option in favor or 'iversion' by kernel version 5.20. Signed-off-by: Lukas Czerner <lczerner@redhat.com> Fixes: cebe85d570cf ("ext4: switch to the new mount api") Link: https://lore.kernel.org/r/20211222104517.11187-2-lczerner@redhat.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-12-23ext4: remove lazytime/nolazytime mount options handled by MS_LAZYTIMELukas Czerner1-11/+2
The lazytime and nolazytime mount options were added temporarily back in 2015 with commit a26f49926da9 ("ext4: add optimization for the lazytime mount option"). It think it has been enough time for the util-linux with lazytime support to get widely used. Remove the mount options. Signed-off-by: Lukas Czerner <lczerner@redhat.com> Link: https://lore.kernel.org/r/20211222104517.11187-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-12-23ext4: don't fail remount if journalling mode didn't changeLukas Czerner1-5/+9
Switching to the new mount api introduced inconsistency in how the journalling mode mount option (data=) is handled during a remount. Ext4 always prevented changing the journalling mode during the remount, however the new code always fails the remount when the journalling mode is specified, even if it remains unchanged. Fix it. Signed-off-by: Lukas Czerner <lczerner@redhat.com> Reported-by: Heiner Kallweit <hkallweit1@gmail.com> Fixes: cebe85d570cf ("ext4: switch to the new mount api") Link: https://lore.kernel.org/r/20211220152657.101599-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-12-23block: drop needless assignment in set_task_ioprio()Lukas Bulwahn1-4/+2
Commit 5fc11eebb4a9 ("block: open code create_task_io_context in set_task_ioprio") introduces a needless assignment 'ioc = task->io_context', as the local variable ioc is not further used before returning. Even after the further fix, commit a957b61254a7 ("block: fix error in handling dead task for ioprio setting"), the assignment still remains needless. Drop this needless assignment in set_task_ioprio(). This code smell was identified with 'make clang-analyzer'. Fixes: 5fc11eebb4a9 ("block: open code create_task_io_context in set_task_ioprio") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20211223125300.20691-1-lukas.bulwahn@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-12-23spi: pxa2xx: Propagate firmware nodeAndy Shevchenko1-2/+1
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211222155739.7699-3-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23spi: dw: Propagate firmware nodeAndy Shevchenko1-2/+2
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20211222155739.7699-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23spi: dln2: Propagate firmware nodeAndy Shevchenko1-1/+3
Propagate firmware node by using a specific API call, i.e. device_set_node(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211222155739.7699-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: codec: tlv320adc3xxx: Fix missing clk_disable_unprepare() on error in adc3xxx_i2c_probe()Yang Yingliang1-6/+12
Fix the missing clk_disable_unprepare() before return from adc3xxx_i2c_probe() in the error handling case. Fixes: e9a3b57efd28 ("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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: dt-bindings: aiu: spdif-dit: add missing sound-name-prefix propertyAlexander Stein1-0/+5
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.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: dt-bindings: spdif-dit: add missing sound-name-prefix propertyAlexander Stein1-0/+5
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.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Intel: hda: Use DEBUG log level for optional printsPeter Ujfalusi1-8/+10
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: debug: Use DEBUG log level for optional printsPeter Ujfalusi1-8/+12
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Add clarifying comments for sof_core_debug and DSP dump flagsPeter Ujfalusi1-2/+4
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Rename snd_sof_get_status() and add kernel log level parameterPeter Ujfalusi6-29/+40
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: dsp_arch_ops: add kernel log level parameter for oops and stackPeter Ujfalusi3-28/+35
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: ops: Always print DSP Panic message but use different messagePeter Ujfalusi1-8/+11
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoc: SOF: core: Update the FW boot state transition diagramPeter Ujfalusi1-26/+26
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: pm: Force DSP off on suspend in BOOT_FAILED state alsoPeter Ujfalusi1-3/+4
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Set SOF_FW_BOOT_FAILED in case we have failure during bootPeter Ujfalusi3-1/+4
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: ipc: Only allow sending of an IPC in SOF_FW_BOOT_COMPLETE statePeter Ujfalusi1-1/+1
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Rename 'enum snd_sof_fw_state' to 'enum sof_fw_state'Peter Ujfalusi3-5/+5
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Move the definition of enum snd_sof_fw_state to global headerPeter Ujfalusi2-11/+22
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Introduce new firmware state: SOF_FW_BOOT_READY_OKPeter Ujfalusi4-4/+7
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Introduce new firmware state: SOF_FW_CRASHEDPeter Ujfalusi5-1/+12
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Add a 'message' parameter to snd_sof_dsp_dbg_dump()Peter Ujfalusi5-16/+23
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Add 'non_recoverable' parameter to snd_sof_dsp_panic()Peter Ujfalusi9-20/+66
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Use sof_debug_check_flag() instead of sof_core_debug directlyPeter Ujfalusi4-12/+11
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: core: Add simple wrapper to check flags in sof_core_debugPeter Ujfalusi2-0/+17
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: Intel: hda-loader: Avoid re-defining the HDA_FW_BOOT_ATTEMPTSPeter Ujfalusi2-2/+1
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23ASoC: SOF: ops: Use dev_warn() if the panic offsets differPeter Ujfalusi1-8/+13
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.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-12-23mtd: spi-nor: micron-st: write 2 bytes when disabling Octal DTR modePratyush Yadav1-5/+17
The Octal DTR configuration is stored in the CFR0V register. This register is 1 byte wide. But 1 byte long transactions are not allowed in 8D-8D-8D mode. The next byte address contains the CFR1V register, which contains the number of dummy cycles. This is very fortunate since the enable path changes the value of this register. Reset the value to its default when disabling Octal DTR mode. This way, both changes to the flash state made when enabling can be reverted in one single transaction. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210531181757.19458-4-p.yadav@ti.com
2021-12-23mtd: spi-nor: spansion: write 2 bytes when disabling Octal DTR modePratyush Yadav1-5/+13
The Octal DTR configuration is stored in the CFR5V register. This register is 1 byte wide. But 1 byte long transactions are not allowed in 8D-8D-8D mode. Since the next byte address does not contain any register, it is safe to write any value to it. Write a 0 to it. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20210531181757.19458-3-p.yadav@ti.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.