From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A0831FB1 for ; Mon, 15 Dec 2025 11:20:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765797629; cv=none; b=XhPJCyt4Re6q3Nu6CaPBsPCOOYGP2cQiw8/lhPpkuTxhES7z2NqX86Z98JIOZYdjh2E7HVofXqREvExjk3FMJtidr04g3Pn7X5+83gJ1g9O4Ewdn9HRTzYDQKihjpjaJkY2JvWjdfcXi7jN57KnGOiDsQPYJ3ZvHlEPb2XKovYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765797629; c=relaxed/simple; bh=PRfThtBw+tIqQ8VRX8aXGo/i0wIhfl2jaIg8WfwD6tg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=sZqbpBEnE1jt8O0ugwlZjOTE0lf4LbH9bShKF/8ZzVyDdslDkf3EOF6pA7QSXK5SFz+RXMjtXAKT1E1mx+5cX8gxCI0gw0bQq2FkYlP+tgCsGClJOzrlZDEXs892eXwQ5Rx9eav1Ad+T9m30gIMQHdgrq+11dg7/ySuw+5rYgRU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MyOS9qVm; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MyOS9qVm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765797627; x=1797333627; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=PRfThtBw+tIqQ8VRX8aXGo/i0wIhfl2jaIg8WfwD6tg=; b=MyOS9qVmQT4XqR8uzfp2OuX37DD1BHwd+3S/zAXoPDDiyH3+mcEVwSLI D1CBfCnEhXUuMuCgqqULTZs8SFWCRoBL5o954vt5kLhMegbm39wagzrBX wJAVIpivZgSagwRZyfHdEEFkbnjPOTP48KcPvpGdFwOD48AB1Y4TqWJ91 p7slJkWdLEtuozqNi80uTrAvGmvNysmre9FWkqclejepeQK+y9u9NHy7Y gJXFhvpZRgTxXv6dL05LvURstADkcI1AzlBb13EKzcJUtD7xU/L4Sph9l 3Yg+jU8wdWNdK1Zp3S0nBejIqnkS244uJE5zg+d6wH5uIGqCodTe+txRD Q==; X-CSE-ConnectionGUID: ejQxZbdSRUq5Sd6J7HJ/qQ== X-CSE-MsgGUID: D5+mlWHxSKiCP1PsBWh44w== X-IronPort-AV: E=McAfee;i="6800,10657,11642"; a="67731737" X-IronPort-AV: E=Sophos;i="6.21,150,1763452800"; d="scan'208";a="67731737" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 03:20:27 -0800 X-CSE-ConnectionGUID: RP9AVwgnT0q7dN7EnnG1IQ== X-CSE-MsgGUID: h9Zc6w8oSd6dxXebMCNkwQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,150,1763452800"; d="scan'208";a="197690197" Received: from mjarzebo-mobl1.ger.corp.intel.com (HELO pujfalus-desk.intel.com) ([10.245.246.95]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 03:20:24 -0800 From: Peter Ujfalusi To: lgirdwood@gmail.com, broonie@kernel.org Cc: linux-sound@vger.kernel.org, kai.vehmanen@linux.intel.com, ranjani.sridharan@linux.intel.com, yung-chuan.liao@linux.intel.com, pierre-louis.bossart@linux.dev, seppo.ingalsuo@linux.intel.com Subject: [PATCH 0/8] ASoC: SOF: ipoc4: Support for generic bytes controls Date: Mon, 15 Dec 2025 13:20:40 +0200 Message-ID: <20251215112048.16331-1-peter.ujfalusi@linux.intel.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-sound@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, We support bytes control type for set and get, but these are module specific controls and there is no way to handle notifications from them in a generic way. Each control have module specific param_id and this param_id is only valid in the module's scope, other modules might use the same id for different functions for example. This series will add a new generic control type, similar to the existing ones for ENUM and SWITCH, which can be used to create bytes controls which can send notifications from firmware on change. The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to describe bytes payload also. On set, the payload must include the sof_ipc4_control_msg_payload struct with the control's ID and data size, followed by the data. On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along with the LARGE_CONFIG_GET message as payload with the ID of the control that needs to be retrieved. The raw data is received back without additional header. A notification might contain data, in this case the num_elems reflects the size in bytes, or without data. If no data is received then the control is marked as dirty and on read the kernel will refresh the data from firmware. The series includes mandatory fixes for existing code and adds support for sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM, SWITCH or BYTES control. Regards, Peter --- Peter Ujfalusi (8): ASoC: SOF: ipc4-control: If there is no data do not send bytes update ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data ASoC: SOF: ipc4-control: Keep the payload size up to date ASoC: SOF: ipc4-topology: Set initial param_id for bytes control type ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET ASoC: SOF: ipc4: Add definition for generic bytes control ASoC: SOF: ipc4-control: Add support for generic bytes control sound/soc/sof/ipc4-control.c | 197 ++++++++++++++++++++++++++++++---- sound/soc/sof/ipc4-topology.c | 36 +++++-- sound/soc/sof/ipc4-topology.h | 9 +- sound/soc/sof/ipc4.c | 45 +++++++- 4 files changed, 252 insertions(+), 35 deletions(-) -- 2.52.0