mbox series

[0/2] ASoC: SOF: topology: simplify kcontrol names with token

Message ID 20230814232325.86397-1-pierre-louis.bossart@linux.intel.com
Headers show
Series ASoC: SOF: topology: simplify kcontrol names with token | expand

Message

Pierre-Louis Bossart Aug. 14, 2023, 11:23 p.m. UTC
The use of the widget name as a prefix for the kcontrol name is quite
useful in the case of multiple pipelines going to the same endpoint,
but it's overkill in simpler cases.

This patchset extends the existing DAPM code to drop the widget name
prefix and make the kcontrol names simpler when there's no possible
ambiguity, e.g.  "gain.2.1 Main Playback Volume" becomes just "Main
Playback Volume".

Jyri Sarha (2):
  ASoC: dapm: Add a flag for not having widget name in kcontrol name
  ASoC: SOF: topology: Add a token for dropping widget name in kcontrol
    name

 include/sound/soc-dapm.h        |  1 +
 include/uapi/sound/sof/tokens.h |  6 +++++-
 sound/soc/soc-dapm.c            |  2 ++
 sound/soc/sof/topology.c        | 22 ++++++++++++++++++++++
 4 files changed, 30 insertions(+), 1 deletion(-)

Comments

Mark Brown Aug. 15, 2023, 7:17 p.m. UTC | #1
On Mon, 14 Aug 2023 18:23:23 -0500, Pierre-Louis Bossart wrote:
> The use of the widget name as a prefix for the kcontrol name is quite
> useful in the case of multiple pipelines going to the same endpoint,
> but it's overkill in simpler cases.
> 
> This patchset extends the existing DAPM code to drop the widget name
> prefix and make the kcontrol names simpler when there's no possible
> ambiguity, e.g.  "gain.2.1 Main Playback Volume" becomes just "Main
> Playback Volume".
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ASoC: dapm: Add a flag for not having widget name in kcontrol name
      commit: f7f4a5ad8e11de4edb7b62d099f0501c8610c92b
[2/2] ASoC: SOF: topology: Add a token for dropping widget name in kcontrol name
      commit: 56ce7b791b787e0aee19601e422f13a18d4eafe7

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark