We discoverd that the state of BCLK on, LRCLK off and SD_MODE on
may cause the speaker melting issue. Removing LRCLK while BCLK
is present can cause unexpected output behavior including a large
DC output voltage as described in the Max98357a datasheet.
In order to:
1. prevent BCLK from turning on by other component.
2. keep BCLK and LRCLK being present at the same time
This patch switches BCLK to GPIO func before LRCLK output, and
configures BCLK func back during LRCLK is output.
Without this fix, BCLK is turned on 11 ms earlier than LRCK by the
da7219.
With this fix, BCLK is turned on only 0.4 ms earlier than LRCK by
the rockchip codec.
Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220619095324.492678-2-judyhsiao@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
dmaengine_terminate_all() is deprecated and should no longer be used.
Use dmaengine_terminate_async() instead. This involves no functional change
since both functions do the same.
After dmaengine_terminate_async() dmaengine_synchronize() must be called
to make sure the channel has really stopped before the underlying memory
is freed. This is done implicitly by dma_release_channel() called from
the .hw_free hook.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20220617120133.4011846-1-s.hauer@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
While testing driver bind/unbind sequences, I stumbled on a corner
case where the SoundWire bus can be suspended before the ASoC card
registration happens. During the registration, register accesses would
then lead to timeouts. This does not happen in regular usages where
the card registration happens within the 3-second time window before
suspend.
Adding a simple pm_runtime_resume_and_get() on component probe solves
the issue, but experiments showed it was too invasive to add at the
ASoC core level, with multiple regressions reported by our CI.
This patchset limits the additional resume to the SOF and SoundWire
codec drivers. An additional patch for the soundwire/intel component
will be sent separately.
Before initiating IPC and/or bus transactions when loading the
topology during a component probe, which happens on card
registration/creation, make sure the device for the SOF driver is
pm_runtime active.
The SOF probe is not necessarily followed by the component probe, such
a timing assumption can be broken in driver bind/unbind tests. This
can be artifially shown if the module for the machine driver is
'blacklisted' and the SOF device becomes pm_runtime_suspended before
manually calling modprobe to register the card.
In an initial experiment, pm_resume_and_get() was called from
soc-component.c, since the current ASoC component model is arguably
missing dependencies between component status and device
status. However this approach proved too invasive and breaks all
existing HDMI playback solutions on Intel platforms.
While this will result in duplication of code, generating pm_runtime
transitions only if strictly required for a given component makes more
sense overall. This patch adds the pm_runtime resume transition for
SOF only.
BugLink: https://github.com/thesofproject/linux/issues/3651
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@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220616210825.132093-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The lockdep mechanism revealed an unbalanced unlocking on MT8186:
[ 2.993966] WARNING: bad unlock balance detected!
[ 2.993978] -------------------------------------
[ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at:
[ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210
[ 2.994012] but there are no more locks to release!
The cause is that the mutex will be double unlocked if dai is unknown
during GPIO selection, and this patch fixes it.
Fixes: cfa9a966f1 ("ASoC: mediatek: mt8186: support gpio control in platform driver")
Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20220617111003.2014395-1-fshao@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The standard snd_soc_info_volsw() allows a two value control to be
defined as an integer control only if the control name ends in
"Volume". It achieves this by creating a substring if it contains
" Volume", and ensuring this exists at the end of the name. The
volume substring is then used to decide whether the type is a
SNDRV_CTL_ELEM_TYPE_INTEGER or SNDRV_CTL_ELEM_TYPE_BOOLEAN.
However this volume substring is only computed for a two value
control.
This means for controls where there are more than two possible
values, the substring is never created, so in this case the
substring remains NULL, and the condition yields
SNDRV_CTL_ELEM_TYPE_BOOLEAN, even though there are more than 2
possible values.
If there are more than 2 possible values for the control,
then it should always be an integer control.
Fixes: aa2a4b8971 ("ASoC: ops: Fix boolean/integer detection for simple controls")
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220617153606.2619457-1-sbinding@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
This patchset adds the missing jack pin remapping needed by upstream
UCM on Chromebooks, suggested by Jaroslav Kysela [1].
These patches were succesfully tested on GeminiLake and JasperLake
platforms, and generalized to other Chromebooks.
[1] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2022-June/004468.html
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
Cleanups suggested by Greg KH during SoundWire reviews, since the
__func__ information can be added with the dyndbg kernel parameter
[1].
The first two patches change the error level in cases where the use of
dev_dbg() was inconsistent with an aborted programming sequence.
[1] https://lore.kernel.org/alsa-devel/20220610023537.27223-2-yung-chuan.liao@linux.intel.com/
Legacy or non DT boot is no longer possible on systems where the
tw4030/5030 is used.
Drop the support for handling legacy pdata and replace it with a local
board_params struct to allow further cleanups on the mfd side.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20220616153521.29701-1-peter.ujfalusi@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-14-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-13-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-12-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module and function information can be added with
'modprobe foo dyndbg=+pmf'
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We report -ENODEV but only use dev_dbg, this is
inconsistent. dev_err() makes sense here.
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dev_dbg() is not good-enough since the flow returns an error.
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616215351.135643-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-14-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-13-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-12-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-11-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-10-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-9-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The card did not map jack pins to controls, which prevents
PulseAudio/PipeWire from dealing with jack detection. It's likely that
jack detection was only tested with the CRAS server and extensions of
UCM.
Suggested-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-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>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20220616214055.134943-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove warnings
sound/soc/sunxi/sun4i-i2s.c:205: warning: Function parameter or member
'num_din_pins' not described in 'sun4i_i2s_quirks'
sound/soc/sunxi/sun4i-i2s.c:205: warning: Function parameter or member
'num_dout_pins' not described in 'sun4i_i2s_quirks'
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.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/20220616220802.136282-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
IPC4 based firmwares have unconditional support for IMR boot.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-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>
Link: https://lore.kernel.org/r/20220616054910.16690-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are two occurrences where the pointer array is being assigned a value
that is never read, the pointer gets updated in the next iteration of a
loop. These assignments are redundant and can be removed.
Cleans up clang scan-build warnings:
sound/soc/intel/skylake/skl-topology.c:2953:3: warning: Value stored to
'array' is never read [deadcode.DeadStores]
sound/soc/intel/skylake/skl-topology.c:3602:3: warning: Value stored to
'array' is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20220614183809.163531-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The sof_ipc4_volume_put() function returns type bool so returning
-ENOENT means returning true. Return false instead.
Fixes: 955e84fc0b ("ASoC: SOF: ipc4-topology: Add control IO ops")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/YqqyDU5BhOzpRjco@kili
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Li Chen <lchen.firstlove@zohomail.com>
This series proposes to add simple bit operations for setting, clearing
and testing specific bits with regmap_field and uses them in one of the
sunxi drivers.
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:
Add platform abstraction for the Meteor Lake platform.
This platform has significant differences compared to the TGL/ADL
generation: it relies on new hardware using the code name 'ACE' and
only supports the INTEL_IPC4 protocol and firmware architecture based
on the Zephyr RTOS
Appropriately change calls to {regmap/regmap_field}_update_bits()
with {regmap/regmap_field}_set_bits()
and {regmap/regmap_field}_clear_bits() for improved readability.
Signed-off-by: Li Chen <lchen@ambarella.com>
Link: https://lore.kernel.org/r/180eef50e96.cb7c34db60740.8898768158778553647@zohomail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We have set/clear/test operations for regmap, but not for regmap_field yet.
So let's introduce regmap_field helpers too.
In many instances regmap_field_update_bits() is used for simple bit setting
and clearing. In these cases the last argument is redundant and we can
hide it with a static inline function.
This adds three new helpers for simple bit operations: set_bits,
clear_bits and test_bits (the last one defined as a regular function).
Signed-off-by: Li Chen <lchen@ambarella.com>
Link: https://lore.kernel.org/r/180eef422c3.deae9cd960729.8518395646822099769@zohomail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add platform abstraction for the Meteor Lake platform.
This platform has significant differences compared to the TGL/ADL
generation: it relies on new hardware using the code name 'ACE' and
only supports the INTEL_IPC4 protocol and firmware architecture based
on the Zephyr RTOS
Co-developed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Link: https://lore.kernel.org/r/20220615084348.3489-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The code loader init sequences are different between versions of
Intel platforms. Have a cl_init callback allows us to reuse the
common code.
No function changed.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@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/20220615084348.3489-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MBDRC supports different modes of operation. There is no configuration
required for bypass mode. The hw_params() call does not filter bypass
mode correctly and it leads to following Smatch static checker warning:
sound/soc/tegra/tegra210_mbdrc.c:778 tegra210_mbdrc_hw_params()
warn: bitwise AND condition is false here
Fix this condition by using proper mode mask and just return for bypass
mode.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 7358a803c7 ("ASoC: tegra: Add Tegra210 based OPE driver")
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1655267914-24702-1-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
I2S reset failures are seen on Tegra210 and later platforms. This indicates
absence of I2S bit clock, which is required to perform the reset operation.
Following failures are seen with I2S based tests on Tegra210 and later:
tegra210-i2s 2901100.i2s: timeout: failed to reset I2S for playback
tegra210-i2s 2901100.i2s: ASoC: PRE_PMU: I2S2 RX event failed: -110
tegra210-i2s 2901100.i2s: timeout: failed to reset I2S for capture
tegra210-i2s 2901100.i2s: ASoC: PRE_PMU: I2S2 TX event failed: -110
The commit d92ad6633f ("ASoC: tegra: Update to use set_fmt_new callback")
regressed I2S functionality on Tegra platforms. Basically it flipped clock
provider and consumer DAI formats. This configures Tegra I2S in consumer
mode by default now and there is none to provide bit clock during loopback
tests. The external codec based tests also fail because both Tegra I2S and
codec I2S get configured in consumer mode.
ASoC core flips the DAI format before calling set_fmt() for CPU DAIs. This
is negated in above commit. Fix this by swapping SND_SOC_DAIFMT_BC_FC and
SND_SOC_DAIFMT_BP_FP switch cases.
Fixes: d92ad6633f ("ASoC: tegra: Update to use set_fmt_new callback")
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Cc: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/1655280277-4701-1-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Judy Hsiao