The HP ProBook 440/450 G9 and EliteBook 640/650 G9 have multiple
motherboard design and they are using different subsystem ID of audio
codec. Add the same quirk for other MBs.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220713022706.22892-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Selections can be propagated via selections, while dependencies are not.
Hence, consolidate selections under the SND_HDA_SCODEC_CS35L41 option.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220712153519.35692-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ACPI_PTR() is more harmful than helpful. For example, in this case
if CONFIG_ACPI=n, the ID table left unused which is not what we want.
Instead of adding ifdeffery or attribute here and there, drop ACPI_PTR().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220712153519.35692-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The FSR (Firmware State Register) holds the ROM state information, it does not
contain error information.
The FSR itself is a bit more complicated as well as the state depends on the
module currently in use.
The error code from ROM or the status code from the firmware is located at the
next register.
Fix the handling of the FSR in order to provide usable and human readable (in
most cases) report on the status and error.
Merge series from Daniel Baluta <daniel.baluta@oss.nxp.com>
Daniel Baluta <daniel.baluta@nxp.com>:
From: Daniel Baluta <daniel.baluta@nxp.com>
We need a way to send extra parameters to DSP firmware. In order to do
this, we introduce ext_data array at the end of ipc_stream_params.
With this new addition we can send compress parameters.
This requires SOF ABI bump.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
By mistake a developer managed to create a 'corrupted' IPC4 firmware image which
loaded fine to the DSP and after boot it sent an IPC reply before we would have
received the FW_READY message.
It turned out that the image was an IPC3 firmware and the IPC reply was the IPC3
FW_READY notification message which got understood as an IPC4 reply message due
to the difference between the two IPC mechanism.
This caused a NULL pointer dereference since the reply memory will be allocated
after the FW_READY message.
To make sure this will not bite again, skip any spurious reply messages before
the FW_READY.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
There is no need to decouple a decoupled stream twice.
Keep the decoupling in hda_link_stream_assign() only as it is going to be
executed in all cases.
Drop the outdated comment from hda_link_dma_hw_params() as well since the code
has changed around it.
We have sanity checks for byte controls and if any of the fail the locally
allocated scontrol->ipc_control_data is freed up, but not set to NULL.
On a rollback path of the error the higher level code will also try to free
the scontrol->ipc_control_data which will eventually going to lead to
memory corruption as double freeing memory is not a good thing.
Fixes: b5cee8feb1d4 ("ASoC: SOF: topology: Make control parsing IPC agnostic")
Reported-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@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/20220712130103.31514-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current implementation of probes only supports IPC3 and should not be
loaded for other IPC implementation.
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>
Link: https://lore.kernel.org/r/20220712131022.1124-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
In case of a firmware crash we force the DSP to be powered down and rebooted.
To make sure that the next boot is going to be clean, force the boot process to
skip the IMR booting and re-download the firmware.
After introducing extended parameters we need to forbid older firmware
versions to run with the current and future kernel versions.
Although in theory the communication protocol will still work the
semantics at application level are undefined. So, prevent this by
disallowing older firmwares to run with newer kernels.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-4-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Allocate memory at the end of sof_ipc_stream_params to store
snd_compr_params in order to be sent them to SOF firmware.
This will help firmware correctly configure codecs parameters.
Notice, that we use 2 bytes from the reserved pool in order to store
the extended data length. This is compatible with older FWs where
there was no extended data.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-3-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We need to extend sof_ipc_pcm_parmas with additional data in order
to send compress_params to SOF FW.
The extensions will be done at runtime so we need to dynamically
allocate pcm object of type struct sof_ipc_pcm_params.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712141531.14599-2-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Call snd_hdac_ext_stream_decouple_locked() unconditionally in
hda_link_stream_assign(), the snd_hdac_ext_stream_decouple_locked() have
internal checks to avoid re-configuring.
There is no need to call snd_hdac_ext_stream_decouple() via
hda_link_dma_params() as the stream must have been set to decoupled when
it got assigned (even if it used local condition to call
snd_hdac_ext_stream_decouple_locked()).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712131620.13365-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The comment in hda_link_dma_hw_params() is no longer valid as the dma_data
is set to NULL at system suspend as well.
Instead of rewording the comment to state the obvious: try to take the
hext_stream from the dma_data and if it is not set then assign a new one
and store it as dma_data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712131620.13365-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The FSR (Firmware State Register) can be found at offset 0 in the SRAM and
it is holding information about the state of the ROM/FW.
In case of a boot failure it can be used to get the state where the boot
process got stuck, it does not itself contains error codes as such.
The error code (or the firmware state information) is stored in the next
soft register at offset 0x4.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220712125734.30512-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
'ret' is never used. Remove it and return 0 instead.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220712123902.14696-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When an FE, typically non-atomic, is connected to an atomic BE, we
force the BE as non-atomic. There's no reason to throw a warning, this
is a perfectly fine configuration and a conversion that's required
by-design.
This removes the unconditional warnings such as
[ 12.054213] iDisp1: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
[ 12.074693] iDisp2: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
[ 12.096612] iDisp3: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
[ 12.118637] iDisp4: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
[ 12.140660] dmic01: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
[ 12.147521] dmic16k: dpcm_be_connect: FE is nonatomic but BE is not, forcing BE as nonatomic
and demotes them to dev_dbg(), as suggested in review comments.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220708200641.26923-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use a dedicated flag instead of directly checking the
sdev->system_suspend_target to decide if we need to skip IMR boot due to
too deep sleep state where the memory used for IMR booting will not retain
its content.
The skip_imr_boot flag will be set true during suspend if the target state
is deeper than S3 and reset back to false on successful boot to re-enable
IMR booting in shallower sleep states.
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>
Link: https://lore.kernel.org/r/20220712120936.28072-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
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/20220712122357.31282-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
The issue was reported with IPC4 firmware but the same condition is present
for IPC3.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
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/20220712122357.31282-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not yet clear, but it is possible to create a firmware so broken
that it will send a reply message before a FW_READY message (it is not
yet clear if FW_READY will arrive later).
Since the reply_data is allocated only after the FW_READY message, this
will lead to a NULL pointer dereference if not filtered out.
The issue was reported with IPC4 firmware but the same condition is present
for IPC3.
Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
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/20220712122357.31282-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On a HP 288 Pro G6, the front mic could not be detected.In order to
get it working, the pin configuration needs to be set correctly, and
the ALC671_FIXUP_HP_HEADSET_MIC2 fixup needs to be applied.
Signed-off-by: Meng Tang <tangmeng@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220712092222.21738-1-tangmeng@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The comments are inconsistent and point to the wrong driver name.
The initially named i2c-multi-instantiate it was renamed to the
serial-multi-instantiate exactly due to support of the platforms
with multiple CS35L41 codecs.
Fix comments accordingly.
While at it, drop file names from the files.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220711100129.37326-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Another Dell model, another fixup entry: Latitude E5430 needs the same
fixup as other Latitude E series as workaround for noise problems.
Signed-off-by: Meng Tang <tangmeng@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220712060005.20176-1-tangmeng@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Cezary Rojewski <cezary.rojewski@intel.com>:
Series consists of loosely connected patches and does not concentrate on
one specific subject.
First, as generic HDAudio codec driver is now part of ASoC, avs-driver
core is updated to register missing ext_bus operations. This completes
driver's core implementation.
The next change adds the last missing piece for port descriptions coming
from topology in formatted string format e.g.: ssp%d have full
effect. To do that, the port value needs to be provided to respective
copier configuration.
Third change relaxes core transition timings so that scenarios where
modules are interfering with each other while being on separate cores
are not occasionally causing trouble.
All other changes are addressing warnings, cleaning things up a little
and protecting driver from invalid firmware behavior - while not
expected in release binaries, does not hurt to add them.
This patch adds the function of headphone button detection,
Button detection will be enabled if the device tree
has a key_enable property.
Signed-off-by: Seven Lee <wtli@nuvoton.com>
Link: https://lore.kernel.org/r/20220627032959.3442064-1-wtli@nuvoton.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>:
Our tests platforms do use realtek codecs, while implementing avs driver
and machine boards for it, we identified some problems with those codec
drivers.
This series aims to fix those issues.
Merge series from V sujith kumar Reddy <Vsujithkumar.Reddy@amd.com>:
Add Generic driver to support multiple platform,
ADD HS control instance for Rembrandt platform.
Add nau8825,max98560 and rt5682s,rt1019 combination support for legacy
platform.
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
Two patches to improve error and memory handling. When IPC4 is used,
some of the flows were incorrect.
We should only have an error when enforcing strict mapping between
kernel and firmware versions. In all other cases, there is no reason
to throw a warning.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220708200719.26961-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is another HP ProDesk 600 G3 model with the PCI SSID 103c:82b4
that requires the quirk HP_MIC_NO_PRESENCE. Add the corresponding
entry to the quirk table.
Signed-off-by: Meng Tang <tangmeng@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220711101744.25189-1-tangmeng@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The issue on Acer SWIFT SF313-51 is that headset microphone
doesn't work. The following quirk fixed headset microphone issue.
Note that the fixup of SF314-54/55 (ALC256_FIXUP_ACER_HEADSET_MIC)
was not successful on my SF313-51.
Signed-off-by: Meng Tang <tangmeng@uniontech.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220711081527.6254-1-tangmeng@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make sure that component is set to proper value, otherwise we may
dereference freed component in interrupt.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220707125701.3518263-6-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure that component is set to proper value, otherwise we may
dereference freed component in interrupt.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220707125701.3518263-5-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make sure that component is set to proper value, otherwise we may
dereference freed component in interrupt.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220707125701.3518263-4-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On our RVP platforms using rt298 with combojack we've seen issues with
controls being in incorrect state after suspend/resume cycle. This is
caused by codec driver not setting pins to correct state and causing
codec suspend method to not be called. Which on resume caused codec
registers to be in undefined state. Fix this by setting pins correctly
in jack detect function.
Above problem is caused by the fact that when jack == NULL code doesn't
reach rt298_jack_detect() function which sets pins. Alternatively
problem could be fixed by just moving rt298_jack_detect, but as rt298
codec is similar to rt286, align the code by setting pins explicitly.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220707125701.3518263-3-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Set rt298->jack to passed value in mic_detect, otherwise when jack is
set to NULL on next interrupt call, we may use freed pointer.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220707125701.3518263-2-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit a5450aba737d ("ASoC: rockchip: i2s: switch BCLK to GPIO") switched
BCLK to GPIO functions when probing the i2s bus interface, but missed
adding a check for when devm_pinctrl_get() returns an error. This can lead
to the following NULL pointer dereference on a rockpro64-v2 if there are no
"pinctrl" properties in the i2s device tree node.
Check that i2s->pinctrl is valid before attempting to search for the
bclk_on and bclk_off pinctrl states.
Fixes: a5450aba737d ("ASoC: rockchip: i2s: switch BCLK to GPIO")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20220711130522.401551-1-alexandru.elisei@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Avoid build errors when CONFIG_COMMON_CLK is not set/enabled.
ERROR: modpost: "__clk_get_name" [sound/soc/fsl/snd-soc-fsl-utils.ko] undefined!
Fixes: 7bad8125549c ("ASoC: fsl_utils: Add function to handle PLL clock source")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1657507190-14546-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove condition with no effect
Signed-off-by: Zhongjun Tan <tanzhongjun@coolpad.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220708024651.42999-1-hbut_tan@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
1. Revise hifixdsp shutdown flow to pull runstall high then reset high.
2. Add 1 us delay between D/BRESET high and low for 10 DSP cycles(26M)
based on IP vendor's suggestion.
Signed-off-by: YC Hung <yc.hung@mediatek.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Li-Yu Yu <afg984@gmail.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: KuanHsun Cheng <Allen-KH.Cheng@mediatek.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220708203904.29214-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not used anywhere in the file, so there is no need to keep it.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220706120230.427296-9-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Old code resets SIE for up to 8 streams using byte accessor, but
register is laid out in following way:
31 GIE
30 CIE
29:x Reserved
x-1:0 SIE
If there is more than 8 streams, some of them may and up with enabled
interrupts. To fix this just clear whole INTCTL register when disabling
interrupts.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20220706120230.427296-8-cezary.rojewski@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
