ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link
Remove the extra 'mt8195-afe-pcm-dai' component, register the DAI
drivers to the main AFE component, and rework the DAI linking between
the headset codec (RT5682/RT5682S) and the TDM interface in the probe
function to stop assigning name, relying on the of_node of the codec.
Also replace the COMP_DUMMY codec entry with a COMP_EMPTY for the
ETDM2_IN and remove it entirely from ETDM1_OUT to fix the registration
flow for this sound card.
While at it, since we also need to swap the codec init function from
ETDM2_IN to ETDM1_OUT, remove the static assignment of both `ops` and
`init` for both, as we now assign these dynamically during probe.
ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing
Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy
Component via COMP_DUMMY()"), the dai_name field is only populated for
dummy components after the card is registered. This causes a null
pointer dereference in the mt8192-mt6359 sound card driver's probe
function when searching for a dai_name among all the card's dai links.
Verify that the dai_name is non-null before passing it to strcmp. While
at it, also check that there's at least one codec.
Peter Ujfalusi [Mon, 8 Jan 2024 09:48:42 +0000 (11:48 +0200)]
ASoC: Intel: bxt_rt298: Fix kernel ops due to COMP_DUMMY change
The change to avoid dummy components will leave the component name and
dai_name NULL which will cause NULL dereference when trying to access to
it in the machine driver when applying fixups.
Peter Ujfalusi [Mon, 8 Jan 2024 09:48:41 +0000 (11:48 +0200)]
ASoC: Intel: bxt_da7219_max98357a: Fix kernel ops due to COMP_DUMMY change
The change to avoid dummy components will leave the component name and
dai_name NULL which will cause NULL dereference when trying to access to
it in the machine driver when applying fixups.
ChiYuan Huang [Fri, 29 Dec 2023 01:46:02 +0000 (09:46 +0800)]
ASoC: codecs: rtq9128: Fix TDM enable and DAI format control flow
To enable TDM mode, the current control flow limits the function
calling order should be 'set_tdm_slot->set_dai_fmt'. But not all
platform sound card like as simeple card to follow this design.
To bypass this limit, adjust the DAI format setting in runtime
'hw_param' callback.
Shenghao Ding [Thu, 4 Jan 2024 14:57:19 +0000 (22:57 +0800)]
ASoC: tas2781: Add tas2563 into driver
Move tas2563 from tas2562 driver to tas2781 driver to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to downloading
corresponding firmware.
Shenghao Ding [Thu, 4 Jan 2024 14:57:18 +0000 (22:57 +0800)]
ASoC: tas2781: Add tas2563 into header file for DSP mode
Move tas2563 from tas2562 header file to tas2781 header file to unbind
tas2563 from tas2562 driver code and bind it to tas2781 driver code,
because tas2563 only work in bypass-DSP mode with tas2562 driver. In
order to enable DSP mode for tas2563, it has been moved to tas2781
driver. As to the hardware part, such as register setting and DSP
firmware, all these are stored in the binary firmware. What tas2781
drivder does is to parse the firmware and download it to the chip,
then power on the chip. So, tas2781 driver can be resued as tas2563
driver. Only attention will be paid to downloading corresponding firmware.
Shenghao Ding [Thu, 4 Jan 2024 14:57:17 +0000 (22:57 +0800)]
ASoC: tas2562: move tas2563 from tas2562 driver to tas2781 driver
Move tas2563 from tas2562 driver to tas2781 driver to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to
downloading corresponding firmware.
Shenghao Ding [Thu, 4 Jan 2024 14:57:16 +0000 (22:57 +0800)]
ASoC: dt-bindings: move tas2563 from tas2562.yaml to tas2781.yaml
Move tas2563 from tas2562.yaml to tas2781.yaml to unbind tas2563 from
tas2562 driver code and bind it to tas2781 driver code, because tas2563
only work in bypass-DSP mode with tas2562 driver. In order to enable DSP
mode for tas2563, it has been moved to tas2781 driver. As to the hardware
part, such as register setting and DSP firmware, all these are stored in
the binary firmware. What tas2781 drivder does is to parse the firmware
and download it to the chip, then power on the chip. So, tas2781 driver
can be resued as tas2563 driver. Only attention will be paid to
downloading corresponding firmware.
Duje Mihanović [Tue, 26 Dec 2023 20:00:24 +0000 (21:00 +0100)]
ASoC: pxa: sspa: Don't select SND_ARM
On ARM64 platforms, SND_ARM shouldn't be selectable, but enabling
SND_SOC_MMP_SSPA will enable SND_ARM and cause build errors if
SND_ARMAACI is enabled (which it is by default). Since the SSPA driver
doesn't depend on AACI nor PXA2XX_LIB, remove this false dependency.
Shengjiu Wang [Wed, 27 Dec 2023 09:27:43 +0000 (17:27 +0800)]
ASoC: SOF: imx: Add SNDRV_PCM_INFO_BATCH flag
The sof imx 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 sof 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.
Hans de Goede [Sun, 26 Nov 2023 21:40:24 +0000 (22:40 +0100)]
ASoC: Intel: cht_bsw_rt5645: Set card.components string
Set the card.components string using the new rt5645_components() helper
which returns a components string based on the DMI quirks inside the
rt5645 codec driver.
Hans de Goede [Sun, 26 Nov 2023 21:40:22 +0000 (22:40 +0100)]
ASoC: rt5645: Add a rt5645_components() helper
The rt5645 codec driver uses DMI quirks to configure the DMIC data-pins,
which means that it knows which DMIC interface is used on a specific
device.
ATM we duplicate this DMI matching inside the UCM profiles to select
the right DMIC interface. Add a rt5645_components() helper which the
machine-driver can use to set the components string of the card so
that UCM can get the info from the components string.
This way we only need to add new DMI quirks in one place.
Hans de Goede [Sun, 26 Nov 2023 21:40:19 +0000 (22:40 +0100)]
ASoC: rt5645: Add platform-data for Acer Switch V 10
The Acer Switch V 10 uses the default jack-detect mode 3, but instead of
using an analog microphone it is using a DMIC on dmic-data-pin 1,
like other models following Intel's Braswell's reference design.
Add a DMI quirk pointing to the intel_braswell_platform_data for this.
Hans de Goede [Sun, 26 Nov 2023 21:40:18 +0000 (22:40 +0100)]
ASoC: rt5645: Drop double EF20 entry from dmi_platform_data[]
dmi_platform_data[] first contains a DMI entry matching:
DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
and then contains an identical entry except for the match being:
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
Since these are partial (non exact) DMI matches the first match
will also match any board with "EF20EA" in their DMI product-name,
drop the second, redundant, entry.
Document the SM8650 sound card using the SM8450 fallback
and add the SM8650 compatible to the sc8280xp sound card
driver to use the sm8650 card driver_name like SM8450 & SM8550.
Add dt-bindings for es8326 and codec es8326 support.
Remove duplicate code, commonize headset codec init/exit API.
At the same time, Enable dual amp max98390 for rt5682s.
This patch series provides several fixes and improvements to AMD ACP drivers
targeting the Vangogh platform, as found on the Valve's new Steam Deck OLED.
Although in theory the board should have been supported by both SOF and legacy
ACP drivers, as of next-20231208 the audio seems to be completely broken.
Please note this only restores the legacy support, while SOF will be handled in
a separate series.
Neil Armstrong [Tue, 19 Dec 2023 13:23:37 +0000 (14:23 +0100)]
ASoC: dt-bindings: qcom,lpass-va-macro: remove spurious contains in if statement
Remove this spurious "contains" which causes the bindings check of
qcom,sm8450-lpass-va-macro compatible to fail with:
codec@33f0000: clocks: [[156, 57, 1], [156, 102, 1], [156, 103, 1], [156, 70, 1]] is too long
from schema $id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#
codec@33f0000: clock-names: ['mclk', 'macro', 'dcodec', 'npl'] is too long
from schema $id: http://devicetree.org/schemas/sound/qcom,lpass-va-macro.yaml#
Seems the double "contains" was considered as valid by the tool but broke
the entire if statements.
Even though we already have common asoc_dummy_dlc for dummy
Component / DAI, this macro will re-create new dummy dlc.
Some drivers defines many dai_link info via SND_SOC_DAILINK_DEFS(),
this means many dummy dlc also will be re-created. This is waste of
memory.
If we can use existing common asoc_dummy_dlc at (X),
we can avoid to re-creating dummy dlc, then, we can save the memory.
At that time, we want to keep existing code as much as possible, because
too many drivers are using this macro. But because of its original style,
using common asoc_dummy_dlc from it is very difficult or impossible.
So let's change the mind. The macro is used like below
This is very special settings that normal use usually not do,
but new macro do.
We can find this special settings on soc-core.c and fill it as
"dummy DAI" (= asoc_dummy_dlc). By this tric, we can avoid to re-create
dummy dlc and save the memory.
This patch add tric at COMP_DUMMY() and add snd_soc_fill_dummy_dai()
to fill dummy DAI.
Gergo Koteles [Thu, 14 Dec 2023 00:25:39 +0000 (01:25 +0100)]
ASoC: tas2781: add support for FW version 0x0503
Layout of FW version 0x0503 is compatible with 0x0502.
Already supported by TI's tas2781-linux-driver tree.
https://git.ti.com/cgit/tas2781-linux-drivers/tas2781-linux-driver/
Fix few trivial code style issues, pointed out by checkpatch, so they do
not get copied to new code (when old code is used as template):
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
WARNING: function definition argument 'struct platform_device *' should also have an identifier name
ERROR: code indent should use tabs where possible
WARNING: please, no spaces at the start of a line
WARNING: Missing a blank line after declarations
WARNING: unnecessary whitespace before a quoted newline
Chancel Liu [Mon, 4 Dec 2023 11:15:32 +0000 (19:15 +0800)]
ASoC: soc-pcm.c: Complete the active count for components without DAIs
Some components like platforms don't have DAIs. If the active count of
these components is ignored pinctrl may be wrongly selected between
default and sleep state. So need to increment or decrement the active
count for components without DAIs to avoid it.
Document bindings for the Qualcomm X1E80100 SoC sound card. The
bindings are the same as for other newer Qualcomm ADSP sound cards, thus
keep them in existing qcom,sm8250.yaml file, even though Linux driver is
separate.
Add sound machine driver for the soundcards on Qualcomm X1E80100 SoC,
supporting up to four channel audio playback over Soundwire bus. The
driver is based on existing sc8280xp.c driver.
ASoC: amd: vangogh: Switch to {RUNTIME,SYSTEM_SLEEP}_PM_OPS
Replace the old SET_{RUNTIME,SYSTEM_SLEEP}_PM_OPS() helpers with their
modern alternatives and drop the now unnecessary __maybe_unused
qualifier in the suspend and resume functions.
Additionally, make use of pm_ptr() to ensure the PM ops are dropped when
building with CONFIG_PM disabled.
ASoC: amd: vangogh: Allow probing ACP PCI when SOF is disabled
Since commit e89f45edb747 ("ASoC: amd: vangogh: Add check for acp config
flags in vangogh platform"), the Vangogh ACP PCI driver could not be used
anymore for boards which happen to have a matching entry in acp-config
list.
Commit f18818eb0dbe ("ASoC: amd: vangogh: Add condition check for acp
config flag") slightly changed the behaviour to permit loading the
driver if AMD_LEGACY flag is set. However, for AMD_SOF flag the probing
is still denied, even if SOF support is disabled in kernel
configuration.
While this helps preventing conflicts between SOF and generic ACP
drivers, there are cases where a fallback to the generic non-SOF support
would still be needed or useful, e.g. SOF firmware is not available or
doesn't work properly, SOF driver is broken or doesn't provide full
support for a particular hardware, or simply for testing/debugging the
alternative solution. A real-life example is Steam Deck OLED, which
works with both drivers.
Prevent returning from probe() when ACP config indicates SOF support for
the current board *and* the Vangogh SOF driver is not enabled in kernel
configuration.
ASoC: amd: vangogh: Drop conflicting ACPI-based probing
The Vangogh machine driver variant based on the MAX98388 amplifier, as
found on Valve's Steam Deck OLED, relies on probing via an ACPI match
table. This worked fine until commit 197b1f7f0df1 ("ASoC: amd: Add new
dmi entries to config entry") enabled SOF support for the target machine
(i.e. Galileo product), causing the sound card to enter the deferred
probe state indefinitely:
The issue is related to commit e89f45edb747 ("ASoC: amd: vangogh: Add
check for acp config flags in vangogh platform"), which tries to
mitigate potential conflicts between SOF and generic ACP Vangogh
drivers, due to sharing the PCI device IDs.
However, the solution is effective only if the machine driver is
directly probed by pci-acp5x through platform_device_register_full().
Hence, remove the conflicting ACPI based probing and rely exclusively on
DMI quirks for sound card setup.
Linus Walleij [Thu, 14 Dec 2023 13:15:45 +0000 (14:15 +0100)]
ASoC: tegra: tegra20_ac97: Convert to use GPIO descriptors
The Tegra20 AC97 driver is using the legacy GPIO APIs in
<linux/of_gpio.h> and <linux/gpio.h> to obtain GPIOs for reset
and sync.
Convert it over and fix the polarity error on the RESET line
in the process: this reset line is clearly active low. Just
fix the one in-tree device tree site using it at the same
time.
Rander Wang [Fri, 15 Dec 2023 08:31:01 +0000 (16:31 +0800)]
ASoC: SOF: IPC4: query fw_context_save feature from fw
Driver queries fw_context_save feature when fw is ready and can skip
library reload with this feature since library is saved in persistent
memory. The default value of fw_context_save is true unless fw reports
false.
Daniel Baluta [Tue, 28 Nov 2023 08:11:19 +0000 (10:11 +0200)]
ASoC: dt-bindings: audio-graph-port: Document new DAI link flags playback-only/capture-only
Document new playback-only and capture-only flags which can be used
when dai link can only support just one direction: playback or capture
but not both.
Charles Keepax [Mon, 11 Dec 2023 16:00:19 +0000 (16:00 +0000)]
ASoC: cs42l43: Allow HP amp to cool off after current limit
Whilst occasional current limiting is fine, constant current limiting
should be avoided. Add a back off system that will disable the
headphone amp, if a lot of current limiting is seen in a short window
of time.
Add support four channel streams. Map channel 3 and 4 to left/right
surround ("quad(side)" from ffmpeg standard channel list) to match what
is in qdsp6/q6dsp-common.c driver.
Move code assigning channel mapping values to a common helper function.
This simplifies three out of four cases, with the last case using
incompatible type (uint16_t array instead of uint8_t array).
This converts the remaining Wolfson ASoC codecs to
use GPIO descriptors.
These Wolfson codecs are mostly used with different
Samsung S3C (especially Cragganmore 6410) board files,
so the in-tree users are fixed up in the process.
Linus Walleij [Fri, 8 Dec 2023 10:09:29 +0000 (11:09 +0100)]
ASoC: wm8996: Convert to GPIO descriptors
This converts the WM8996 codec to use GPIO descriptors, an a similar
way to WM5100.
The driver is instantiating a GPIO chip named wm8996, and we get
rid of the base address for the GPIO chip from the platform data and
just use dynamic numbering. Move base and ngpio into the static
gpio_chip template.
Fix up the only in-tree user which is the Cragganmore 6410 module.
Linus Walleij [Fri, 8 Dec 2023 10:09:28 +0000 (11:09 +0100)]
ASoC: wm5100: Convert to GPIO descriptors
This converts the WM5100 codec to use GPIO descriptors, a pretty
straight-forward conversion with the following peculiarities:
- The driver is instantiating a GPIO chip named wm5100, and the
headphone polarity detection GPIO is lifted from there. We add
this to the GPIO descriptor table as well, and we can then get
rid of also the base address for the GPIO chip from the
platform data and just use dynamic numbering.
- Fix up the only in-tree user which is the Cragganmore 6410
module.
Linus Walleij [Fri, 8 Dec 2023 10:09:27 +0000 (11:09 +0100)]
ASoC: wm2200: Convert to GPIO descriptors
This converts the WM2200 codec to use GPIO descriptors.
This is a pretty straight-forward conversion, and it also
switches over the single in-tree user in the S3C
Cragganmore module for S3C 6410.
This coded does not seem to get selected or be selectable
through Kconfig, I had to hack another soundcard Kconfig
entry to select it for compile tests.
Linus Walleij [Fri, 8 Dec 2023 10:09:26 +0000 (11:09 +0100)]
ASoC: wm1250-ev1: Convert to GPIO descriptors
This converts the WM1250-EV1 codec to use GPIO descriptors.
It turns out that the platform data was only used to pass some
global GPIO numbers from a board file, so we get rid of this
and also switch over the single in-tree user in the S3C
Cragganmore module for S3C 6410.
The driver obtains two GPIO lines named OSR and master and just
pull them low, we leave this behaviour as it was.
Linus Walleij [Fri, 8 Dec 2023 10:09:25 +0000 (11:09 +0100)]
ASoC: wm0010: Convert to GPIO descriptors
This converts the WM0010 codec to use GPIO descriptors.
It's a pretty straight-forward conversion also switching over
the single in-tree user in the S3C Cragganmore module
for S3C 6410.
Dan Carpenter [Mon, 4 Dec 2023 12:42:07 +0000 (15:42 +0300)]
ASoC: audio-graph-card2: fix off by one in graph_parse_node_multi_nm()
The > comparison should be >= to avoid writing one element beyond the end
of the dai_link->ch_maps[] array. The dai_link->ch_maps[] array is
allocated in graph_parse_node_multi() and it has "nm_max" elements.
Modify acp config flag read logic from ACP v7.0 onwards.
Instead of reading from DMI table match entry, read the
config flag value from BIOS ACPI table.
This will remove updating DMI table when new platform support
is added.
Use FLAG_AMD_LEGACY_ONLY_DMIC flag as default one.
Peter Ujfalusi [Thu, 7 Dec 2023 09:54:25 +0000 (11:54 +0200)]
ASoC: SOF: Intel: hda-codec: Delay the codec device registration
The current code flow is:
1. snd_hdac_device_register()
2. set parameters needed by the hdac driver
3. request_codec_module()
the hdac driver is probed at this point
During boot the codec drivers are not loaded when the hdac device is
registered, it is going to be probed later when loading the codec module,
which point the parameters are set.
On module remove/insert
rmmod snd_sof_pci_intel_tgl
modprobe snd_sof_pci_intel_tgl
The codec module remains loaded and the driver will be probed when the
hdac device is created right away, before the parameters for the driver
has been configured:
1. snd_hdac_device_register()
the hdac driver is probed at this point
2. set parameters needed by the hdac driver
3. request_codec_module()
will be a NOP as the module is already loaded
Move the snd_hdac_device_register() later, to be done right before
requesting the codec module to make sure that the parameters are all set
before the device is created:
1. set parameters needed by the hdac driver
2. snd_hdac_device_register()
3. request_codec_module()
This way at the hdac driver probe all parameters will be set in all cases.
projects / linux.git / log