On a platform shutdown, the expectation for most drivers is that
userspace tasks will release all resources. When those sequences do
not complete, it can be the case that PCM devices exposed by ALSA
cards are used *after* the DSP shutdown completes, leading to a
platform hang.
When the clients and machine drivers provide an _unregister callback,
let's invoke it in the shutdown sequence.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20220216133241.3990281-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the case like dmaengine which's not a dai but as a component, the
num_dai is zero, dmaengine component has the same component_of_node
as cpu dai, when cpu dai component is not ready, but dmaengine component
is ready, try to get cpu dai name, the snd_soc_get_dai_name() return
-EINVAL, not -EPROBE_DEFER, that cause below error:
asoc-simple-card <card name>: parse error -22
asoc-simple-card: probe of <card name> failed with error -22
The sound card failed to probe.
So this patch fixes the issue above by skipping the zero num_dai
component in searching dai name.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1644491952-7457-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't populate the read-only const array rates on the stack but
instead it static. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20220214213223.65780-1-colin.i.king@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel's kernel test robot found the following randconfig combination:
SND_SOC_SOF=y
SND_SOC_SOF_CLIENT=m
In this the sof-client object is not going to be built into the snd-sof.o
and we will have undefined references to the sof-client functions.
Fixes: 6955d9512d ("ASoC: SOF: Introduce IPC SOF client support")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Peter Ujfalusi <Peter Ujfalusi <peter.ujfalusi@linux.intel.com>>
Link: https://lore.kernel.org/r/20220214071330.22151-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Nikita Yushchenko <nikita.yoush@cogentembedded.com>:
These patches clean up pcm3168a driver, without introducing any
functional change.
Add switch control for selecting CTIA or OMTP Headset by swapping
gnd and mic with the help of GPIO.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Co-developed-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Signed-off-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Link: https://lore.kernel.org/r/1644668672-29790-2-git-send-email-quic_srivasam@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On BIAS STANDBY->OFF transition the current implementation sleeps
600ms on suspend in order to discharge the chip. The suspend is
propagated from "snd_soc_suspend" call for all audio cards in a
serial fashion, thus in case of boards like i.MX8DXL EVK which has
3 distinct WM8960 codecs the total cumulated sleep on suspend is 1.8
seconds.
On the other hand the BIAS OFF->STANDBY transition happens
asynchronously with regard to "snd_soc_resume" - the call is
propagated from "soc_resume_deferred" which is just scheduled
from "snd_soc_resume", each card having its own work scheduled to
execute "soc_resume_deferred" call.
The patch performs discharge completion on BIAS OFF->STANDBY transition
so that the cumulated effect on suspend described above is avoided
and discharge is completed in paralel in case of multiple WM8960
codecs on the board.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Link: https://lore.kernel.org/r/20220208121727.4461-1-viorel.suman@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The I2C remove function is empty for the wm8731 driver, it can just be
deleted.
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220211165811.1176005-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
- drop incomplete (not tdm-aware) calculation/setting of hardware
fmt value from pcm3168a_set_dai_fmt(); instead, store original
SND_SOC_DAIFMT* setting in io_params
- in pcm3168a_hw_params(), do all checks in terms of SND_SOC_DAIFMT*,
and convert that to register bitfield values only to write to
hardware
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Link: https://lore.kernel.org/r/20220208084220.1289836-4-nikita.yoush@cogentembedded.com
Signed-off-by: Mark Brown <broonie@kernel.org>
- group together code lines that calculate value for msad/msda field
- rename variables to better match their meaning:
val -> ms,
max_ratio -> num_scki_ratios
- update variable types to match exactly parameters or return types
of the calls where those variables are used
- write two fields of the same register in a single regmap call
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Link: https://lore.kernel.org/r/20220208084220.1289836-3-nikita.yoush@cogentembedded.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When checking if the requested parameters are supported, the driver uses
PCM3168A_FMT_DSP_MASK to check for PCM3168A_FMT_DSP_* values.
However, formally not only PCM3168A_FMT_DSP_* values match that
condition, PCM3168A_FMT_I2S_TDM and PCM3168A_FMT_LEFT_J_TDM also do.
The check still gives correct result because those extra values can't
be in 'fmt' at the check location. Still, to make the code less cryptic,
better to compare 'fmt' with PCM3168A_FMT_DSP_* values explicitly.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Link: https://lore.kernel.org/r/20220208084220.1289836-2-nikita.yoush@cogentembedded.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Functions won't be directly used outside of compress.c file
so mark them as static.
This will also fix warnings reported by kernel test robot:
>> sound/soc/sof/compress.c:91:5: warning: no previous prototype for
function 'sof_compr_open' [-Wmissing-prototypes]
int sof_compr_open(struct snd_soc_component *component,
^
sound/soc/sof/compress.c:91:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
int sof_compr_open(struct snd_soc_component *component,
Fixes: 6324cf901e ("SoC: SOF: compr: Add compress ops implementation")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20220211082631.179735-1-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Platform_driver probe functions aren't called with locks held
and thus don't need GFP_ATOMIC. Use GFP_KERNEL instead.
Problem found with Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20220210204223.104181-4-Julia.Lawall@inria.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable access to the speaker protection firmware debug stream
using compress stream API and lower minimum fragment size to
16 words.
Signed-off-by: Vlad Karpovich <Vlad.Karpovich@cirrus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220210172053.22782-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Newer firmwares will support compressed buffers that may or may not
exist, for example debugging streams. Update the driver to make a
compressed stream optional. A warning will still be generated at DSP
boot time and opening the stream will fail if the compressed buffer in
question does not exist, however the DSP can still be booted and other
features used.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220210172053.22782-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The TLV320ADC3001/3101 have an internal DSP, which can either be
used in various preset configurations (called "Processing Blocks"
in the data sheet), or as a freely programmable (using the
"PurePath Studio" graphical programming tool from TI) but rather
small DSP ("miniDSP").
Using the default configuration (PRB_R1) it's possible to set up
filtering using a first-order IIR, which can be useful for adding
a digital high pass filter to the signal chain, for instance.
This patch adds support for configuring the IIR filter coefficients.
The filter itself is always enabled; the default coefficients
implement a pass-through function.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202101805360.7068@lnxricardw1.se.axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
The Linux SOF implementation is historically monolithic in a sense that all
features accessible in the firmware can be used via the snd_sof_dev struct in
one way or another.
Support for features can not be added or removed runtime and with the current
way of things it is hard if not impossible to implement support for dynamic
feature support when based on the firmware manifest we can easily enable/access
independent modules with the SOF.
In order to be able to support such modularity this series introduces a small
framework within SOF for client support using the Auxiliary bus.
Client drivers can be removed runtime and later re-loaded if needed without
affecting the core's behaviour, but it is the core's and the platform's duty
to create the Auxiliary devices usable in the platform and via the firmware.
There is still a need for SOF manifest update to convey information about
features to really make the full dynamic client device creation.
The series will introduce the core SOF client support and converts the generic
ipc flood test, ipc message injector and the probes (Intel HDA only) to a client
driver.
Merge series from Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>:
This patch set is to add support for SC7280 sound card registration and
to add dt-bindings documentation file.
Add a new client driver for probes support and move
all the probes-related code from the core to the
client driver.
The probes client driver registers a component driver
with one CPU DAI driver for extraction and creates a
new sound card with one DUMMY DAI link with a dummy codec
that will be used for extracting audio data from specific
points in the audio pipeline.
The probes debugfs ops are based on the initial
implementation by Cezary Rojewski and have been moved
out of the SOF core into the client driver making it
easier to maintain. This change will make it easier
for the probes functionality to be added for all platforms
without having the need to modify the existing(15+) machine
drivers.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-10-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the IPC message injection code out from the debug file as separate
SOF client driver.
Based on the kernel configuration, the device registration for the new IPC
message injector is going to happen in the core.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-9-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the IPC flood test code out from the debug file as separate SOF client
driver.
Based on the kernel configuration, the device registration for the new IPC
flood test is going to happen in the core.
With the separate client driver it is going to be possible to run multiple
flood tests in parallel to increase the stress, the new Kconfig option can
be used to select this (defaults to 1).
In order to preserve backward compatibility with existing SW/scripts, the
first IPC flood test's debugfs files have been linked to the old files.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Co-developed-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-8-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SOF client can be of 'passive' type, meaning that they do not handle
PM framework callbacks by themselves but rely on the auxiliary driver's
suspend and resume callbacks to be notified about the core's suspend or
resume event.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A client in the SOF (Sound Open Firmware) context is a driver that needs
to communicate with the DSP via IPC messages. The SOF core is responsible
for serializing the IPC messages to the DSP from the different clients.
One example of an SOF client would be an IPC test client that floods the
DSP with test IPC messages to validate if the serialization works as
expected.
Multi-client support will also add the ability to split the existing audio
cards into multiple ones, so as to e.g. to deal with HDMI with a dedicated
client instead of adding HDMI to all cards.
This patch introduces descriptors for SOF client driver and SOF client
device along with APIs for registering and unregistering a SOF client
driver, sending IPCs from a client device and accessing the SOF core
debugfs root entry.
Along with this, add a couple of new members to struct snd_sof_dev that
will be used for maintaining the list of clients.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Co-developed-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-6-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The utils.c contains wrappers and implementation for accessing iomem mapped
regions and a single unrelated function to create a compressed page table
from snd_dma_buffer for firmware use.
The latter is used by the PCM and the dma trace code and it needs to be
moved to a generic source/header for the client conversion to be possible.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the parameter list for the firmware initiated message (IPC event)
handler functions to:
handler(struct snd_sof_dev *sdev, void *full_msg);
Allocate memory and read the whole message in snd_sof_ipc_msgs_rx() then
pass the pointer to the function handling the message.
Do this only if we actually have a function which is tasked to process the
given type.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the enum sof_dsp_power_states 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: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only reference to D3_HOT and D3_COLD DSP power state is in
intel/hda-dsp.c in form of a dev_dbg() print.
Remove them as they are not used and even if they are they could be
re-added via the substate.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@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/20220210150525.30756-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the sysclk and sysclk_src checking in the function set_sysclk() to
prevent the PLL power off. It is not getting re-programmed during
subsequent runs after the first run (in BIAS_OFF stage).
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://lore.kernel.org/r/20220210071900.17287-1-oder_chiou@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add new machine driver to register sound card on sc7280 based targets and
do the required configuration for lpass cpu dai and external codecs
connected over MI2S and soundwire interfaces.
Add support for audio jack detection, soundwire init and MBHC.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Co-developed-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Signed-off-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Link: https://lore.kernel.org/r/1644497415-25291-4-git-send-email-quic_srivasam@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add macro for lpass DAI id's max limit to create static arrays
and for array boundary checks.
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
Co-developed-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Signed-off-by: Venkata Prasad Potturu <quic_potturu@quicinc.com>
Link: https://lore.kernel.org/r/1644497415-25291-3-git-send-email-quic_srivasam@quicinc.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The existing code maximizes confusion by using 'stream' and 'hstream'
variables of different types, e.g:
struct hdac_stream *stream;
struct hdac_ext_stream *stream;
struct hdac_stream *hstream;
struct hdac_ext_stream *hstream;
This confusion is partly inherited from legacy code but SOF
contributors added their own creative spin, e.g.
struct hdac_ext_stream *link_dev;
struct hdac_ext_stream *dsp_stream;
struct hdac_ext_stream hda_stream;
and my personal favorite:
stream = &hda_stream->hda_stream;
This patch suggests a consistent naming across all Intel code related
to HDAudio stream management. The convention is - by hierarchical
order:
struct sof_intel_hda_stream *hda_stream;
struct hdac_ext_stream *hext_stream;
struct hdac_stream *hstream;
No functionality change - just renaming of variables/members.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220209063104.9971-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Hi,
the DMA trace implementation on AMD platform assumes that the stream_tag pointer
is pointing the stream_tag member of struct sof_ipc_dma_trace_params_ext, which
is true at the moment, but it can not be guarantied and a change in the dtrace
core can cause out of bound accesses for AMD.
For this reason, change the API to pass the struct itself which will remove the
assumption and makes it clear from both sides what is expected to be sent via the
parameter list.
This opens up a window to clean up the intel and AMD implementation at the same
time.
Regards,
Peter
---
Peter Ujfalusi (2):
ASoC: SOF: intel: hda-trace: Pass the dma buffer pointer to
hda_dsp_trace_prepare
ASoC: SOF: dma-trace: Pass pointer to params_ext struct in
trace_init()
sound/soc/sof/amd/acp-trace.c | 38 ++++++++-------------------------
sound/soc/sof/amd/acp.h | 3 ++-
sound/soc/sof/intel/hda-trace.c | 17 ++++++++-------
sound/soc/sof/intel/hda.h | 3 ++-
sound/soc/sof/ops.h | 4 ++--
sound/soc/sof/sof-priv.h | 2 +-
sound/soc/sof/trace.c | 2 +-
7 files changed, 26 insertions(+), 43 deletions(-)
--
2.35.0
Merge series from Mark Brown <broonie@kernel.org>:
This series removes a bunch of spurious selects of gpiolib that were
causing noise in randconfig build tests.
Mark Brown (6):
ASoC: dmic: Remove spurious gpiolib select
ASoC: rt9120: Remove spurious gpiolib select
ASoC: simple-amplifier: Remove spurious gpiolib select
ASoC: max9759: Remove spurious gpiolib select
ASoC: zl38060: Remove spurious gpiolib select
ASoC: simple-mux: Depend on gpiolib rather than selecting it
sound/soc/codecs/Kconfig | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
base-commit: e783362eb5
--
2.30.2
The fsl_sai driver calculates the number of pins used and enables
multiple channels if necessary. This means the SAI expects data in
one FIFO per pin. The SDMA engine only services a single FIFO, so
multi pin support doesn't work at all.
This patch enables the software combine mode in chips that support
it. With this the SAI presents only a single FIFO to the outside
and distributes the data into the different FIFOs internally.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20220111081518.982437-1-s.hauer@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement snd_compress_ops. There are a lot of similarities with
PCM implementation.
For now we use sof_ipc_pcm_params to transfer compress parameters to SOF
firmware.
This will be changed in the future once we either add new compress
parameters to SOF or enhance existing sof_ipc_pcm_params structure
to support all native compress params.
Note that get_caps and get_codec_caps are missing and will be added
later. This is because we need to find a way to advertise DSP
capabilities depending on supported platforms.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20220120143741.492634-1-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of passing a pointer to the stream_tag within the
struct sof_ipc_dma_trace_params_ext, pass the pointer to the containing
struct.
AMD needs to update buffer.phy_addr (and don't really use the stream_tag)
for the trace 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/20220128123623.23569-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pass the snd_dma_buffer pointer as parameter to hda_dsp_trace_prepare()
function.
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/20220128123623.23569-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The simple-mux driver requires gpiolib. Currently it selects GPIOLIB but
since the use of select can lead to issues with randconfig let's instead
depend on GPIOLIB, select is more idiomatically used for Kconfig symbols
that are not user selectable but GPIOLIB is user selectable.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-7-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The usage of GPIOs is optional in the code so don't force on gpiolib when
building it, avoiding warnings in randconfigs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-6-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The usage of GPIOs is optional in the code so don't force on gpiolib when
building it, avoiding warnings in randconfigs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-5-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The usage of GPIOs is optional in the code so don't force on gpiolib when
building it, avoiding warnings in randconfigs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-4-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The usage of GPIOs is optional in the code so don't force on gpiolib when
building it, avoiding warnings in randconfigs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-3-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The usage of GPIOs is optional in the code so don't force on gpiolib when
building it, avoiding warnings in randconfigs.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220202192333.3655269-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Samuel Holland <samuel@sholland.org>:
This series extends the sun4i-i2s binding and driver to support some
newer versions of the hardware. Each instance of the hardwar now has
multiple input/output pins, and channels can be muxed between them.
Since so far the driver only supports a "default" linear channel map,
the driver changes are minimal.
Samuel Holland (3):
ASoC: dt-bindings: sun4i-i2s: Add compatibles for R329 and D1
ASoC: sun4i-i2s: Update registers for more channels
ASoC: sun4i-i2s: Add support for the R329/D1 variant
.../sound/allwinner,sun4i-a10-i2s.yaml | 5 ++
sound/soc/sunxi/sun4i-i2s.c | 68 +++++++++++++++----
2 files changed, 59 insertions(+), 14 deletions(-)
--
2.33.1
The Madera CODECs use regmap_irq functions but nothing ensures that
regmap_irq is built into the kernel. Add dependencies on the ASoC
symbols for the relevant MFD component. There is no point in building
the ASoC driver if the MFD doesn't support it and the MFD part contains
the necessary dependencies to ensure everything is built into the
kernel.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220203115025.16464-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
midas_wm811 uses gpiolib but relies on the header being implicitly included
which can lead to build failures in some configurations, explicitly pull
the header in to avoid problems.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20220202191322.3650708-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When the DMIC_ENA bit is set the analogue inputs are disconnected from
the digital core of the chip, in favour of the digital microphones.
Currently the driver will always enable DMIC_ENA whilst the GPIOs are
configured for the DMIC function, this means the user can't currently
use both the analog inputs and the digital inputs in one system.
Add an additional DAPM mutex that allows switching between analog and
digital inputs into the digital core.
Reported-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reported-and-tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
Link: https://lore.kernel.org/r/20220202164545.30457-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
