May 2022 - Alsa-devel - mailman.alsa-project.org

ASoC component/card relationship
by Pierre-Louis Bossart 04 May '22

04 May '22

Hi, In the existing ASoC code, there is a fixed mapping between ASoC card and component. A component relies on a ->card pointer that is set during the probe. A component cannot be used by or "bound to" more than one card [1] This has interesting impacts on how a codec or DSP driver need to be implemented. In the AVS series posted this week, multiple components are registered by the DSP driver, following an interface-based split. There's in addition a second-level split, where the logic is pushed further: the DSP driver partitions the SSP DAIs in different set of 'dai_driver's used by different components, which are in turn used by different cards. What is done in these patches is not wrong, and is probably the only solution to support a real-world platform with the existing ASoC code, but are the framework assumptions correct? In this example, the board-level information on which interface is used for what functionality trickles down to the lowest level of the DSP driver implementation. I believe this breaks to some extent the 'clean' split between platform and machine driver(s), and it's not quite aligned with the usual notion of register/probe used across frameworks, be it for drivers/clocks/you name it. A similar case could happen in a codec driver, if independent functionality such as headset and amplifier support was exposed by separate cards, that would in turn mandate that the codec driver exposed N components, each handling different functionality but the same type of DAI. An alternative approach would be that the DSP driver exposes all the possible DAIs that can be used, and the binding is refined to allow for more flexibility. I think it's really the individual DAI that cannot be used by more than one card. I figured I would ask on this mailing list if a) I am not mistaken on the component/card relationship and b) if this is by design, or if we want to clarify what a component is and what its restrictions might be. Thanks for your feedback/comments -Pierre [1] https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L1364

6 12

[PATCH v5 0/2] Add generic serial MIDI driver using serial bus API
by Daniel Kaehn 04 May '22

04 May '22

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. Changes in v5: - Reword and add to description in dt-binding - Change 'speed' dt property to 'current-speed' - Move MIDI output loop onto workqueue (since this could loop quite a while, if ALSA provides a continuous stream of bytes) - Add tx_state bit flags to snd_serial_generic struct - Safegard critical section in tx_work with atomic bit ops on tx_state - Switch operations on `filemode` to use atomic bit ops Changes in v4: - Fix regressed typo - Correct 3.84 kBaud -> 38.4 kBaud in DT & Kconfig (sorry about spam - noticed after sending v3 and didn't want to let the error sit around for too long) Changes in v3: - Replace use of snd_printk() with dev_* alternatives - Removed unnecessary initialization of err variables - Replaced instances of `== SERIAL_MODE_NOT_OPENED` with zero check - Loop on output_write to completely fill output buffer if data available - Depend on CONFIG_OF in Kconfig - Replace use of devm_kzalloc() with extra_size allocation in snd_devm_card_new() - Use module_serdev_device_driver() instead of module_init() and module_exit(0) Changes in v2: - Fix 'snd_serial_generic_write_wakeup' missing static keyword - Correct 3.125 kBaud > 31.25 kBaud in documentation for MIDI The need for this driver arose from a project using a Raspberry Pi4 which needed to receive and send raw MIDI with low latency. The pl011 UART used is not compatible with the existing serial MIDI driver made for u16550-style devices. Using a userspace program such as ttymidi to feed input from the TTY device to a virtual ALSA MIDI device was functional, but not ideal. I am not sure if a MIDI driver needing the mentioned 'hack' to clock 38.4 kBaud down to the standard MIDI baud is permissible in the mainline kernel, but am submitting nevertheless in case it is useful. To my knowledge, it doesn't seem that there would be any way for this driver to manually configure a serial port to 31.25 kBaud using the serial bus API (please correct me f I'm wrong). In my use case, I am actually configuring one port to run at 115.2 kBaud for faster communication with a custom onboard MIDI controller. Daniel Kaehn (2): dt-bindings: sound: Add generic serial MIDI device Add generic serial MIDI driver using serial bus API .../devicetree/bindings/sound/serialmidi.yaml | 46 +++ sound/drivers/Kconfig | 18 + sound/drivers/Makefile | 2 + sound/drivers/serial-generic.c | 377 ++++++++++++++++++ 4 files changed, 443 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/serialmidi.yaml create mode 100644 sound/drivers/serial-generic.c base-commit: 3e71713c9e75c34fc03f55ea86b381856ca952ee -- 2.33.0

2 5

Re: [PATCH] ASoC: Intel: sof_cs42l42: add support for adl_mx98360a_cs4242 and BT offload audio
by Cezary Rojewski 04 May '22

04 May '22

On 2022-05-04 2:24 PM, Terry Chen wrote: > This patch adds driver data for adl_mx98360a_cs4242 which supports > two max98360a speaker amplifiers on SSP1 and cs42l42 headphone codec > on SSP0 running on ADL platform. Also add the capability to machine > driver of creating DAI Link for BT offload. Although BT offload > always uses SSP2 port but we reserve the flexibility to assign > the port number in macro. Title's length seems off. Please shorten it a bit. Commit message formatting (line width) is not cohevise across the lines either. Another suggestion: skip redundant bits at the front e.g.: s/This patch adds/Add/. When adding new code (new functionality), it's good to plainly state: "To be able to do X we add capability Y". The last sentence in your message is a side note. It's good that you're being transparent here, my only advice is that you add a new line before such notes as these are not the main dish here, really. Title suggest you're doing two things here - adding support for some ADL configuration (1) and BT audio offload (2). Recommendation is to splitting non-atomic changes so each patch in the series answers single problem. > Signed-off-by: Terry Chen <terry_chen(a)wistron.corp-partner.google.com> > --- > sound/soc/intel/boards/sof_cs42l42.c | 88 ++++++++++++++++++- > .../intel/common/soc-acpi-intel-adl-match.c | 8 ++ > 2 files changed, 92 insertions(+), 4 deletions(-) > ... > @@ -278,6 +284,13 @@ static struct snd_soc_dai_link_component dmic_component[] = { > } > }; > > +static struct snd_soc_dai_link_component dummy_component[] = { > + { > + .name = "snd-soc-dummy", > + .dai_name = "snd-soc-dummy-dai", > + } > +}; Isn't there some SND_SOC_DAILINK_DEF() macro for that already? > static int create_spk_amp_dai_links(struct device *dev, > struct snd_soc_dai_link *links, > struct snd_soc_dai_link_component *cpus, > @@ -467,9 +480,52 @@ static int create_hdmi_dai_links(struct device *dev, > return -ENOMEM; > } > > +static int create_bt_offload_dai_links(struct device *dev, > + struct snd_soc_dai_link *links, > + struct snd_soc_dai_link_component *cpus, > + int *id, int ssp_bt) > +{ > + int ret = 0; Looks like there is no need for 'ret' variable here. > + > + /* bt offload */ > + if (!(sof_cs42l42_quirk & SOF_BT_OFFLOAD_PRESENT)) > + return 0; > + > + links[*id].name = devm_kasprintf(dev, GFP_KERNEL, "SSP%d-BT", > + ssp_bt); Current limit is 100. > + if (!links[*id].name) > + goto devm_err; This 'goto' statement seems redundant. I might be missing something but returning -ENOMEM should suffice. Label 'devm_err' does not do anything special anyway. > + > + links[*id].id = *id; > + links[*id].codecs = dummy_component; > + links[*id].num_codecs = ARRAY_SIZE(dummy_component); > + links[*id].platforms = platform_component; > + links[*id].num_platforms = ARRAY_SIZE(platform_component); > + > + links[*id].dpcm_playback = 1; > + links[*id].dpcm_capture = 1; > + links[*id].no_pcm = 1; > + links[*id].cpus = &cpus[*id]; > + links[*id].num_cpus = 1; > + > + links[*id].cpus->dai_name = devm_kasprintf(dev, GFP_KERNEL, > + "SSP%d Pin", > + ssp_bt); Ditto - limit 100. Applies to every single occurence below too. > + if (!links[*id].cpus->dai_name) > + goto devm_err; > + > + (*id)++; Are the parenthesis needed? Should be save to drop them. > + > + return 0; > + > +devm_err: > + return ret; Once 'ret/devm_err' situation is clarified, this block can be dropped. > +}

1 0

pcm: multi: return correct hwptr and avail from snd_pcm_multi_status()
by GitHub pull_request - opened 04 May '22

04 May '22

alsa-project/alsa-lib pull request #224 was opened from infmagic2047: Ensure the logic of snd_pcm_multi_status() is consistent with snd_pcm_multi_avail_update(). Signed-off-by: Yutao Yuan <infmagic2047reg(a)outlook.com> Request URL : https://github.com/alsa-project/alsa-lib/pull/224 Patch URL : https://github.com/alsa-project/alsa-lib/pull/224.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

alsa starts muted every reboot. /var/lib/alsa/asound.conf file does not exist
by GitHub issues - opened 04 May '22

04 May '22

alsa-project/alsa-utils issue #145 was opened from dontbejay: This is a multi distro issue. This has occured in EndeavourOS(XFCE), and Ubuntu(GNOME) as well. Currently I am on openSUSE(KDE) and alsa has the same issue. Every boot alsa has "Front" speakers Muted on my Sound Blaster Z. I have to go into alsamixer and unmute them. "sudo alsactl store" seems to do nothing to automatically restore settings on boot. Typing "sudo alsactl restore" Does fix the issue when it is used. http://alsa-project.org/db/?f=8354e69bed4316f798b2d8300f8109cb6b672d18 (the Front speaker has been manually unmuted) Issue URL : https://github.com/alsa-project/alsa-utils/issues/145 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Arch Linux Alsa Driver mic misconfigured 0000:00:1f.3
by GitHub issues - opened 04 May '22

04 May '22

alsa-project/alsa-firmware issue #6 was opened from WalterSmuts: Hi, I have a `Xiaomi Mi Laptop Pro X 15` running arch linux and the `pulseaudio-alsa` package seems to make sound work out of the box. Unfortunately it doesn't configure the mic properly. Attempting on a ubuntu live-usb I found the mic working. I ran the info script for both OS's (see below). My interpretation of the info dumped by the script is that ubuntu loads the `sof-audio-pci` drivers and arch linux seems to load some other intel drivers. Looking through the [arch wiki](https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture#AL… I see reference to some newer laptops requiring the sof drivers: > [sof-firmware](https://archlinux.org/packages/?name=sof-firmware) and/or [alsa-ucm-conf](https://archlinux.org/packages/?name=alsa-ucm-conf) are required for some newer laptop models (mainly since 2019) because they implement their drivers with firmware provided by the [Sound Open Firmware](https://www.sofproject.org/) project. So installing the `sof-firmware` package and restarting the laptop unfortunately still does not fix my issue. Looks to me like the old drivers are still taking preference. Can someone guide me in the right direction here? * [Working Ubuntu Info](http://alsa-project.org/db/?f=e66f34b60915348fa835bdde9e849119e103165… * [Non-working Arch Info](http://alsa-project.org/db/?f=1a4c03f9abd116c5a0b149e51e436f004fa2022… Issue URL : https://github.com/alsa-project/alsa-firmware/issues/6 Repository URL: https://github.com/alsa-project/alsa-firmware

2 1

[v4 00/18] ASoC: mediatek: Add support for MT8186 SoC
by Jiaxin Yu 03 May '22

03 May '22

This series of patches adds support for Mediatek AFE of MT8186 Soc. Patches are based on broonie tree "for-next" branch. Changes since v3: - [v4 09/18] - remove DEBUG_COEFF debugging code - [v4 10/18] - simplify the logic of the code - [v4 13/18] - split out the MT6366 bits into mt8186-mt6366-commom.c - fix build error of "error: 'struct dev_pm_info' has no member named 'runtime_error'" - fix bug of adda dai driver - add route for pcm interface channel 2. - [v4 15/18] - [v4 17/18] - commonize the configuration of the codecs - move MT6366 common bits into mt8186-mt6366-common.c Changes since v2: - add a new compatible string "mediatek,mt6366-sound" - modify the log level for simplicity - use dev_err_probe(...) instead of dev_err(...) in dev probe() - optimized the logic of some code - use BIT() and GENMASK() macros to descript the registers Thanks for AngeloGioacchino's careful reviews. Changes since v1: [v2 01/17] - add a new ID to the existing mt6358 codec driver [v2 03/17] - modify log level in DAPM events - use standard numeric control with name ending in Switch - return 1 when the value changed in mixer control's .get callback [v2 05/17] - ending in Switch to the standard on/off controls - change to "HW Gain 1 Volume" and "HW Gain 2 Volume" [v2 09/17] - return an error in the default case rather than just picking one of the behaviours when do .set_fmt - use the new defines that are _PROVIDER_MASK, _DAIFMT_CBP_CFP and _DAIFMT_CBC_CFC [v2 10/17] [v2 11/17] - the clock and gpio are aplit out into separate patches The source file's GPL comment use c++ style, and the header fils's GPL comment use c style. We have added "Switch" after the names of all the controls that just are simple on/off. Jiaxin Yu (18): ASoC: mediatek: mt6366: support for mt6366 codec dt-bindings: mediatek: mt6358: add new compatible for using mt6366 ASoC: mediatek: mt8186: support audsys clock control ASoC: mediatek: mt8186: support adda in platform driver ASoC: mediatek: mt8186: support hostless in platform driver ASoC: mediatek: mt8186: support hw gain in platform driver ASoC: mediatek: mt8186: support i2s in platform driver ASoC: mediatek: mt8186: support pcm in platform driver ASoC: mediatek: mt8186: support src in platform driver ASoC: mediatek: mt8186: support tdm in platform driver ASoC: mediatek: mt8186: support audio clock control in platform driver ASoC: mediatek: mt8186: support gpio control in platform driver ASoC: mediatek: mt8186: add platform driver dt-bindings: mediatek: mt8186: add audio afe document ASoC: mediatek: mt8186: add machine driver with mt6366, da7219 and max98357 dt-bindings: mediatek: mt8186: add mt8186-mt6366-da7219-max98357 document ASoC: mediatek: mt8186: add machine driver with mt6366, rt1019 and rt5682s dt-bindings: mediatek: mt8186: add mt8186-mt6366-rt1019-rt5682s document .../devicetree/bindings/sound/mt6358.txt | 4 +- .../bindings/sound/mt8186-afe-pcm.yaml | 175 + .../sound/mt8186-mt6366-da7219-max98357.yaml | 71 + .../sound/mt8186-mt6366-rt1019-rt5682s.yaml | 71 + sound/soc/codecs/mt6358.c | 1 + sound/soc/mediatek/Kconfig | 44 + sound/soc/mediatek/Makefile | 1 + sound/soc/mediatek/mt8186/Makefile | 22 + sound/soc/mediatek/mt8186/mt8186-afe-clk.c | 651 ++++ sound/soc/mediatek/mt8186/mt8186-afe-clk.h | 106 + sound/soc/mediatek/mt8186/mt8186-afe-common.h | 235 ++ .../soc/mediatek/mt8186/mt8186-afe-control.c | 261 ++ sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 244 ++ sound/soc/mediatek/mt8186/mt8186-afe-gpio.h | 19 + sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 3005 +++++++++++++++++ sound/soc/mediatek/mt8186/mt8186-audsys-clk.c | 150 + sound/soc/mediatek/mt8186/mt8186-audsys-clk.h | 15 + .../soc/mediatek/mt8186/mt8186-audsys-clkid.h | 45 + sound/soc/mediatek/mt8186/mt8186-dai-adda.c | 873 +++++ .../soc/mediatek/mt8186/mt8186-dai-hostless.c | 298 ++ .../soc/mediatek/mt8186/mt8186-dai-hw-gain.c | 236 ++ sound/soc/mediatek/mt8186/mt8186-dai-i2s.c | 1355 ++++++++ sound/soc/mediatek/mt8186/mt8186-dai-pcm.c | 423 +++ sound/soc/mediatek/mt8186/mt8186-dai-src.c | 695 ++++ sound/soc/mediatek/mt8186/mt8186-dai-tdm.c | 695 ++++ .../mediatek/mt8186/mt8186-interconnection.h | 69 + .../soc/mediatek/mt8186/mt8186-misc-control.c | 294 ++ .../mediatek/mt8186/mt8186-mt6366-common.c | 59 + .../mediatek/mt8186/mt8186-mt6366-common.h | 17 + .../mt8186/mt8186-mt6366-da7219-max98357.c | 1003 ++++++ .../mt8186/mt8186-mt6366-rt1019-rt5682s.c | 979 ++++++ sound/soc/mediatek/mt8186/mt8186-reg.h | 2913 ++++++++++++++++ 32 files changed, 15028 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/mt8186-afe-pcm.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8186-mt6366-da7219-max98357.yaml create mode 100644 Documentation/devicetree/bindings/sound/mt8186-mt6366-rt1019-rt5682s.yaml create mode 100644 sound/soc/mediatek/mt8186/Makefile create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-clk.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-clk.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-common.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-control.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-gpio.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-gpio.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-afe-pcm.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-audsys-clk.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-audsys-clk.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-audsys-clkid.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-adda.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-hostless.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-hw-gain.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-i2s.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-pcm.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-src.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-dai-tdm.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-interconnection.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-misc-control.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-common.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-common.h create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.c create mode 100644 sound/soc/mediatek/mt8186/mt8186-reg.h -- 2.25.1

4 31

[PATCH v4] ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload
by Peter Ujfalusi 03 May '22

03 May '22

It is possible to craft a topology where sof_get_control_data() would do out of bounds access because it expects that it is only called when the payload is bytes type. Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes. Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data. In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end. In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context. The data is pointing to the end of cdata struct, so it should never be null. Reported-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- Hi, Changes since v3: - Move the comment about validating data along with the code which validates the data (checks the SOF_ABI_MAGIC) Changes since v2: - Drop the cdata->data check against NULL as it is not a valid test and since we are in sof_get_control_data() the memory has been already allocated changes since v1: - adjust the payload size for non bytes controls by subtracting the size of the sof_ipc_ctrl_data struct, plus add comment to note this Regards, Peter sound/soc/sof/ipc3-topology.c | 39 +++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/sound/soc/sof/ipc3-topology.c b/sound/soc/sof/ipc3-topology.c index 572bcbfdb356..bc848f556b88 100644 --- a/sound/soc/sof/ipc3-topology.c +++ b/sound/soc/sof/ipc3-topology.c @@ -20,7 +20,8 @@ struct sof_widget_data { int ctrl_type; int ipc_cmd; - struct sof_abi_hdr *pdata; + void *pdata; + size_t pdata_size; struct snd_sof_control *control; }; @@ -784,16 +785,26 @@ static int sof_get_control_data(struct snd_soc_component *scomp, } cdata = wdata[i].control->ipc_control_data; - wdata[i].pdata = cdata->data; - if (!wdata[i].pdata) - return -EINVAL; - /* make sure data is valid - data can be updated at runtime */ - if (widget->dobj.widget.kcontrol_type[i] == SND_SOC_TPLG_TYPE_BYTES && - wdata[i].pdata->magic != SOF_ABI_MAGIC) - return -EINVAL; + if (widget->dobj.widget.kcontrol_type[i] == SND_SOC_TPLG_TYPE_BYTES) { + /* make sure data is valid - data can be updated at runtime */ + if (cdata->data->magic != SOF_ABI_MAGIC) + return -EINVAL; + + wdata[i].pdata = cdata->data->data; + wdata[i].pdata_size = cdata->data->size; + } else { + /* points to the control data union */ + wdata[i].pdata = cdata->chanv; + /* + * wdata[i].control->size is calculated with struct_size + * and includes the size of struct sof_ipc_ctrl_data + */ + wdata[i].pdata_size = wdata[i].control->size - + sizeof(struct sof_ipc_ctrl_data); + } - *size += wdata[i].pdata->size; + *size += wdata[i].pdata_size; /* get data type */ switch (cdata->cmd) { @@ -876,10 +887,12 @@ static int sof_process_load(struct snd_soc_component *scomp, */ if (ipc_data_size) { for (i = 0; i < widget->num_kcontrols; i++) { - memcpy(&process->data[offset], - wdata[i].pdata->data, - wdata[i].pdata->size); - offset += wdata[i].pdata->size; + if (!wdata[i].pdata_size) + continue; + + memcpy(&process->data[offset], wdata[i].pdata, + wdata[i].pdata_size); + offset += wdata[i].pdata_size; } } -- 2.36.0

3 2

[PATCH] ASoC: adau1761: Add ADAU1761-as-ADAU1361 compatibility mode
by Ricard Wanderlof 03 May '22

03 May '22

During probe, determine if the chip is in fact an ADAU1761 even though an ADAU1361 is specified, and perform additional operations to enable the ADAU1761 to behave as an ADAU1361, i.e. disregarding the DSP and setting up routing and PM transparently. This enables either chip to be mounted when an ADAU1361 is specified. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- sound/soc/codecs/adau1761.c | 86 +++++++++++++++++++++++++++++++++++-- sound/soc/codecs/adau17x1.c | 20 +++++++-- sound/soc/codecs/adau17x1.h | 1 + 3 files changed, 99 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/adau1761.c b/sound/soc/codecs/adau1761.c index fb006fc81653..8f887227981f 100644 --- a/sound/soc/codecs/adau1761.c +++ b/sound/soc/codecs/adau1761.c @@ -556,8 +556,6 @@ static const struct snd_soc_dapm_route adau1761_dapm_routes[] = { { "Left DAC", NULL, "Interpolator Resync Clock" }, { "Right DAC", NULL, "Interpolator Resync Clock" }, - { "DSP", NULL, "Digital Clock 0" }, - { "Slew Clock", NULL, "Digital Clock 0" }, { "Right Playback Mixer", NULL, "Slew Clock" }, { "Left Playback Mixer", NULL, "Slew Clock" }, @@ -569,6 +567,56 @@ static const struct snd_soc_dapm_route adau1761_dapm_routes[] = { { "Digital Clock 1", NULL, "SYSCLK" }, }; +static const struct snd_soc_dapm_route adau1761_dapm_dsp_routes[] = { + { "DSP", NULL, "Digital Clock 0" }, +}; + +static int adau1761_compatibility_probe(struct device *dev) +{ + struct adau *adau = dev_get_drvdata(dev); + struct regmap *regmap = adau->regmap; + int val, ret = 0; + + /* Only consider compatibility mode when ADAU1361 was specified. */ + if (adau->type != ADAU1361) + return 0; + + regcache_cache_bypass(regmap, true); + + /* + * This will enable the core clock and bypass the PLL, + * so that we can access the registers for probing purposes + * (without having to set up the PLL). + */ + regmap_write(regmap, ADAU17X1_CLOCK_CONTROL, + ADAU17X1_CLOCK_CONTROL_SYSCLK_EN); + + /* + * ADAU17X1_SERIAL_SAMPLING_RATE doesn't exist in non-DSP chips; + * reading it results in zero at all times, and write is a no-op. + * Use this register to probe for ADAU1761. + */ + regmap_write(regmap, ADAU17X1_SERIAL_SAMPLING_RATE, 1); + ret = regmap_read(regmap, ADAU17X1_SERIAL_SAMPLING_RATE, &val); + if (ret) + goto exit; + if (val != 1) + goto exit; + regmap_write(regmap, ADAU17X1_SERIAL_SAMPLING_RATE, 0); + ret = regmap_read(regmap, ADAU17X1_SERIAL_SAMPLING_RATE, &val); + if (ret) + goto exit; + if (val != 0) + goto exit; + + adau->type = ADAU1761_AS_1361; +exit: + /* Disable core clock after probing. */ + regmap_write(regmap, ADAU17X1_CLOCK_CONTROL, 0); + regcache_cache_bypass(regmap, false); + return ret; +} + static int adau1761_set_bias_level(struct snd_soc_component *component, enum snd_soc_bias_level level) { @@ -823,7 +871,11 @@ static int adau1761_component_probe(struct snd_soc_component *component) if (ret) return ret; - if (adau->type == ADAU1761) { + /* + * If we've got an ADAU1761, or an ADAU1761 operating as an + * ADAU1361, we need these non-DSP related DAPM widgets and routes. + */ + if (adau->type == ADAU1761 || adau->type == ADAU1761_AS_1361) { ret = snd_soc_dapm_new_controls(dapm, adau1761_dapm_widgets, ARRAY_SIZE(adau1761_dapm_widgets)); if (ret) @@ -834,7 +886,29 @@ static int adau1761_component_probe(struct snd_soc_component *component) if (ret) return ret; } - + /* + * These routes are DSP related and only used when we have a + * bona fide ADAU1761. + */ + if (adau->type == ADAU1761) { + ret = snd_soc_dapm_add_routes(dapm, adau1761_dapm_dsp_routes, + ARRAY_SIZE(adau1761_dapm_dsp_routes)); + if (ret) + return ret; + } + /* + * In the ADAU1761, by default, the AIF is routed to the DSP, whereas + * for the ADAU1361, the AIF is permanently routed to the ADC and DAC. + * Thus, if we have an ADAU1761 masquerading as an ADAU1361, + * we need to explicitly route the AIF to the ADC and DAC. + * For the ADAU1761, this is normally done by set_tdm_slot, but this + * function is not necessarily called during stream setup, so set up + * the compatible AIF routings here from the start. + */ + if (adau->type == ADAU1761_AS_1361) { + regmap_write(adau->regmap, ADAU17X1_SERIAL_INPUT_ROUTE, 0x01); + regmap_write(adau->regmap, ADAU17X1_SERIAL_OUTPUT_ROUTE, 0x01); + } ret = adau17x1_add_routes(component); if (ret < 0) return ret; @@ -919,6 +993,10 @@ int adau1761_probe(struct device *dev, struct regmap *regmap, if (ret) return ret; + ret = adau1761_compatibility_probe(dev); + if (ret) + return ret; + /* Enable cache only mode as we could miss writes before bias level * reaches standby and the core clock is enabled */ regcache_cache_only(regmap, true); diff --git a/sound/soc/codecs/adau17x1.c b/sound/soc/codecs/adau17x1.c index af05463af4ac..c0f44ecef606 100644 --- a/sound/soc/codecs/adau17x1.c +++ b/sound/soc/codecs/adau17x1.c @@ -334,6 +334,17 @@ static bool adau17x1_has_dsp(struct adau *adau) } } +/* Chip has a DSP but we're pretending it doesn't. */ +static bool adau17x1_has_disused_dsp(struct adau *adau) +{ + switch (adau->type) { + case ADAU1761_AS_1361: + return true; + default: + return false; + } +} + static bool adau17x1_has_safeload(struct adau *adau) { switch (adau->type) { @@ -516,10 +527,11 @@ static int adau17x1_hw_params(struct snd_pcm_substream *substream, regmap_update_bits(adau->regmap, ADAU17X1_CONVERTER0, ADAU17X1_CONVERTER0_CONVSR_MASK, div); - if (adau17x1_has_dsp(adau)) { + + if (adau17x1_has_dsp(adau) || adau17x1_has_disused_dsp(adau)) regmap_write(adau->regmap, ADAU17X1_SERIAL_SAMPLING_RATE, div); + if (adau17x1_has_dsp(adau)) regmap_write(adau->regmap, ADAU17X1_DSP_SAMPLING_RATE, dsp_div); - } if (adau->sigmadsp) { ret = adau17x1_setup_firmware(component, params_rate(params)); @@ -663,7 +675,7 @@ static int adau17x1_set_dai_tdm_slot(struct snd_soc_dai *dai, switch (slot_width * slots) { case 32: - if (adau->type == ADAU1761) + if (adau->type == ADAU1761 || adau->type == ADAU1761_AS_1361) return -EINVAL; ser_ctrl1 = ADAU17X1_SERIAL_PORT1_BCLK32; @@ -738,7 +750,7 @@ static int adau17x1_set_dai_tdm_slot(struct snd_soc_dai *dai, regmap_update_bits(adau->regmap, ADAU17X1_SERIAL_PORT1, ADAU17X1_SERIAL_PORT1_BCLK_MASK, ser_ctrl1); - if (!adau17x1_has_dsp(adau)) + if (!adau17x1_has_dsp(adau) && !adau17x1_has_disused_dsp(adau)) return 0; if (adau->dsp_bypass[SNDRV_PCM_STREAM_PLAYBACK]) { diff --git a/sound/soc/codecs/adau17x1.h b/sound/soc/codecs/adau17x1.h index 98a3b6f5bc96..5e58abfffc3d 100644 --- a/sound/soc/codecs/adau17x1.h +++ b/sound/soc/codecs/adau17x1.h @@ -10,6 +10,7 @@ enum adau17x1_type { ADAU1361, ADAU1761, + ADAU1761_AS_1361, ADAU1381, ADAU1781, }; -- 2.20.1 -- Ricard Wolf Wanderlof ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 1

[PATCH] ASoC: dapm: Don't fold register value changes into notifications
by Mark Brown 03 May '22

03 May '22

DAPM tracks and reports the value presented to the user from DAPM controls separately to the register value, these may diverge during initialisation or when an autodisable control is in use. When writing DAPM controls we currently report that a change has occurred if either the DAPM value or the value stored in the register has changed, meaning that if the two are out of sync we may appear to report a spurious event to userspace. Since we use this folded in value for nothing other than the value reported to userspace simply drop the folding in of the register change. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-dapm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index ca917a849c42..869c76506b66 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3437,7 +3437,6 @@ int snd_soc_dapm_put_volsw(struct snd_kcontrol *kcontrol, update.val = val; card->update = &update; } - change |= reg_change; ret = soc_dapm_mixer_update_power(card, kcontrol, connect, rconnect); @@ -3539,7 +3538,6 @@ int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol, update.val = val; card->update = &update; } - change |= reg_change; ret = soc_dapm_mux_update_power(card, kcontrol, item[0], e); -- 2.30.2

1 1