From: Mark Brown <broonie@kernel.org>
Date: Wed, 11 Mar 2026 13:34:14 +0000 (+0000)
Subject: Merge patch series "ASoC: Intel: catpt: Overhaul volume and mute control operations"
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=94ef278e7439c875b83ddbeddb92d1580d566a0c;p=thirdparty%2Flinux.git

Merge patch series "ASoC: Intel: catpt: Overhaul volume and mute control operations"

Cezary Rojewski <cezary.rojewski@intel.com> says:

ASoC: Intel: catpt: Overhaul volume and mute control operations

Short summary first, longer description later:

- fix the return code for kctl->put() - currently the driver returns
  '0' even if changes were done
- lower power consumption for kctl operations by waking the DSP only
  when some streaming is done.  No streaming? Cache the values and
  inform the AudioDSP firmware later.
- drop the existing code duplication between individual and master
  volume controls

The very first patch addresses synchronization problem that exists when
an individual control and its paired stream are manipulated by a user
simultaneously.  As the refactor integrates the fix in its new code,
most of it gets shuffled but in case of a "refactor problem" I've
decided to have it separated and leading the series.  This way the
problem is fixed even if refactor, for whatever reason, would be
reverted.

--
More of in-depth explanation for the refactor, taken from commit 2:

The catpt-driver's volume and mute control operations always return '0'
regardless if a change occurred or not.  To conform to ALSA's interface,
value '1' shall be returned when a change occurred.

The second major point is power consumption.  Existing control
operations always wake the DSP even if no streams are running.  In such
case waking the DSP just for the sake of updating the volume (or mute)
settings on the firmware side is a waste of power.  The provided
implementation caches the values and updates the settings only when
streams are being opened for streaming or are already running.

As changing existing code is non-trivial, provide new operations
instead.  The put() operation, which interests us the most, takes the
following shape:

	// two values provided to put():
	// @pin_id - which stream given control relates to
	// @value_to_apply - the value from user

	if (control->existing_val == value_to_apply)
		return 0;

	runtime_stream = get_running_stream(pin_id);
	if (runtime_stream != NULL) {
		ret = send_ipc();
		if (ret)
			return ret;
	}

	control->existing_val = value_to_apply;
	return 1;

Adheres to ALSA's expectation and avoids sending IPCs if there is no
change to be made.
---

94ef278e7439c875b83ddbeddb92d1580d566a0c