Commit Graph

3603 Commits

Author SHA1 Message Date
Takashi Iwai
21634f0f30 Merge branch 'topic/hda-pci-ids' into for-next
Pull cleanup of HD-audio PCI IDs.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-18 14:24:56 +02:00
Amadeusz Sławiński
76e3a42464 ASoC: Intel: Skylake: Use global PCI match macro
Instead of using local macro to match PCI device, use global one. As
Apollolake is Broxton-P successor that made it to the market, be precise
and use APL shortcut. IS_CFL() macro is dropped as it is unused.

Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230717114511.484999-9-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-18 14:22:19 +02:00
Amadeusz Sławiński
cab8cf497d ALSA: hda: Add controller matching macros
Some HDA controllers require additional handling, so there are macros to
match them, however those are spread across multiple files. Add them all
in one place, so they can be reused.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230717114511.484999-6-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-18 14:22:17 +02:00
Oswald Buddenhagen
c435d375fd ALSA: emu10k1: set the "no filtering" bits on PCM voices on Audigy
Given that the filter is already set to neutral for PCM voices, the
only observable effect is that the Z1/Z2/FXBUS registers don't have a
stray bit set for negative numbers anymore. The bit is below the ones
significant for output, but it would mess with 32-bit sample
recombination, which we intend to add.

kX-project does that, but I had to figure out myself why.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230715160802.326872-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-17 09:29:07 +02:00
Oswald Buddenhagen
c960b012ec ALSA: emu10k1: track loss of external clock on E-MU cards
85;95;0c
This uses IRQs to track spontaneous changes to the word clock source
register.

FWIW, that this can happen in the first place is the reason why it is
futile to lock the clock source mixer setting while the device is open -
we can't consistently control the rate anyway. Though arguably, we
should reset any open streams when that happens, as they become
corrupted anyway.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230715160738.326832-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-17 09:21:21 +02:00
Kuninori Morimoto
90de551c1b
ASoC: simple-card-utils.c: enable multi Component support
If CPU/Codec driver keeps its DAI node, we can directly identify actual
DAI by using snd_soc_get_dai_via_args().
This means we can use multi Component.

This patch enables multi Component support on Audio Graph Card/Card2.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a5w4o949.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:47 +01:00
Kuninori Morimoto
bbde4a30c6
ASoC: soc-core.c: add snd_soc_copy_dai_args()
To use multi Component support, we need to check dai_args whether
Card could get DAI from args (CPU/Codec needs set dai_args on DAI driver).
If it could, we need to allocate dai_args for dlc.
This patch adds snd_soc_copy_dai_args() for it.

This is helper function for multi Component support.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkgko94e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:46 +01:00
Kuninori Morimoto
988bad5ee4
ASoC: soc-core.c: add snd_soc_dlc_use_cpu_as_platform()
Current snd_soc_is_matching_component() checks "of_node" or "dai_args".
Thus coping "of_node" only is not enough to use CPU as Platform.
This patch adds snd_soc_dlc_use_cpu_as_platform() and help it.

This is helper function for multi Component support.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cz10o94k.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:45 +01:00
Kuninori Morimoto
442ae56cf5
ASoC: soc-core.c: add snd_soc_get_dai_via_args()
To enable multi Component, Card driver need to get DAI via dai_args
to identify it. This patch adds snd_soc_get_dai_via_args() for it.

This is helper function for multi Component support.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87edlgo94p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:44 +01:00
Kuninori Morimoto
45655ec69c
ASoC: soc-core.c: enable multi Component
Current ASoC Card is using dlc (snd_soc_dai_link_component) to find
target DAI / Component to be used.
Current dlc has below 3 items to identify DAI / Component

	(a) name	for Component
	(b) of_node	for Component
	(c) dai_name	for DAI

(a) or (b) is used to identify target Component, and (c) is used
to identify DAI.

One of the biggest issue on it today is dlc needs "name matching"
for "dai_name" (c).

It was not a big deal when we were using platform_device, because we
could specify nessesary "dai_name" via its platform_data.

But we need to find DAI name pointer from whole registered datas and/or
each related driver somehow in case of DT, because we can't specify it.
Therefore, Card driver parses DT and assumes the DAI, and find its name
pointer. How to assume is based on each Component and/or Card.

Next biggest issue is Component node (a)/(b).

Basically, Component is registered when CPU/Codec driver was
probed() (X). Here, 1 Component is possible to have some DAIs.

	int xxx_probe(struct platform_device *pdev)
	{
		...
(X)		ret = devm_snd_soc_register_component(pdev->dev,
					&component_driver,
					&dai_driver, dai_driver_num);
		...
	}

The image of each data will be like below.
One note here is "driver" is included for later explanation.

	+-driver------+
	|+-component-+|
	||       dai0||
	||       dai1||
	||        ...||
	|+-----------+|
	+-------------+

The point here is 1 driver has 1 Component, because basically driver
calles snd_soc_register_component() (= X) once.

Here is the very basic CPU/Codec connection image.

	HW image			SW image
	+-- Board ------------+		+-card--------------------------+
	|+-----+      +------+|		|+-driver------+ +-driver------+|
	|| CPU | <--> |CodecA||		||+-component-+| |+-component-+||
	|+-----+      +------+|		|||        dai|<=>|dai        |||
	+---------------------+		||+-----------+| |+-----------+||
					|+-------------+ +-------------+|
					+-------------------------------+

It will be very complex if it has multi DAIs.
Here is intuitive easy to understandable HW / SW example.

	HW image			SW image
	+-- Board ---------------+	+-card--------------------------+
	|+--------+      +------+|	|+-driver------+ +-driver------+|
	|| CPU ch0| <--> |CodecA||	||+-component-+| |+-component-+||
	||        |      +------+|	|||    ch0 dai|<=>|dai        |||
	||        |      +------+|	|||           || |+-----------+||
	||     ch1| <--> |CodecB||	|||           || +-------------+|
	|+--------+      +------+|	|||           || +-driver------+|
	+------------------------+	|||           || |+-component-+||
					|||    ch1 dai|<=>|dai        |||
					||+-----------+| |+-----------+||
					|+-------------+ +-------------+|
					+-------------------------------+

It will be handled as multi interface as "one Card".

	card0,0: CPU-ch0 - CodecA
	card0,1: CPU-ch1 - CodecB
	    ^

But, here is the HW image example which will be more complex

	+-- Basic Board ---------+
	|+--------+      +------+|
	|| CPU ch0| <--> |CodecA||
	||     ch1| <-+  +------+|
	|+--------+   |          |
	+-------------|----------+
	+-- expansion board -----+
	|             |  +------+|
	|             +->|CodecB||
	|                +------+|
	+------------------------+

We intuitively think we want to handle these as "2 Sound Cards".

	card0,0: CPU-ch0 - CodecA
	card1,0: CPU-ch1 - CodecB
	    ^

But below image which we can register today doesn't allow it,
because the same Component will be connected to both Card0/1,
but it will be rejected by (Z).

	 +-driver------+
	 |+-component-+|
	+-card0-------------------------+
	|||           || +-driver------+|
	|||           || |+-component-+||
	|||    ch0 dai|<=>|dai        |||
	|||           || |+-----------+||
	|||           || +-------------+|
	+-------------------------------+
	 ||           ||
	+-card1-------------------------+
	|||           || +-driver------+|
	|||           || |+-component-+||
	|||    ch1 dai|<=>|dai        |||
	|||           || |+-----------+||
	|||           || +-------------+|
	+-------------------------------+
	 |+-----------+|
	 +-------------+

	static int soc_probe_component()
	{
		...
		if (component->card) {
(Z)			if (component->card != card) {
				dev_err(component->dev, ...);
				return -ENODEV;
			}
			return 0;
		}
		...
	}

So, how about to call snd_soc_register_component() (= X) multiple times
on probe() to avoid buplicated component->card limitation, to be like
below ?

	 +-driver------+
	+-card0-------------------------+
	||             | +-driver------+|
	||+-component-+| |+-component-+||
	|||    ch0 dai|<=>|dai        |||
	||+-----------+| |+-----------+||
	||             | +-------------+|
	+-------------------------------+
	 |             |
	+-card1-------------------------+
	||             | +-driver------+|
	||+-component-+| |+-component-+||
	|||    ch1 dai|<=>|dai        |||
	||+-----------+| |+-----------+||
	||             | +-------------+|
	+-------------------------------+
         +-------------+

Yes, looks good. But unfortunately it doesn't help us for now.
Let's see soc_component_to_node() and snd_soc_is_matching_component()

	static struct device_node
	*soc_component_to_node(struct snd_soc_component *component)
	{
		...
(A)		of_node = component->dev->of_node;
		...
	}

	static int snd_soc_is_matching_component(...)
	{
		...
(B)		if (dlc->of_node && component_of_node != dlc->of_node)
		...
	}

dlc checkes "of_node" to identify target component (B),
but this "of_node" came from component->dev (A) which is added
by snd_soc_register_component() (X) on probe().

This means we can have different "component->card", but have same
"component->dev" in this case.

Even though we calls snd_soc_register_component() (= X) multiple times,
all Components have same driver's dev, thus it is impossible to
identified the Component.
And if it was impossible to identify Component, it is impossible to
identify DAI on current implementation.

So, how to handle above complex HW image today is 2 patterns.
One is handles it as "1 big sound card".
The SW image is like below.

SW image
	+-card--------------------------+
	|+-driver------+ +-driver------+|
	||+-component-+| |+-component-+||
	|||    ch0 dai|<=>|dai        |||
	|||           || |+-----------+||
	|||           || +-------------+|
	|||           || +-driver------+|
	|||           || |+-component-+||
	|||    ch1 dai|<->|dai        |||
	||+-----------+| |+-----------+||
	|+-------------+ +-------------+|
	+-------------------------------+

But the problem is not intuitive.
We want to handle it as "2 Cards".

2nd pattern is like below.

SW image
	+-card0-------------------------+
	|+-driver------+ +-driver------+|
	||+-component-+| |+-component-+||
	|||    ch0 dai|<=>|dai        |||
	||+-----------+| |+-----------+||
	|+-------------+ +-------------+|
	+-------------------------------+

	+-card1-------------------------+
	|+-driver------+ +-driver------+|
	||+-component-+| |+-component-+||
	|||    ch1 dai|<=>|dai        |||
	||+-----------+| |+-----------+||
	|+-------------+ +-------------+|
	+-------------------------------+

It handles as "2 Cards", but CPU part needs to be probed as 2 drivers.
It is also not intuitive.

To solve this issue, we need to have multi Component support.

In current implementation, we need to identify Component first
to identify DAI, and it is using name matching to identify DAI.

But how about to be enable to directly identify DAI by unique way
instead of name matching ? In such case, we can directly identify DAI,
then it can identify Component from DAI.

For example Simple-Card / Audio-Graph-Card case, it is specifying DAI
via its node.

Simple-Card

	sound-dai = <&cpu-sound>;

Audio-Graph-Card

	dais = <&cpu-sound>;

If each CPU/Codec driver keeps this property when probing,
we can identify DAI directly from Card.
Being able to identify DAI directly means being able to identify its
Component as well even though Component has same dev (= B).

This patch adds new "dai_node" for it.

To keeping compatibility, it checks "dai_node" first if it has,
otherwise, use existing method (name matching).

Link: https://lore.kernel.org/r/87fskz5yrr.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87fs5wo94v.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:43 +01:00
Kuninori Morimoto
09f75f0981
ASoC: soc-dai.c: add DAI get/match functions
Current ASoC is specifying and checking DAI name.
But where it came from and how to check was ambiguous.
This patch adds snd_soc_dai_name_get() / snd_soc_dlc_dai_is_match()
and makes it clear.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h6qco952.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-17 06:15:42 +01:00
Oswald Buddenhagen
fbb64eedf5 ALSA: emu10k1: make E-MU dock monitoring interrupt-driven
... instead of using a one-second polling timer.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230710065956.1246364-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-07-10 16:56:59 +02:00
Herve Codina
12e58fec5b
ASoC: soc-dapm.h: Convert macros to return a compound literal
The SND_SOC_DAPM_* helpers family are used to build widgets array in a
static way.

Convert them to return a compound literal in order to use them in both
static and dynamic way.
With this conversion, the different SND_SOC_DAPM_* parameters can be
computed by the code and the widget can be built based on this parameter
computation.
  static int create_widget(char *input_name)
  {
          struct snd_soc_dapm_widget widget;
          char name*;
          ...
          name = input_name;
          if (!name)
                  name = "default";

          widget = SND_SOC_DAPM_INPUT(name);
          ...
  }

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20230623085830.749991-12-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-09 22:48:18 +01:00
Takashi Iwai
d6048fdc87 ASoC: Updates for v6.5
A fairly quiet release from a core and framework point of view, but a
 very big one from the point of view of new drivers:
 
  - More refectoring from Morimoto-san, this time mainly around DAI
    links and how we control the ordering of trigger() callbacks.
  - Convert a lot of drivers to use maple tree based caches.
  - Lots of work on the x86 driver stack.
  - Compressed audio support for Qualcomm.
  - Support for AMD SoundWire, Analog Devices SSM3515, Google Chameleon,
    Ingenic X1000, Intel systems with various CODECs, Longsoon platforms,
    Maxim MAX98388, Mediatek MT8188, Nuvoton NAU8825C, NXP platforms with
    NAU8822, Qualcomm WSA884x, StarFive JH7110, Texas Instruments TAS2781.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSZjIQACgkQJNaLcl1U
 h9Dm0wf/X1q4n6KSXLvSyoSUxS/RWzWgyDDX7a4iLcFiov3ehHpVwzhwI/+1xSzs
 SGhg6q2rud05SejFBh+2L7HMZfdXWSfW9ukaGz3UsCdqw3/7zAUFgY1RGtjZO4lA
 eH50vEME9RbkIDgyxzYe9eViaKGh2fNxIbQ2d9hx6+nIVNfuuSikvGz4K/9PD0DN
 2tBgzuIWwrPIbvMV2zHDCycmVG0lqScMWjIrdpDFxa63aPTr920YqYWSoQfOUR1s
 j9zlZWnclTjrqRl1GZHxnM8N70vmutZWXAB1WFjal6mmMd6lUG71CyYHvA5h5D0V
 ygNpn9B5REYlHBVzI43uT3nog+iS4Q==
 =dbjW
 -----END PGP SIGNATURE-----

Merge tag 'asoc-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Updates for v6.5

A fairly quiet release from a core and framework point of view, but a
very big one from the point of view of new drivers:

 - More refectoring from Morimoto-san, this time mainly around DAI
   links and how we control the ordering of trigger() callbacks.
 - Convert a lot of drivers to use maple tree based caches.
 - Lots of work on the x86 driver stack.
 - Compressed audio support for Qualcomm.
 - Support for AMD SoundWire, Analog Devices SSM3515, Google Chameleon,
   Ingenic X1000, Intel systems with various CODECs, Longsoon platforms,
   Maxim MAX98388, Mediatek MT8188, Nuvoton NAU8825C, NXP platforms with
   NAU8822, Qualcomm WSA884x, StarFive JH7110, Texas Instruments TAS2781.
2023-06-26 15:38:02 +02:00
Takashi Iwai
a15b513756 Merge branch 'for-next' into for-linus
Pull the 6.5-devel branch for upstreaming.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-26 15:23:23 +02:00
Takashi Iwai
4a1b5ba16e Merge branch 'topic/midi20' into for-next
Pull one more API update for UMP core.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-23 09:56:24 +02:00
Takashi Iwai
33cd763078 ALSA: ump: Export MIDI1 / UMP conversion helpers
Yet more preliminary work for the upcoming USB gadget support.

Now export the helpers to convert between legacy MIDI1 and UMP data
for handling the MIDI 1.0 USB interface.  The header file is moved to
include/sound.

The API functions are slightly changed, so that they can be used
without the direct access to snd_ump object.  The allocation is done
in ump.c itself as it's a simple kcalloc().

Link: https://lore.kernel.org/r/20230623075530.10976-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-23 09:56:11 +02:00
Takashi Iwai
6b164eaecd Merge branch 'topic/midi20' into for-next
This is a small patch set to change the UMP core for the upcoming
gadget driver support.  Basically exporting a couple of helper
functions and adding a flag to suppress the internal UMP handling.
No functional changes by those alone.

Link: https://lore.kernel.org/r/20230621110241.4751-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21 13:06:43 +02:00
Takashi Iwai
4dce2f076b ALSA: ump: Export snd_ump_receive_ump_val()
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Export the currently local snd_ump_receive_ump_val().  It can be used
by the gadget driver for processing the UMP data.

Link: https://lore.kernel.org/r/20230621110241.4751-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21 13:06:19 +02:00
Takashi Iwai
eacd9c7f1d ALSA: ump: Add no_process_stream flag
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Add a new flag, no_process_stream, to snd_ump for suppressing the UMP
Stream message handling in UMP core.

Link: https://lore.kernel.org/r/20230621110241.4751-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21 13:06:18 +02:00
Takashi Iwai
a798076837 ALSA: ump: Add helper to change MIDI protocol
This is a preliminary patch for MIDI 2.0 USB gadget driver.
Export a new helper to allow changing the current MIDI protocol from
the outside.

Link: https://lore.kernel.org/r/20230621110241.4751-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21 13:06:18 +02:00
Ivan Orlov
8d0cf150d2 sound: make all 'class' structures const
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Ivan Orlov <ivan.orlov0322@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geoff Levand <geoff@infradead.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: alsa-devel@alsa-project.org
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20230620175633.641141-2-gregkh@linuxfoundation.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-21 07:29:10 +02:00
Kuninori Morimoto
3c8b586185
ASoC: soc-core.c: add index on snd_soc_of_get_dai_name()
Current snd_soc_of_get_dai_name() doesn't accept index
for #sound-dai-cells. It is not useful for user.
This patch adds it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pm5qdgng.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-20 12:49:22 +01:00
Kuninori Morimoto
05722a0ce6
ASoC: soc-core.c: add snd_soc_{of_}get_dlc()
Current soc-core.c has snd_soc_{of_}get_dai_name() to get DAI name
for dlc (snd_soc_dai_link_component). It gets .dai_name, but we need
.of_node too. Therefor user need to arrange.

It will be more useful if it gets both .dai_name and .of_node.
This patch adds snd_soc_{of_}get_dlc() for it, and existing functions
uses it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r0q6dgnm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-20 12:49:21 +01:00
Shenghao Ding
678f38eba1
ASoC: tas2781: Add Header file for tas2781 driver
Create Header file for  tas2781 driver.

Signed-off-by: Shenghao Ding <13916275206@139.com>
Link: https://lore.kernel.org/r/20230618122819.23143-1-13916275206@139.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-19 12:59:29 +01:00
Mark Brown
1a32b4b9a6
ASoC: Merge fixes due to dependencies
So we can apply the tlv320aic3xxx DT conversion.
2023-06-16 14:55:20 +01:00
Kuninori Morimoto
45b4ad53d4
ASoC: simple_card_utils: remove unused cpus/codecs/platforms from props
simple_dai_props has cpus/codecs/platforms. These pointer were used
for dai_link before, but are allocated today since
commit 050c7950fd ("ASoC: simple-card-utils: alloc dai_link
information for CPU/Codec/Platform").
We don't need to keep it anymore. This patch removes these.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkhhxpc6.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-15 12:08:41 +01:00
Kuninori Morimoto
fed4be313a
ASoC: simple-card-utils.c: share asoc_graph_parse_dai()
Current Audio Graph Card/Card2 implements asoc_simple_parse_dai()
on each driver, but these are same function.
This patch share it as asoc_graph_parse_dai().

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87o7lihpvy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-14 14:47:53 +01:00
Mark Brown
a11e6515b0
ASoC: add new trigger ordering method
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:

This patch-set adds new "trigger" starting/stopping method.
2023-06-13 17:39:51 +01:00
Kuninori Morimoto
099770e2da
ASoC: remove old trigger ordering method
All drivers switch to use generic trigger ordering method.
Let's remove old method.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87legufnyy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13 12:11:23 +01:00
Kuninori Morimoto
356caf663d
ASoC: add new trigger ordering method
Current ASoC is assuming that trigger starting order is
Link -> Component -> DAI as default, and its reverse order for stopping.
But some Driver / Card want to reorder it for some reasons.
We have such flags, but is unbalance like below.

	struct snd_soc_component_driver	:: start_dma_last
	struct snd_soc_dai_link		:: stop_dma_first

We want to have more flexible, and more generic method.
This patch adds new snd_soc_trigger_order for start/stop at
component / DAI-link.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r0qmfnzx.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13 12:11:19 +01:00
Bard Liao
ac950278b0
ASoC: add N cpus to M codecs dai link support
Currently, ASoC supports dailinks with the following mappings:
1 cpu DAI to N codec DAIs
N cpu DAIs to N codec DAIs
But the mapping between N cpu DAIs and M codec DAIs is not supported.
The reason is that we didn't have a mechanism to map cpu and codec DAIs

This patch suggests a new snd_soc_dai_link_codec_ch_map struct in
struct snd_soc_dai_link{} which provides codec DAI to cpu DAI mapping
information used to implement N cpu DAIs to M codec DAIs
support.

When a dailink contains two or more cpu DAIs, we should set channel
number of cpus based on its channel mask. The new struct also provides
channel mask information for each codec and we can construct the cpu
channel mask by combining all codec channel masks which map to the cpu.

The N:M mapping is however restricted to the N <= M case due to physical
restrictions on a time-multiplexed bus such as I2S/TDM, AC97, SoundWire
and HDaudio.

Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter 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/20230607031242.1032060-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-13 12:11:15 +01:00
Oswald Buddenhagen
e68235c8aa ALSA: emu10k1: fix synthesizer pitch for E-MU cards at 44.1 kHz
This is only a very partial fix - the frequency-dependent envelope & LFO
register values aren't adjusted.

But I'm not sure they were even correct at 48 kHz to start with, as most
of them are precalculated by common code which assumes an EMU8K-specific
44.1 kHz word clock, and it seems somewhat unlikely that the hardware's
register interpretation was adjusted to compensate for the different
word clock.

In any case I'm not going to spend time on fixing that, as this code is
unlikely to be actually used by anyone today.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:42:08 +02:00
Oswald Buddenhagen
19b89d15fa ALSA: emu10k1: fix sample rates for E-MU cards at 44.1 kHz word clock
Now that we know the actual word clock, we can:
- Put the resulting rate into the hardware info
- At 44.1 kHz word clock shift the rate for the pitch calculations,
  which presume a 48 kHz word clock

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:41:43 +02:00
Oswald Buddenhagen
e73b597e63 ALSA: emu10k1: query rate of external clock sources on E-MU cards
The value isn't used yet; the subsequent commits will do that.

This ignores the existence of rates above 48 kHz, which is fine, as the
hardware will just switch to the fallback clock source when fed with a
rate which is incompatible with the base clock multiplier, which
currently is always x1.

The sample rate display in /proc spdif-in is adjusted to reflect our
understanding of the input rates.

This is tested only with an 0404b card without sync card, so there is a
lot of room for improvement.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>

Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:41:07 +02:00
Oswald Buddenhagen
60985241bf ALSA: emu10k1: make available E-MU clock sources card-specific
The actually available clock sources depend on the available audio input
ports and dedicated clock input ports.

This includes refactoring the code to be data-driven to remain
manageable.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:40:51 +02:00
Oswald Buddenhagen
1359886227 ALSA: emu10k1: split off E-MU fallback clock from clock source
So far, we set the fallback as a side effect of setting the source. But
the fallback makes no sense at all when an internal clock is selected.
Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the
global default and we're not changing it automatically any more, it's
just fine to leave it entirely to the explicit setting.

This changes the name of the pre-existing control to something more
appropriate (regardless of the split), so users will need to adjust
their mixer settings.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:39:50 +02:00
Takashi Iwai
508b662b69 Merge branch 'topic/midi20' into for-next
As the updated MIDI 2.0 spec has been published freshly, this is a
catch up to add the support for new specs, especially UMP v1.1
features, on Linux kernel.

The new UMP v1.1 introduced the concept of Function Blocks (FB), which
is a kind of superset of USB MIDI 2.0 Group Terminal Blocks (GTB).
The patch set adds the support for FB as the primary information
source while keeping the parse of GTB as fallback.  Also UMP v1.1
supports the groupless messages, the protocol switch, static FBs, and
other new fundamental features, and those are supported as well.

Link: https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange
Link: https://lore.kernel.org/r/20230612081054.17200-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-13 07:37:59 +02:00
Takashi Iwai
6a8b4800ae ALSA: seq: ump: Notify UMP protocol change to sequencer
UMP v1.1 supports the protocol switch via a UMP Stream message.  When
it's received, we need to take care of the midi_version field in the
corresponding sequencer client, too.

This patch introduces a new ops to notify the protocol change to
snd_seq_ump_ops for handling it.

Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12 18:22:33 +02:00
Takashi Iwai
4a16a3af05 ALSA: seq: ump: Handle FB info update
This patch implements the handling of the dynamic update of FB info.

When the FB info update is received after the initial parsing, it
means the dynamic FB info update.  We compare the result, and if the
actual update is detected, it's notified via a new ops,
notify_fb_change, to the sequencer client, and the corresponding
sequencer ports are updated accordingly.

Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12 18:22:31 +02:00
Takashi Iwai
5437ac9bad ALSA: seq: ump: Handle groupless messages
The UMP Utility and Stream messages are "groupless", i.e. an incoming
groupless packet should be sent only to the UMP EP port, and the event
with the groupless message is sent to UMP EP as is without the group
translation per port.

Also, the former reserved bit 0 for the client group filter is now
used for groupless events.  When the bit 0 is set, the groupless
events are filtered out and skipped.

Link: https://lore.kernel.org/r/20230612081054.17200-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12 18:22:29 +02:00
Takashi Iwai
37e0e14128 ALSA: ump: Support UMP Endpoint and Function Block parsing
This patch adds the basic support for UMP Endpoint and UMP Function
Block parsing, which are extended in the new UMP v1.1 spec.
The patch provides a new helper function to perform the query of the
UMP Endpoint information and builds up the UMP blocks based on UMP
Function Block information.  For the communication over the UMP
Endpoint, it opens the rawmidi device once internally, inquiries the
UMP Endpoint and Function Block info by sending new UMP Stream
messages, and waits for the response for each query.

The new UMP spec allows to update the FB info and change its
associated groups or its activeness on the fly, too.  For catching it,
the UMP core keeps watching the incoming UMP messages, and
snd_ump_receive() handles the incoming UMP Stream messages to refresh
the FB info.

Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-12 18:22:26 +02:00
Yanteng Si
942ccdd834 ALSA: hda: Workaround for SDnCTL register on loongson
On loongson controller, after calling snd_hdac_stream_updateb()
to enable DMA engine, the SDnCTL.STRM will become to zero.  We
need to access SDnCTL in dword to keep SDnCTL.STRM is not changed.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/27aeddf5ebbe7c69631cec0e489c1b264be94990.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07 12:41:21 +02:00
Yanteng Si
cbc3e98acf ALSA: hda: Using polling mode for loongson controller by default
On loongson controller, RIRBSTS.RINTFL cannot be cleared,
azx_interrupt() is called all the time. We disable RIRB
interrupt, and use polling mode by default.

Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/d309a75424d438b958d90d797b4f1ba45468e090.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-07 12:37:25 +02:00
Kuninori Morimoto
1c943f60e8
ASoC: add snd_soc_get_stream_cpu()
We are using get_stream_cpu() to get CPU stream which cares
Codec2Codec. But it is static function for now, and we want to use it
from other files. This patch makes it global function.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87fs7cj9mf.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-06 16:57:31 +01:00
Kuninori Morimoto
b9aa53fbee
ASoC: soc.h: remove snd_soc_compr_ops :: trigger
ASoC framework is not using trigger call-back for snd_soc_compr_ops.
This patch remove it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87edmwj9m1.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-06 16:57:30 +01:00
Oswald Buddenhagen
db987421b5 ALSA: emu10k1: vastly improve usefulness of info in /proc
- Include the FX bus map, without which the already present send routing
  info would require looking up the documentation.
- Include the physical I/O channels as known to the driver
- Make the multi-channel capture map actually name the mapped input
  channels rather than "FXBUS" (Audigy) or even "???" (SbLive)
- The latter two are omitted for E-MU cards, as their physical I/O is
  routed through the FPGA
- While at it, make the "Card" field somewhat more useful

This includes de-duplicating the label tables between emuproc and emufx,
updating/improving the FX bus label table, and making the SB Live! 5.1
multi-track capture channel mapping hack data-driven.

Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-05 09:26:45 +02:00
Oswald Buddenhagen
6ab13291ba ALSA: emu10k1: make E-MU FPGA register dump in /proc more useful
Include the routing information, which can be actually read back.

Somewhat as a drive-by, make the register dump format less obscure - the
previous one made no sense at all.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-06-05 09:26:26 +02:00
Mark Brown
b48aa6a357
ES8316 audio codec fixes on Rock5B
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:

This patch series handles a few issues related to the ES8316 audio
codec, discovered while doing some testing on the Rock 5B board.
2023-05-30 20:41:29 +01:00
Oswald Buddenhagen
11ee59bdac ALSA: emu10k1: add synchronized start of multi-channel playback
We use independent voices for the channels, so we need to make an effort
to ensure that they are actually in sync.

The hardware doesn't provide atomicity, so we may need to retry a few
times, due to NMIs, PCI contention, and the wrong phase of the moon.

Solution inspired by kX-project.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236023-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-24 12:10:29 +02:00
Takashi Iwai
e7684f3bae Merge branch 'topic/midi20' into for-next
Pull a fixup for build error on big-endian archs.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-24 09:10:15 +02:00
Stephen Rothwell
dafb82e7d3 ALSA: ump: Correct snd_ump_midi1_msg_program definition
The #endif is placed obviously at a wrong position, which caused a
build error on the big endian machine.

Fixes: 0b5288f5fe ("ALSA: ump: Add legacy raw MIDI support")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20230524135448.3ecad334@canb.auug.org.au
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-24 09:09:19 +02:00
David Rau
dc0ff0fa3a
ASoC: da7219: Add Jack insertion detection polarity
Add support of selecting insertion detection polarity
- Default polarity (Low)
- Inverted polarity (High)

Correct the keywords of parsing `dlg,jack-det-rate`
bases on the new DT binding.

Signed-off-by: David Rau <David.Rau.opensource@dm.renesas.com>
Link: https://lore.kernel.org/r/20230523161821.4260-4-David.Rau.opensource@dm.renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-23 18:49:36 +01:00
Takashi Iwai
03a58514d4 Merge branch 'topic/midi20' into for-next
This is a (largish) patch set for adding the support of MIDI 2.0
functionality, mainly targeted for USB devices.  MIDI 2.0 is a
complete overhaul of the 40-years old MIDI 1.0.  Unlike MIDI 1.0 byte
stream, MIDI 2.0 uses packets in 32bit words for Universal MIDI Packet
(UMP) protocol.  It supports both MIDI 1.0 commands for compatibility
and the extended MIDI 2.0 commands for higher resolutions and more
functions.

For supporting the UMP, the patch set extends the existing ALSA
rawmidi and sequencer interfaces, and adds the USB MIDI 2.0 support to
the standard USB-audio driver.

The rawmidi for UMP has a different device name (/dev/snd/umpC*D*) and
it reads/writes UMP packet data in 32bit CPU-native endianness.  For
the old MIDI 1.0 applications, the legacy rawmidi interface is
provided, too.

As default, USB-audio driver will take the alternate setting for MIDI
2.0 interface, and the compatibility with MIDI 1.0 is provided via the
rawmidi common layer.  However, user may let the driver falling back
to the old MIDI 1.0 interface by a module option, too.

A UMP-capable rawmidi device can create the corresponding ALSA
sequencer client(s) to support the UMP Endpoint and UMP Group
connections.  As a nature of ALSA sequencer, arbitrary connections
between clients/ports are allowed, and the ALSA sequencer core
performs the automatic conversions for the connections between a new
UMP sequencer client and a legacy MIDI 1.0 sequencer client.  It
allows the existing application to use MIDI 2.0 devices without
changes.

The MIDI-CI, which is another major extension in MIDI 2.0, isn't
covered by this patch set.  It would be implemented rather in
user-space.

Roughly speaking, the first half of this patch set is for extending
the rawmidi and USB-audio, and the second half is for extending the
ALSA sequencer interface.

The patch set is based on 6.4-rc2 kernel, but all patches can be
cleanly applicable on 6.2 and 6.3 kernels, too (while 6.1 and older
kernels would need minor adjustment for uapi header changes).

The updates for alsa-lib and alsa-utils will follow shortly later.

The author thanks members of MIDI Association OS/API Working Group,
especially Andrew Mee, for great helps for the initial design and
debugging / testing the drivers.

Link: https://lore.kernel.org/r/20230523075358.9672-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 14:14:47 +02:00
Takashi Iwai
81fd444aa3 ALSA: seq: Bind UMP device
This patch introduces a new ALSA sequencer client for the kernel UMP
object, snd-seq-ump-client.  It's a UMP version of snd-seq-midi
driver, while this driver creates a sequencer client per UMP endpoint
which contains (fixed) 16 ports.

The UMP rawmidi device is opened in APPEND mode for output, so that
multiple sequencer clients can share the same UMP endpoint, as well as
the legacy UMP rawmidi devices that are opened in APPEND mode, too.
For input, on the other hand, the incoming data is processed on the
fly in the dedicated hook, hence it doesn't open a rawmidi device.

The UMP packet group is updated upon delivery depending on the target
sequencer port (which corresponds to the actual UMP group).

Each sequencer port sets a new port type bit,
SNDRV_SEQ_PORT_TYPE_MIDI_UMP, in addition to the other standard
types for MIDI.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-33-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:11:33 +02:00
Takashi Iwai
46397622a3 ALSA: seq: Add UMP support
Starting from this commit, we add the basic support of UMP (Universal
MIDI Packet) events on ALSA sequencer infrastructure.  The biggest
change here is that, for transferring UMP packets that are up to 128
bits, we extend the data payload of ALSA sequencer event record when
the client is declared to support for the new UMP events.

A new event flag bit, SNDRV_SEQ_EVENT_UMP, is defined and it shall be
set for the UMP packet events that have the larger payload of 128
bits, defined as struct snd_seq_ump_event.

For controlling the UMP feature enablement in kernel, a new Kconfig,
CONFIG_SND_SEQ_UMP is introduced.  The extended event for UMP is
available only when this Kconfig item is set.  Similarly, the size of
the internal snd_seq_event_cell also increases (in 4 bytes) when the
Kconfig item is set.  (But the size increase is effective only for
32bit architectures; 64bit archs already have padding there.)
Overall, when CONFIG_SND_SEQ_UMP isn't set, there is no change in the
event and cell, keeping the old sizes.

For applications that want to access the UMP packets, first of all, a
sequencer client has to declare the user-protocol to match with the
latest one via the new SNDRV_SEQ_IOCTL_USER_PVERSION; otherwise it's
treated as if a legacy client without UMP support.

Then the client can switch to the new UMP mode (MIDI 1.0 or MIDI 2.0)
with a new field, midi_version, in snd_seq_client_info.  When switched
to UMP mode (midi_version = 1 or 2), the client can write the UMP
events with SNDRV_SEQ_EVENT_UMP flag.  For reads, the alignment size
is changed from snd_seq_event (28 bytes) to snd_seq_ump_event (32
bytes).  When a UMP sequencer event is delivered to a legacy sequencer
client, it's ignored or handled as an error.

Conceptually, ALSA sequencer client and port correspond to the UMP
Endpoint and Group, respectively; each client may have multiple ports
and each port has the fixed number (16) of channels, total up to 256
channels.

As of this commit, ALSA sequencer core just sends and receives the UMP
events as-is from/to clients.  The automatic conversions between the
legacy events and the new UMP events will be implemented in a later
patch.

Along with this commit, bump the sequencer protocol version to 1.0.3.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:11:21 +02:00
Takashi Iwai
ea46f79709 ALSA: seq: Add snd_seq_expand_var_event_at() helper
Create a new variant of snd_seq_expand_var_event() for expanding the
data starting from the given byte offset.  It'll be used by the new
UMP sequencer code later.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:11:14 +02:00
Takashi Iwai
0b5288f5fe ALSA: ump: Add legacy raw MIDI support
This patch extends the UMP core code to support the legacy MIDI 1.0
rawmidi devices.  When the new kconfig CONFIG_SND_UMP_LEGACY_RAWMIDI
is set, the UMP core allows to attach an additional rawmidi device for
each UMP Endpoint.  The rawmidi device contains 16 substreams where
each substream corresponds to a UMP Group belonging to the EP.  The
device reads/writes the legacy MIDI 1.0 byte streams and translates
from/to UMP packets.

The legacy rawmidi devices are exclusive with the UMP rawmidi devices,
hence both of them can't be opened at the same time unless the UMP
rawmidi is opened in APPEND mode.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:11:09 +02:00
Takashi Iwai
6b41e64a5d ALSA: ump: Redirect rawmidi substream access via own helpers
This is a code refactoring for abstracting the rawmidi access to the
UMP's own helpers.  It's a preliminary work for the later code
refactoring of the UMP layer.

Until now, we access to the rawmidi substream directly from the
driver via rawmidi access helpers, but after this change, the driver
is supposed to access via the newly introduced snd_ump_ops and
receive/transmit via snd_ump_receive() and snd_ump_transmit() helpers.
As of this commit, those are merely wrappers for the rawmidi
substream, and no much function change is seen here.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:11:08 +02:00
Takashi Iwai
fa030f666d ALSA: ump: Additional proc output
UMP devices may have more interesting information than the traditional
rawmidi.  Extend the rawmidi_global_ops to allow the optional proc
info output and show some more bits in the proc file for UMP.

Note that the "Groups" field shows the first and the last UMP Groups,
and both numbers are 1-based (i.e. the first group is 1).

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:10:59 +02:00
Takashi Iwai
e3a8a5b726 ALSA: rawmidi: UMP support
This patch adds the support helpers for UMP (Universal MIDI Packet) in
ALSA core.

The basic design is that a rawmidi instance is assigned to each UMP
Endpoint.  A UMP Endpoint provides a UMP stream, typically
bidirectional (but can be also uni-directional, too), which may hold
up to 16 UMP Groups, where each UMP (input/output) Group corresponds
to the traditional MIDI I/O Endpoint.

Additionally, the ALSA UMP abstraction provides the multiple UMP
Blocks that can be assigned to each UMP Endpoint.  A UMP Block is a
metadata to hold the UMP Group clusters, and can represent the
functions assigned to each UMP Group.  A typical implementation of UMP
Block is the Group Terminal Blocks of USB MIDI 2.0 specification.

For distinguishing from the legacy byte-stream MIDI device, a new
device "umpC*D*" will be created, instead of the standard (MIDI 1.0)
devices "midiC*D*".  The UMP instance can be identified by the new
rawmidi info bit SNDRV_RAWMIDI_INFO_UMP, too.

A UMP rawmidi device reads/writes only in 4-bytes words alignment,
stored in CPU native endianness.

The transmit and receive functions take care of the input/out data
alignment, and may return zero or aligned size, and the params ioctl
may return -EINVAL when the given input/output buffer size isn't
aligned.

A few new UMP-specific ioctls are added for obtaining the new UMP
endpoint and block information.

As of this commit, no ALSA sequencer instance is attached to UMP
devices yet.  They will be supported by later patches.

Along with those changes, the protocol version for rawmidi is bumped
to 2.0.3.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:10:54 +02:00
Takashi Iwai
fb3bd12159 ALSA: rawmidi: Add ioctl callback to snd_rawmidi_global_ops
A new callback, ioctl, is added to snd_rawmidi_global_ops for allowing
the driver to deal with the own ioctls.  This is another preparation
patch for the upcoming UMP support.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:10:53 +02:00
Takashi Iwai
09b62892dd ALSA: rawmidi: Pass rawmidi directly to snd_rawmidi_kernel_open()
snd_rawmidi_kernel_open() is used only internally from ALSA sequencer,
so far, and parsing the card / device matching table at each open is
redundant, as each sequencer client already gets the rawmidi object
beforehand.

This patch optimizes the path by passing the rawmidi object directly
at snd_rawmidi_kernel_open().  This is also a preparation for the
upcoming UMP rawmidi I/O support.

Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-23 12:10:52 +02:00
Cezary Rojewski
836855100b
ASoC: Intel: avs: Account for UID of ACPI device
Configurations with multiple codecs attached to the platform are
supported but only if each from the set is different. Add new field
representing the 'Unique ID' so that codecs that share Vendor and Part
IDs can be differentiated and thus enabling support for such
configurations.

Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20230519201711.4073845-6-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-22 11:18:24 +01:00
Oswald Buddenhagen
a915d60426 ALSA: emu10k1: revamp playback voice allocator
Instead of separate voices, we now allocate non-interleaved channels,
which may in turn contain two interleaved voices each. The higher-level
code keeps only one pointer per channel. The channels are not allocated
in one block any more, as there is no reason to do that. As a
consequence of that, and because it is cleaner regardless, we now let
the allocator store these pointers at a specified location, rather than
returning only the first one and having the calling code deduce the
remaining ones.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-20 10:16:20 +02:00
Oswald Buddenhagen
b4fea2d3f2 ALSA: emu10k1: make snd_emu10k1_voice_alloc() assign voices' epcm
The voice allocator clearly knows about the field (it resets it), so
it's more consistent (and leads to less duplicated code) to have the
constructor take it as a parameter.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-20 10:16:03 +02:00
Mark Brown
83b3432fc5
ASoC: cs35l56: Bugfixes and efficiency improvement
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:

First two patches are bugfixes.
Third patch skips the overhead of rebooting the amp after applying
firmware files when we know that it isn't necessary.
2023-05-19 12:32:36 +09:00
Simon Trimmer
1a8edfcffa
ASoC: cs35l56: In secure mode skip SHUTDOWN and RESET around fw download
If the device is in secure mode it's unnecessary to send a SHUTDOWN and
SYSTEM_RESET around the firmware download. It could only be patching
insecure tunings. A tuning patch doesn't need a SHUTDOWN and only needs
a REINIT afterwards. This will reduce the overhead of exiting system
suspend in secure mode.

Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/Message-Id: <20230518150250.1121006-4-rf@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-19 11:32:13 +09:00
Ranjani Sridharan
e123036be3
ASoC: soc-pcm: test if a BE can be prepared
In the BE hw_params configuration, the existing code checks if any of the
existing FEs are prepared, running, paused or suspended - and skips the
configuration in those cases. This allows multiple calls of hw_params
which the ALSA state machine supports.

This check is not handled for the prepare stage, which can lead to the
same BE being prepared multiple times. This patch adds a check similar to
that of the hw_params, with the main difference being that the suspended
state is allowed: the ALSA state machine allows a transition from
suspended to prepared with hw_params skipped.

This problem was detected on Intel IPC4/SoundWire devices, where the BE
dailink .prepare stage is used to configure the SoundWire stream with a
bank switch. Multiple .prepare calls lead to conflicts with the .trigger
operation with IPC4 configurations. This problem was not detected earlier
on Intel devices, HDaudio BE dailinks detect that the link is already
prepared and skip the configuration, and for IPC3 devices there is no BE
trigger.

Link: https://github.com/thesofproject/sof/issues/7596
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com
Link: https://lore.kernel.org/r/20230517185731.487124-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-19 02:31:14 +09:00
Oswald Buddenhagen
82a9fa6e9e ALSA: emu10k1: make freeing untouched playback voices cheap
This allows us to drop the code that tries to preserve already allocated
voices upon repeated hw_param callback invocations. Getting it right for
multi-channel voices would otherwise get a bit hairy.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 16:55:56 +02:00
Oswald Buddenhagen
b840f8d8fc ALSA: emu10k1: improve voice status display in /proc
Eliminate the MIDI type, as there is no such thing - the MPU401 port
doesn't have anything to do with voices.

For clarity, differentiate between regular and extra voices.

Don't atomize the enum into bits in the table display.

Simplify/optimize the storage.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 16:49:09 +02:00
Oswald Buddenhagen
fccd6f31a4 ALSA: emu10k1: enable bit-exact playback, part 4: send amounts
On Audigy, the send amounts are merely targets, presumably to avoid
sound distortion due to sudden changes, which the EMU8K docu explicitly
warns about.

However, that "soft-start" would prevent bit-for-bit reproduction, so
we now force the current send amounts to their final values at PCM
playback init.

One might want to do that for the MIDI synthesizer as well, though it
seems mostly pointless due to the attack phase each note has anyway.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140339.3722279-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 16:41:59 +02:00
Oswald Buddenhagen
46055699e5 ALSA: emu10k1: introduce and use snd_emu10k1_ptr_write_multiple()
While this nicely denoises the code, the real intent is being able to
write many registers pseudo-atomically, which will come in handy later.

Idea stolen from kX-project.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>

Link: https://lore.kernel.org/r/20230518093134.3697955-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 13:08:23 +02:00
Oswald Buddenhagen
5b1cd21f0f ALSA: emu10k1: fix PCM playback cache and interrupt handling
The cache causes a fixed delay regardless of stream parameters.
Consequently, all that "cache invalidate size" calculation stuff was
garbage (which can be traced right back to Creative's OSS driver).

This also removes the definitions of registers CD1..CDF, because they
are accessed only relative to CD0 anyway.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 07:30:17 +02:00
Oswald Buddenhagen
1e5323bd77 Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)"
This workaround fails to address the underlying problem, which is
actually wholly self-made. Subsequent patches will fix it.

This reverts commit 56385a12d9.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-18 07:29:41 +02:00
Oswald Buddenhagen
216abe45cf ALSA: emu10k1: make struct snd_emu1010 less wasteful
Shrink the {in,out}put_source arrays and their data type to what is
actually necessary.

To be still on the safe side, add some static asserts.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-11-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:07:59 +02:00
Oswald Buddenhagen
6f3609f8a3 ALSA: emu10k1: add explicit support for E-MU 0404
Unlike the other models, this is actually a distinct card, rather than
an E-MU 1010 with different "dongles". It is stereo only, and supports
no ADAT (there is no trace of ADAT in the manual, switching the output
mode to ADAT has no effect, and switching the input mode to ADAT just
breaks input (presumably ... my only ADAT source is the card's output)).

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-10-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:07:58 +02:00
Oswald Buddenhagen
536438f1de ALSA: emu10k1: make mixer control mass creation less wasteful
Define arrays of strings instead of snd_kcontrol_new.

While at it, move the E-MU source & destination enum defs next to their
hardware defs, which is a lot more logical and will come in handy in a
followup commit. And add some static asserts to verify that the array
sizes match.

This also applies the compactization from the previous commit to the
destination registers.
While reshuffling the arrays anyway, switch the order of the HAMOA_DAC
& HANA_SPDIF output destinations for the 1010 card, so they follow a
more regular pattern. This should have no functional impact.

The code is somewhat de-duplicated by the extraction of add_ctls().

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:07:53 +02:00
Oswald Buddenhagen
9b00a1e9b1 ALSA: emu10k1: make some initializer arrays less wasteful
- Use bit fields in struct snd_emu_chip_details
- Use shorts in the E-MU routing register arrays

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:07:51 +02:00
Oswald Buddenhagen
51d652f458 ALSA: emu10k1: factor out snd_emu10k1_compose_audigy_sendamounts()
Saves a bit of code duplication.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:04:36 +02:00
Oswald Buddenhagen
77e067d0fa ALSA: emu10k1: skip needless setting of some voice registers
Many registers are meaningless for stereo slaves and the extra voices.
This patch cleans up these unnecessary register writes.

snd_emu10k1_playback_{trigger,stop}_voice() is not called for stereo
slaves any more.

snd_emu10k1_playback_prepare_voice() is renamed to
snd_emu10k1_playback_unmute_voice(), as this better reflects its
remaining function. It's not called for the extra voices any more.

Accordingly, snd_emu10k1_playback_mute_voice() is factored out from
snd_emu10k1_playback_stop_voice(), and is called selectively as well.

This doesn't add conditionals which would avoid initializing
sub-registers, as that wouldn't pull its weight.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:04:35 +02:00
Oswald Buddenhagen
a61c695aee ALSA: emu10k1: remove useless resets of stop-on-loop-end bits
We initialize them at card init and don't touch them later, so there is
no need to reset them again at voice start.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:04:33 +02:00
Oswald Buddenhagen
94dabafea0 ALSA: emu10k1: cleanup envelope register init
We (rightfully) don't enable the envelope engine for PCM voices, so any
related setup is entirely pointless - the EMU8K documentation makes that
very clear, and the fact that the various open drivers all use different
values to no observable detriment pretty much confirms it.

The remaining initializations are regrouped for clarity.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-17 17:04:32 +02:00
Oswald Buddenhagen
bcdbd3b788 ALSA: emu10k1: enable bit-exact playback, part 2: voice attenuation
The voice volume is a raw fractional multiplier that can't actually
represent 1.0. To still enable real pass-through, we now set the volume
to 0.5 (which results in no loss of precision, as the FX bus provides
fractional values) and scale up the samples in DSP code.

To maintain backwards compatibility with existing configuration files,
we rescale the values in the mixer controls. The range is extended
upwards from 0xffff to 0x1fffd, which actually introduces the
possibility of specifying an amplification.

There is still a minor incompatibility with user space, namely if
someone loaded custom DSP code. They'll just get half the volume, so
this doesn't seem like a big deal.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-16 11:11:04 +02:00
Oswald Buddenhagen
1298bc978a ALSA: emu10k1: enable bit-exact playback, part 1: DSP attenuation
Fractional multiplication with the maximal value 2^31-1 causes some tiny
distortion. Instead, we want to multiply with the full 2^31. The catch
is of course that this cannot be represented in the DSP's signed 32 bit
registers.

One way to deal with this is to encode 1.0 as a negative number and
special-case it. As a matter of fact, the SbLive! code path already
contained such code, though the controls never actually exercised it.

A more efficient approach is to use negative values, which actually
extend to -2^31. Accordingly, for all the volume adjustments we now use
the MAC1 instruction which negates the X operand.

The range of the controls in highres mode is extended downwards, so -1
is the new zero/mute. At maximal excursion, real zero is not mute any
more, but I don't think anyone will notice this behavior change. ;-)

That also required making the min/max/values in the control structs
signed. This technically changes the user space interface, but it seems
implausible that someone would notice - the numbers were actually
treated as if they were signed anyway (and in the actual mixer iface
they _are_). And without this change, the min value didn't even make
sense in the first place (and no-one noticed, because it was always 0).

Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-15 22:06:21 +02:00
Oswald Buddenhagen
60571ac9ea ALSA: emu10k1: automate encoding of sub-register definitions
The idea to encode the bitfield manipulation in the register address is
quite clever, but doing that by hand is ugly and error-prone. So derive
it automatically from the mask instead.

Macros cannot #define other macros, so we now declare enums instead.

This also adds macros for decoding the register definitions. These will
be used by later commits.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408798-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-15 22:00:54 +02:00
Mark Brown
fe0d5b9a4d
ASoC: Factor out control notification support
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:

This series introduces and uses a helper for notifying control changes
to userspace.
2023-05-16 00:17:58 +09:00
Pierre-Louis Bossart
bf10d002b6
ASoC: Intel: soc-acpi: add tables for LunarLake
These tables are used for 'nocodec' and SoundWire mockups+RVP tests.
The LNL RVP has a single rt711-sdca SoundWire codec.

Co-developed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com
Link: https://lore.kernel.org/r/20230512173305.65399-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-15 20:11:58 +09:00
Charles Keepax
ace9ed54bd
ASoC: soc-component: Add notify control helper function
Add a function to allow ASoC drivers to easily notify an ALSA control
change. This function will automatically add any component naming
prefix into the control name.

Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com
Link: https://lore.kernel.org/r/20230512122838.243002-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-15 20:11:17 +09:00
Pierre-Louis Bossart
ccc2f0c1b6
ASoC: SOF: Intel: hda-mlink: add helper to program SoundWire PCMSyCM registers
These registers enable the HDaudio DMA hardware to split/merge data
from different PDIs, possibly on different links.

This capability exists for all types of HDaudio extended links, but
for now is only required for SoundWire. In the SSP/DMIC case, the IP
is programmed by the DSP firmware.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com
Reviewed-by: Rander Wang <rander.wang@intel.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
Link: https://lore.kernel.org/r/20230512174611.84372-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-15 10:20:14 +09:00
Pierre-Louis Bossart
dcb88fc47d
ASoC: SOF: Intel: hda-mlink: add helper to get SoundWire hlink
Same functionality as for DMIC/SSP with different ID.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com
Reviewed-by: Rander Wang <rander.wang@intel.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com
Link: https://lore.kernel.org/r/20230512174611.84372-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-15 10:20:10 +09:00
Oswald Buddenhagen
f549466b8b ALSA: emu10k1: apply channel delay hack to all E-MU cards
Evidently, the channel delay bug exists in all E-MU cards; it's in the
Hana FPGA program, and was never fixed.

Note that the implementation is somewhat lazy - to localize the code
paths, we actually waste a GPR and a DSP instruction by keeping two
delay registers for the same physical source.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-12 09:17:18 +02:00
Oswald Buddenhagen
37bb927d5b ALSA: core: update comment on snd_card.controls_rwsem
Since commit 5bbb1ab5bd ("control: use counting semaphore as write lock
for ELEM_WRITE operation"), this has been locking the controls including
their values, not just the list of controls.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428095941.1706278-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-05-08 09:25:48 +02:00
Kuninori Morimoto
4d62611256
ASoC: simple_card_utils.c: use asoc_dummy_dlc
Now we can share asoc_dummy_dlc. This patch use it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com
Link: https://lore.kernel.org/r/87ttx6ypi3.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-08 08:47:14 +09:00
Kuninori Morimoto
d2a4e0d740
ASoC: soc-utils.c: add asoc_dummy_dlc
ASoC uses dummy Component, sharing snd_soc_dai_link_component
for it is better idea. This patch adds it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com
Link: https://lore.kernel.org/r/87a5yy0zyk.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org
2023-05-08 08:47:05 +09:00
Takashi Iwai
baa6584a24 ASoC: Updates for v6.4
The bulk of the commits here are for the conversion of drivers to use
 void remove callbacks but there's a reasonable amount of other stuff
 going on, the pace of development with the SOF code continues to be high
 and there's a bunch of new drivers too:
 
  - More core cleanups from Morimto-san.
  - Update drivers to have remove() callbacks returning void, mostly
    mechanical with some substantial changes.
  - Continued feature and simplification work on SOF, including addition
    of a no-DSP mode for bringup, HDA MLink and extensions to the IPC4
    protocol.
  - Hibernation support for CS35L45.
  - More DT binding conversions.
  - Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
    nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas R-Car
    Gen4, Rockchip RK3588 and TI TAS5733.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmRGdEsACgkQJNaLcl1U
 h9BNVAf+Ijupg3dhAl6847v1PRYXkYK6YjAayhNd0xRoRePKnnv1zkrsXSBzxZUM
 8KHpQDUJyfQbPnE2JRmr1WfHSoNDl/NXdJl+lefPBgol5bzxRji68hDPGjA0645o
 R6vzrqLNw8mh3jwptXfEpQfKH8tIvwOeMeLkncDvsm0ZCUR2GhYnjB1g82ih0ssx
 lvh36PdCRF0e/ruHxkiVn9b/riID65oTRkN6IxJqoPnqJZVyCiqmiJcfWePpaPir
 4R9Dyk+REos/aCLdne1g6H21Tgi0td+blv6empqwdEXG41VSdRMTrOZb1ZISKmpF
 ggPbKsk9BjJFBCewllHXJ0YEcBp9/g==
 =TVxt
 -----END PGP SIGNATURE-----

Merge tag 'asoc-v6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

ASoC: Updates for v6.4

The bulk of the commits here are for the conversion of drivers to use
void remove callbacks but there's a reasonable amount of other stuff
going on, the pace of development with the SOF code continues to be high
and there's a bunch of new drivers too:

 - More core cleanups from Morimto-san.
 - Update drivers to have remove() callbacks returning void, mostly
   mechanical with some substantial changes.
 - Continued feature and simplification work on SOF, including addition
   of a no-DSP mode for bringup, HDA MLink and extensions to the IPC4
   protocol.
 - Hibernation support for CS35L45.
 - More DT binding conversions.
 - Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
   nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas R-Car
   Gen4, Rockchip RK3588 and TI TAS5733.
2023-04-24 15:15:31 +02:00
Oswald Buddenhagen
7002cbd625 ALSA: emu10k1: use high-level I/O in set_filterQ()
This makes the code shorter and more legible.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230423181002.1246793-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-04-24 08:16:26 +02:00
Oswald Buddenhagen
8d60d5cabe ALSA: emu10k1: use high-level I/O functions also during init
... and also use more pre-defined constants on the way (some of which
required adjustment).

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>

Link: https://lore.kernel.org/r/20230422161021.1143967-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-04-23 09:22:09 +02:00
Oswald Buddenhagen
2696d5a3b0 ALSA: emu10k1: fixup DSP defines
Firstly, fix the distribution between public and private headers.
Otherwise, some of the already public macros wouldn't actually work, and
the SNDRV_EMU10K1_IOCTL_DBG_READ result for Audigy would be useless.

Secondly, add condition code registers for Audigy. These are just
aliases for selected constant registers, and thus are generation-
specific. At least A_CC_REG_ZERO is actually correct ...

Finally, shuffle around some defines to more logical places while at it,
and fix up some more comments.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-04-23 09:19:47 +02:00
Oswald Buddenhagen
145ec1fd00 ALSA: emu10k1: pull in some register definitions from kX-project
For documentation purposes and later use.

Some pre-existing but (mostly) unused definitions were renamed for
consistency.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-04-23 09:15:18 +02:00