Within SDCA collections of Channels are referred to as Clusters, each
Channel within a Cluster can have various properties attached to it.
For example a stereo audio stream, would have a Cluster with 2 Channels
one marked as left and the other as right. Various Clusters are
specified in DisCo/ACPI and controls then allow the class driver to
select between these channel configurations. Add support for parsing
these Cluster definitions.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DisCo/SDCA contains small buffers of data that hold ranges of valid
values for the various SDCA Controls. Add support for parsing these
from ACPI.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Each SDCA Entity will contain a number of Controls, these are
basically equivalent to registers. Although a single Control will only
ever contain a single field. Some of these would map directly to ALSA
controls once more of the SDCA class driver is implemented. These
controls are parsed out of the DisCo ACPI tables.
One small todo here is that each Control can have multiple
sub-entries (Control Numbers), these are typically used to represent
channels. Whilst support is present for these, currently the
ACPI properties that would allow differing defaults for each channel
are not parsed. But there is nothing here that should prevent that
being added in the future.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Within SDCA there is a special Entity called Entity 0 which is used
to hold Function level controls. Whilst Entity 0 isn't a full SDCA
Entity, it is helpful to add an sdca_entity structure for it. This
will allow it to be treated identically in the code that handles
SDCA Controls.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Each SDCA Function may contain a table of register writes that should be
written out before the Function is used. Add code to parse this table
from the DisCo tables in ACPI.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a helper function to parse all the Function and Entity
information from ACPI. In SDCA each device may have several Functions
and each corresponds to a specific audio capability such as say
amplifier playback or microphone capture. Each Function then contains
a number of Entities that represent individual parts of the audio
signal chain and are linked together in a graph similar to DAPM.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix up some variable/struct member naming, add some missing kerneldoc
and fix some minor formatting/whitespace issues.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20250205113801.3699902-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, patch_sdca_function_type() both patches the function type
for older SDCA revisions, and reports the name of the function. In
general it is cleaner to have a single function only do a single
task, so split these operations into two separate functions.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20241220173516.907406-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It is not helpful to error out on some SDCA function types, we
might as well report the correct name and let the driver core
simply not bind a driver to those functions for which the code
lacks support. Also given no functions currently have support,
it seems odd to select some as unsupported.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20241220173516.907406-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SDCA only supports 3-bits for the function address, but the ACPI value
is 64-bits. Update the code that parses this to do a bounds check
and error out on invalid addresses. Currently, an invalid address
would truncate to the bottom 3-bits when used and thus use a likely
incorrect address. With the bounds check, it is also now safe to
shrink the size of the adr member of sdca_function_desc to a u8 and
rearrange the struct members to pack better with the new size of adr.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20241220173516.907406-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All the error messages in the SDCA code manually print the function
in the output, update these to use dev_fmt instead. Whilst making
the changes tweak a couple of the error messages to make them a
little shorter.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20241220173516.907406-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Several of the SDCA files don't include all the headers they use
locally. These are included by the point of use through other
headers, so it is not currently causing any issues. However, files
should directly include things they directly use, so add the
missing header includes.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20241220173516.907406-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit cdd30ebb1b ("module: Convert symbol namespace to string
literal") changes the arguments for various module symbol macros
including some that we've aded new uses for. Merge the commit up to
avoid problems in -next.
Signed-off-by: Mark Brown <broonie@kernel.org>
We should use *-y instead of *-objs in Makefile for the module
objects. *-objs is used rather for host programs.
Fixes: 3a513da1ae ("ASoC: SDCA: add initial module")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20241203141823.22393-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
sdca_lookup_functions may be called by a Peripheral that is not listed
in the ACPI table. Testing adev is required to avoid kernel NULL pointer
dereference.
Fixes: 3a513da1ae ("ASoC: SDCA: add initial module")
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20241113064133.162501-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SND_SOC_SDCA can't be optional when SND_SOC_ACPI_INTEL_SDCA_QUIRKS is
selected. IS_REACHABLE can prevent the link error. However it is not
suitable for this case. When CONFIG_SND_SOC_ACPI_INTEL_SDCA_QUIRKS is
Y and CONFIG_SND_SOC_SDCA is M, the SDCA helpers will be empty and
return false. But we need the helpers to do their jobs whenSND_SOC_SDCA
is M.
IOW, the SDCA library is not optional for Intel platforms where the
SDCA_QUIRK is selected.
Also, make SND_SOC_SDCA invisible. SND_SOC_SDCA should be selected if
a device supports SDCA. User should not unselect it.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202411021722.DiX1Y5sf-lkp@intel.com/
Suggested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://patch.msgid.link/20241106055810.10123-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a generic match function for quirks, chances are we are going to
have lots of those...
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241016102333.294448-6-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add new module for SDCA (SoundWire Device Class for Audio) support.
For now just add a parser to identify the SDCA revision and the
function mask.
Note that the SDCA definitions and related MIPI DisCo properties are
defined only for ACPI platforms and extracted with _DSD helpers. There
is currently no support for Device Tree in the specification, the
'depends on ACPI' reflects this design limitation. This might change
in a future revision of the specification but for SDCA 1.0 ACPI is the
only supported type of platform firmware.
The SDCA library is defined with static inline fallbacks, which will
allow for unconditional addition of SDCA support in common parts of
the code.
The design follows a four-step process:
1) Basic information related to Functions is extracted from MIPI DisCo
tables and stored in the 'struct sdw_slave'. Devm_ based memory
allocation is not allowed at this point prior to a driver probe, so we only
store the function node, address and type.
2) When a codec driver probes, it will register subdevices for each
Function identified in phase 1)
3) a driver will probe for each subdevice and addition parsing/memory
allocation takes place at this level. devm_ based allocation is highly
encouraged to make error handling manageable.
4) Before the peripheral device becomes physically attached, register
access is not permitted and the regmaps are cache-only. When
peripheral device is enumerated, the bus level uses the
'update_status' notification; after optional device-level
initialization, the codec driver will notify each of the subdevices so
that they can start interacting with the hardware.
Note that the context extracted in 1) should be arguably be handled
completely in the codec driver probe. That would however make it
difficult to use the ACPI information for machine quirks, and
e.g. select different machine driver and topologies as done for the
RT712_VB handling later in the series. To make the implementation of
quirks simpler, this patchset extracts a minimal amount of context
(interface revision and number/type of Functions) before the codec
driver probe, and stores this context in the scope of the 'struct
sdw_slave'.
The SDCA library can also be used in a vendor-specific driver without
creating subdevices, e.g. to retrieve the 'initialization-table'
values to write platform-specific values as needed.
For more technical details, the SDCA specification is available for
public downloads at https://www.mipi.org/mipi-sdca-v1-0-download
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20241016102333.294448-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
