Use ssp-common module to detect codec and amplifier type in driver
probe function and remove all quirks about codec and amplifier type.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-8-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use ssp-common module to detect codec and amplifier type in driver
probe function and remove all quirks about codec and amplifier type.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-7-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use ssp-common module to detect codec and amplifier type in driver
probe function and remove all quirks about codec and amplifier type.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use ssp-common module to detect codec and amplifier type in driver
probe function and remove all quirks about codec and amplifier type.
Due to codec detection feature, we could remove HP Dooly's DMI quirk
safely.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use ACPI HID definition in ssp-common header for device name macros.
No functional change here.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Create a new common module to host functions which could be shared
among SSP machine drivers. Add functions to detect headphone codec and
speaker amplifier via ACPI system at runtime in order to remove codec
type quirks in machine drivers.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove SOF_RT5682_MCLK_24MHZ flag from JSL and CML/WHL board configs
since the information could be retrieved from SOF API. The macro
itself is removed as well.
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915124852.1696857-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Rather than incrementing the ID for the dai_links in many places
throughout the code, just increment it each time we initialise a new DAI
link.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915075611.1619548-5-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now only the SoundWire part of the code uses the global cpus array,
remove it and have create_sdw_dailink allocate its own link components.
This removes a lot of state being passed around in the driver, which
simplifies things a fair bit.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915075611.1619548-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The code contains a fair amount of state tracking and one part of that
is keeping track of which entry in the large global cpus
snd_soc_dai_link_component array is currently in use. Add a helper
function to allocate a simple DAI link, this simplifies the
code slightly and moves us in the direction of eliminating the need for
the large global cpus array. This does slightly increase the number of
allocations done, but this is probe time and the code already does a
large number of allocations so this increase is small over all.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915075611.1619548-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Whilst it should not cause any issues as only a single instance of the
machine will be instantiated, it is still slightly better practice to
keep working data in the private data structure, rather than a global
variable. Move sdw_pin_index into the mc_private structure.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230915075611.1619548-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The compile warning with -Wformat-truncation at
sdw_amd_scan_controller() is false-positive; the max loop size is
AMD_SDW_MAX_MANAGERS (= 2), hence it fits with the given size.
For suppressing the warning, replace snprintf() with scnprintf().
As stated in the above, truncation doesn't matter.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230915082207.26200-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds a control that there are four options to control the digital volume output.
The user could select "immediate" to make volume updates immediately.
In default, the driver selects the volume update with "zero detection + soft inc/dec change".
Signed-off-by: Shuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20230915020530.83452-1-shumingf@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a certain sequence needs to be followed when configuring the HDA
DMA in host and DSP.
The firmware provides a way to handle this two stage sequencing by
splitting the library loading into two stage:
1st stage: LOAD_LIBRARY_PREPARE message
the lib_id is 0, used to configure the DMA on DSP side
2nd stage: LOAD_LIBRARY message
both dma_id and lib_id is valid, used for the actual transfer of
the library
In case a firmware without support for this two stage loading is used then
the second stage message will trigger the loading and the first stage will
return with error, which is ignored by the kernel.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Link: https://lore.kernel.org/r/20230915114018.1701-5-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On Intel platforms there is a strict order requirement for the DMA
programming:
DSP side configures the buffer and sets the GEN bit
Host side sets the RUN bit.
In order to follow this flow, a new global message type has been added to
prepare the DSP side of the DMA:
host sends LOAD_LIBRARY_PREPARE with the dma_id
DSP side sets its buffer and sets the GEN bit
Host sets the RUN bit
Host sends LOAD_LIBRARY with dma_id and lib_id
DSP receives the library data.
It is up to the platform code to use the new prepare stage message and how
to handle the reply to it from the firmware, which can indicate that the
message type is not supported/handled.
In this case the kernel should proceed to the LOAD_LIBRARY stage assuming
a single stage library loading:
host sends LOAD_LIBRARY_PREPARE with the dma_id
DSP replies that the message type is not supported/handled
Host acknowledges the return code and sets the RUN bit
Host sends LOAD_LIBRARY with dma_id and lib_id
DSP receives the library data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Link: https://lore.kernel.org/r/20230915114018.1701-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The FIFOS (FIFO Size) field is in bit 0-15 of the register.
Use the defined mask instead of a magic number for the FIFOS value
masking in hda_dsp_stream_hw_params().
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Link: https://lore.kernel.org/r/20230915114018.1701-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The status code 2 and 15 can be translated to -EOPNOTSUPP, so convert them
to a meaningful error number.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Link: https://lore.kernel.org/r/20230915114018.1701-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When a copier exposes a single format, we can fixup the BE dailink with
that format. This is helpful when some codec have format restrictions and
e.g. don't support a 32-bit format. In that case, the copier output
formats mirror that restriction in the topology file.
An alternate solution was suggested earlier using a dedicated topology
token. When specified, the token would be used to fix-up the dailink. The
main reason why this solution was chosen is that there is a risk of a
disconnect between token definition and copier format. With a single piece
of information as suggested in this patch, there are fewer risks of a bad
configuration.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@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/20230915093507.7242-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We will use the sof_ipc4_copier_is_single_format() function to check if a
ipc4 copier has single format available in ipc4-pcm.c in the next patch.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@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/20230915093507.7242-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The cs35l56_pm_ops_i2c_spi struct is only needed if either the
I2C or SPI modules are selected for building. Otherwise it would
be unused bytes, so in that case omit it.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230914150918.14505-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use pm_ptr() when setting the pointer to the dev_pm_ops so that it
will be NULL if CONFIG_PM is disabled. This allows the dev_pm_ops to be
compiled out in that case.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230914150918.14505-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the out label to dump the message payload when the IPC message fails.
The payload contains important information on what might have caused the
error in firmware.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@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/20230914125115.30904-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
New code uses ENOTSUPP as per checkpatch recommendation:
ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP
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>
Link: https://lore.kernel.org/r/20230914124943.24399-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:
The PCI device registers contain a subsystem ID (SSID), that is
separate from the silicon ID. The PCI specification defines it thus:
"They provide a mechanism for board vendors to distiguish their
boards from one another even thought the boards may have the same
PCI controller on them."
This allows the driver for the silicon part to apply board-speficic
settings based on this SSID.
The CS35L56 driver uses this to select the correct firmware file for
the board. The actual ID is part of the PCI register set of the
host audio interface so this set of patches includes extracting the
SSID from the Intel audio controller and passing it to the machine
driver and then to ASoC components. Other PCI audio controllers
will have the same SSID registers, so can use the same mechanism to
pass the SSID.
The patch helps save power by control MICBIAS. The headset's
MICBIAS should be disabled without button requirement.
Signed-off-by: Seven Lee <wtli@nuvoton.com>
Link: https://lore.kernel.org/r/20230913064003.2925997-1-wtli@nuvoton.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to use temporary strings to construct the kcontrol names,
devm_kasprintf can be used to replace the snprintf + devm_kstrdup pairs.
This change will also fixes the following compiler warning/error (W=1):
sound/soc/codecs/hdac_hdmi.c: In function ‘hdac_hdmi_jack_port_init’:
sound/soc/codecs/hdac_hdmi.c:1793:63: error: ‘ Switch’ directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Werror=format-truncation=]
1793 | snprintf(kc_name, sizeof(kc_name), "%s Switch", xname);
| ^~~~~~~
In function ‘create_fill_jack_kcontrols’,
inlined from ‘hdac_hdmi_jack_port_init’ at sound/soc/codecs/hdac_hdmi.c:1871:8:
sound/soc/codecs/hdac_hdmi.c:1793:25: note: ‘snprintf’ output between 8 and 39 bytes into a destination of size 32
1793 | snprintf(kc_name, sizeof(kc_name), "%s Switch", xname);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The warnings got brought to light by a recent patch upstream:
commit 6d4ab2e97d ("extrawarn: enable format and stringop overflow warnings in W=1")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230913091325.16877-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the driver properties do not define a cirrus,firmware-uid try to get the
PCI SSID as the UID.
On PCI-based systems the PCI SSID is used to uniquely identify the specific
sound hardware. This is the standard mechanism for x86 systems and is the
way to get a unique system identifier for systems that use the CS35L56 on
SoundWire.
For non-SoundWire systems there is no Windows equivalent of the ASoC driver
in I2C/SPI mode. These would be:
1. HDA systems, which are handled by the HDA subsystem.
2. Linux-specific systems.
3. Composite devices where the cs35l56 is not present in ACPI and is
configured using software nodes.
Case 2 can use the firmware-uid property, though the PCI SSID is supported
as an alternative, as it is the standard PCI mechanism.
Case 3 is a SoundWire system where some other codec is the SoundWire bridge
device and CS35L56 is not listed in ACPI. As these are SoundWire systems
they will normally use the PCI SSID.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230912163207.3498161-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the PCI SSID has been set in the struct snd_soc_acpi_mach_params,
copy this to struct snd_soc_card so that it can be used by other
ASoC components.
This is important for components that must apply system-specific
configuration.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230912163207.3498161-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Pass the PCI SSID of the audio interface through to the machine driver.
This allows the machine driver to use the SSID to uniquely identify the
specific hardware configuration and apply any platform-specific
configuration.
struct snd_sof_pdata is passed around inside the SOF code, but it then
passes configuration information to the machine driver through
struct snd_soc_acpi_mach and struct snd_soc_acpi_mach_params. So SSID
information has been added to both snd_sof_pdata and
snd_soc_acpi_mach_params.
PCI does not define 0x0000 as an invalid value so we can't use zero to
indicate that the struct member was not written. Instead a flag is
included to indicate that a value has been written to the
subsystem_vendor and subsystem_device members.
sof_pci_probe() creates the struct snd_sof_pdata. It is passed a struct
pci_dev so it can fill in the SSID value.
sof_machine_check() finds the appropriate struct snd_soc_acpi_mach. It
copies the SSID information across to the struct snd_soc_acpi_mach_params.
This done before calling any custom set_mach_params() so that it could be
used by the set_mach_params() callback to apply variant params.
The machine driver receives the struct snd_soc_acpi_mach as its
platform_data.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230912163207.3498161-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add members to struct snd_soc_card to store the PCI subsystem ID (SSID)
of the soundcard.
The PCI specification provides two registers to store a vendor-specific
SSID that can be read by drivers to uniquely identify a particular
"soundcard". This is defined in the PCI specification to distinguish
products that use the same silicon (and therefore have the same silicon
ID) so that product-specific differences can be applied.
PCI only defines 0xFFFF as an invalid value. 0x0000 is not defined as
invalid. So the usual pattern of zero-filling the struct and then
assuming a zero value unset will not work. A flag is included to
indicate when the SSID information has been filled in.
Unlike DMI information, which has a free-format entirely up to the vendor,
the PCI SSID has a strictly defined format and a registry of vendor IDs.
It is usual in Windows drivers that the SSID is used as the sole identifier
of the specific end-product and the Windows driver contains tables mapping
that to information about the hardware setup, rather than using ACPI
properties.
This SSID is important information for ASoC components that need to apply
hardware-specific configuration on PCI-based systems.
As the SSID is a generic part of the PCI specification and is treated as
identifying the "soundcard", it is reasonable to include this information
in struct snd_soc_card, instead of components inventing their own custom
ways to pass this information around.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20230912163207.3498161-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The loop is not using "node", of_node_put(node) is not needed.
Cc: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8734zlilmd.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason the JH7110 PWM DAC driver made it through build testing
in spite of not being updated for the move of probe() to the ops struct.
Make the required update.
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
This patch series aims to add match data improvements for wm8580 driver.
This patch series is only compile tested.
Merge series from Linus Walleij <linus.walleij@linaro.org>:
The Maxim devices are pretty straight-forward to convert
over to use GPIO descriptors, so let's do it.
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
This patch series aims to add match data improvements for tlv320aic32x4
driver.
This patch series is only compile tested.
Merge series from Linus Walleij <linus.walleij@linaro.org>:
The Maxim devices are pretty straight-forward to convert
over to use GPIO descriptors, so let's do it.
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
This series introduces dynamic pinctrl and adds support for the SOF on
the mt8188-mt6359 machine driver.
Merge series from Biju Das <biju.das.jz@bp.renesas.com>:
This patch series aims to add match data improvements for ak4642 driver.
This patch series is only compile tested.
Merge series from Marian Postevca <posteuca@mutex.one>:
This series adds support for a line of HUAWEI laptops with
AMD CPUs that connect using the ACP3x module to a ES8336 CODEC.
The CODEC driver must be extended to support the S32 LE format
and the MCLK div by 2 option. MCLK div by 2 is needed for one specific
SKU, which uses a 48Mhz MCLK, which seems to be too high of a frequency
for the CODEC and must be divided by 2.
The acp legacy driver must also be extended by using callbacks so that
the more complicated handling of this specific CODEC can be moved
outside the more generic ACP code.
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
This patch series contains several fixes and improvements to drivers
based on the CS35l41 audio codec.
It has been verified on Valve's Steam Deck, except the HDA related patches.
Merge series from Hal Feng <hal.feng@starfivetech.com>:
This patchset adds PWM-DAC audio support for the StarFive JH7110 SoC.
The PWM-DAC module does not require a hardware codec, but a dummy codec is
needed for the driver. The dummy spdif codec driver, which is already
upstream, is compatible with the one which JH7110 PWM-DAC needed. So we
use it as the dummy codec driver for the JH7110 PWM-DAC module.
Merge series from Sameer Pujar <spujar@nvidia.com>:
This small series fixes redundant PLLA updates that happen for
each DAI link in the audio path. This helps to resolve DMIC clock
issue seen on Jetson TX2 platform.
The rpmsg pcm device is a device which should support
double buffering.
Found this issue with pipewire. When there is no
SNDRV_PCM_INFO_BATCH flag in driver, the pipewire will
set headroom to be zero, and because rpmsg pcm device
don't support residue report, when the latency setting
is small, the "delay" always larger than "target" in
alsa-pcm.c, that reading next period data is not
scheduled on time.
With SNDRV_PCM_INFO_BATCH flag in driver, the pipewire
will select a smaller period size for device, then
the task of reading next period data will be scheduled
on time.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1694414287-13291-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Replace the remaining dev_err() calls in probe() with dev_err_probe(),
to improve consistency.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230907171010.1447274-12-cristian.ciocaltea@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
