This API was required for CLSA0100 laptop, which did not
have correct properties inside ACPI. The required values
are now hardcoded inside the driver so this is no longer
needed.
Without this api, there CLSA0100 can now use the generic
cs35l41 fixup, like the other laptops.
All other laptops will read the Speaker Position from
ACPI and set the channel map from within the driver.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220509214703.4482-4-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After a build regression report, I took a look at possible users of
CONFIG_ISA_DMA_API on m68k and found none, which Greg confirmed. The
CONFIG_GENERIC_ISA_DMA option in turn is only needed to implement
ISA_DMA_API, and is clearly not used on the platforms with ISA support.
The CONFIG_ISA support for AMIGA_PCMCIA is probably also unneeded,
but this is less clear. Unlike other PCMCIA implementations, this one
does not use the drivers/pcmcia subsystem at all and just supports
the "apne" network driver. When it was first added, one could use
ISA drivers on it as well, but this probably broke at some point.
With no reason to keep this, let's just drop the corresponding files
and prevent the remaining ISA drivers that use this from getting built.
The remaining definitions in asm/dma.h are used for PCI support.
Link: https://lore.kernel.org/lkml/9e5ee1c3-ca80-f343-a1f5-66f3dd1c0727@linux-m68k.org/
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: Greg Ungerer <gerg@linux-m68k.org>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Merge series from Ranjani Sridharan <ranjani.sridharan@linux.intel.com>:
The patches in this series add support for FW loading for IPC4 in the SOF
driver.
sound/soc/codecs/max98396.c: In function ‘max98396_i2c_probe’:
sound/soc/codecs/max98396.c:1555:25: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_regulator_get_optional’? [-Werror=implicit-function-declaration]
max98396->reset_gpio = devm_gpiod_get_optional(&i2c->dev,
^~~~~~~~~~~~~~~~~~~~~~~
devm_regulator_get_optional
sound/soc/codecs/max98396.c:1556:23: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’?
"reset", GPIOD_OUT_HIGH);
^~~~~~~~~~~~~~
GPIOF_INIT_HIGH
sound/soc/codecs/max98396.c:1556:23: note: each undeclared identifier is reported only once for each function it appears in
sound/soc/codecs/max98396.c:1565:3: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration]
gpiod_set_value_cansleep(max98396->reset_gpio, 0);
^~~~~~~~~~~~~~~~~~~~~~~~
gpio_set_value_cansleep
cc1: all warnings being treated as errors
Include header file <linux/gpio/consumer.h>
Fixes: b585811367 ("ASoC: max98396: add amplifier driver")
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Link: https://lore.kernel.org/r/20220512074640.75550-2-tanghui20@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Zheyu Ma <zheyuma97@gmail.com>:
These drivers mishandle the regulator resource in the probe function,
failing to disable the regulator for probing failure.
Generic serial MIDI driver adding support for using serial devices
compatible with the serial bus as raw MIDI devices, allowing using
additional serial devices not compatible with the existing
serial-u16550 driver. Supports only setting standard serial baudrates on
the underlying serial device; however, the underlying serial device can
be configured so that a requested 38.4 kBaud is actually the standard MIDI
31.25 kBaud. Supports DeviceTree configuration.
Signed-off-by: Daniel Kaehn <kaehndan@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220509145933.1161526-3-kaehndan@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
of_find_device_by_node() takes reference, we should use put_device()
to release it. when devm_kzalloc() fails, it doesn't have a
put_device(), it will cause refcount leak.
Add missing put_device() to fix this.
Fixes: 6a5f850aa8 ("ASoC: fsl: Add imx-hdmi machine driver")
Fixes: f670b274f7 ("ASoC: imx-hdmi: add put_device() after of_find_device_by_node()")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220511052740.46903-1-linmq006@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
With dual fifo enabled, the case that recording mono sound
in the background, playback mono sound twice in parallal,
at second time playback sound may distort, the possible
reason is using dual fifo to playback mono sound is not
recommended.
This patch is to provide a option to use multi fifo script,
which can be dynamically configured as one fifo or two fifo
mode.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1652183808-3745-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
Two minor changes to enable DMIC and capture for CS35L41, and one new
configuration for AlderLake hardware.
Some board revisions of the Framework Laptop have an ALC295 with a
disconnected or faulty headset mic presence detect.
The "dell-headset-multi" fixup addresses this issue, but also enables an
inoperative "Headphone Mic" input device whenever a headset is
connected.
Adding a new quirk chain specific to the Framework Laptop resolves this
issue. The one introduced here is based on the System76 "no headphone
mic" quirk chain.
The VID:PID f111:0001 have been allocated to Framework Computer for this
board revision.
Revision history:
- v2: Moved to a custom quirk chain to suppress the "Headphone Mic"
pincfg.
Signed-off-by: Dustin L. Howett <dustin@howett.net>
Link: https://lore.kernel.org/r/20220511010759.3554-1-dustin@howett.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On i.MX8Plus there are two updates for micfil module.
One is that the output format is S32_LE, only the 24 more
significative bits have information, the other bits are always
zero. Add 'formats' variable in soc data to distinguish the
format on different platform.
Another is that the fifo depth is 32 entries.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1652087663-1908-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:
Before componentisation any part registered as a CODEC would have
automatically supported both little and big endian, ie. the core
would duplicate any supported LE or BE PCM format to support the other
endian as well. As componentisation removed the distinction between
CODEC drivers and platform drivers, a flag was added to specify
if this behaviour is required for a particular component. However,
as most systems tend to use little endian the absence of the flag
is rarely noticed. Also the naming of the flag "endianness" is a
little unobvious as to if it should be applied to a particular
component.
This series adds a comment to better explain the meaning of the
flag and then tidys up the usage of the flag. A couple of uses
of the flag are removed where is has been used inappropriately
on the CPU side of the DAI link, this is clearly not valid in the
cases it has been used, and I suspect never would be valid. Then
some redundant formats are removed, since they would be covered by
existing endianness flags. And finally a bunch of devices that are
missing the flag have it added.
It is worth noting that since componenisation there are now a couple
of cases where it is not entire clear to me that the flag should
be applied to all CODECs as it was before. In those cases I haven't
updated the driver to add the flag and they are outlined here:
1) Build into the AP CODECs, these are actual silicon inside the main
processor and they typically receive audio directly from an internal
bus. It is not obvious to me that these can happily ignore endian. On
the CODEC side these include: jz4725b.c, jz4760.c, jz4770.c,
rk3328_codec.c, lpass-va-macro.c, lpass-rx-macro.c, lpass-tx-macro.c,
lpass-wsa-macro.c. There are also some examples of this scattered
around the various platform support directories in sound/soc.
2) Devices behind non-audio buses, SPI just moves bits and doesn't
really define an endian for audio data on the bus. Thus it seems the
CODEC probably can care about the endian. The only devices that fall
into this group (mostly for AoV) are: rt5514-spi.c, rt5677-spi.c,
cros_ec_codec.c (only the AoV).
3) CODECs with no DAIs, these could specify the flag and plenty of
them do; CODECs from the initial conversion to componentisation. But
the flag makes no difference here since there is nothing for it to
apply to. This includes purely analogue CODECs: aw8738.c, ssm2305.c,
tpa6130a2.c, tda7419.c, max9759.c, max9768.c, max9877.c, lm4857.c,
simple-mux.c, simple-amplifier.c. And devices that only do jack
detection: ts3a227e.c, mt6359-accdet.c.
If there are any opinions on adding the flag to any of those three
groups they would be greatfully received. But I am leaning towards
leaving 1,2 without endianness flags since it feels inappropriate,
and removing the endian flag from devices in catagory 3 that already
have it. Assuming no one objects to that I will do a follow up
series for that.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
Hi,
The current IPC client infrastructure can only be used with IPC3.
This series carries updates for the core side of the client support to handle
IPC4 messages and updates the ipc message injector to be usable with IPC4.
The IPC flood test is only supported by SOF_IPC (IPC3), we are not going to
create the aux device for it at all if the firmware is using IPC4.
Regards,
Peter
---
Peter Ujfalusi (8):
ASoC: SOF: sof-client: Add API to get the maximum IPC payload size
ASoC: SOF: ipc-msg-injector: Query the maximum IPC payload size
ASoC: SOF: sof-client-probes: Query the maximum IPC payload size
ASoC: SOF: sof-client: Add API to get the ipc_type
ASoC: SOF: sof-client: Add support IPC4 message sending
ASoC: SOF: ipc-msg-injector: Separate the message sending
ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages
ASoC: SOF: sof-client: IPC flood test can only work with SOF_IPC
sound/soc/sof/sof-client-ipc-msg-injector.c | 181 ++++++++++++++++++--
sound/soc/sof/sof-client-probes.c | 5 +-
sound/soc/sof/sof-client.c | 66 ++++++-
sound/soc/sof/sof-client.h | 2 +
4 files changed, 227 insertions(+), 27 deletions(-)
--
2.36.0
sound/soc/mediatek/mt8195/mt8195-mt6359.c:1639:32: warning: ‘mt8195_mt6359_max98390_rt5682_card’ defined but not used [-Wunused-variable]
1639 | static struct mt8195_card_data mt8195_mt6359_max98390_rt5682_card = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/mediatek/mt8195/mt8195-mt6359.c:1634:32: warning: ‘mt8195_mt6359_rt1011_rt5682_card’ defined but not used [-Wunused-variable]
1634 | static struct mt8195_card_data mt8195_mt6359_rt1011_rt5682_card = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/mediatek/mt8195/mt8195-mt6359.c:1629:32: warning: ‘mt8195_mt6359_rt1019_rt5682_card’ defined but not used [-Wunused-variable]
1629 | static struct mt8195_card_data mt8195_mt6359_rt1019_rt5682_card = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since all users of this driver do need CONFIG_OF anyway, there is no
need to save a few bytes on kernel builds while CONFIG_OF disabled, so
just remove the #ifdef to fix this warning.
Fixes: 86a6b9c9df ("ASoC: mediatek: mt8195: add machine support for max98390 and rt5682")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20220509120918.9000-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
