ASoC/soundwire: Add rt712 VB support #5199
Conversation
This structure is used to copy information from the 'sdw_slave' structures, it's better to create a flexible array of 'sdw_slave' pointers and directly access the information. This will also help access additional information stored in the 'sdw_slave' structure, such as an SDCA context. This patch does not add new functionality, it only modified how the information is retrieved. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
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>
Use SDCA helpers to get the basic information and store it in the slave context. The information will be optionally be used in codec drivers to register sub-devices for each Function. When platforms are not based on ACPI the helpers do absolutely nothing. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
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>
We shouldn't do any devm_ based allocation in the io_init(), this need to happen in the probe(). Luckily, we now have an SDCA helper to look in ACPI tables if a SMART_MIC function is exposed. FIXME: the registers are not well handled today, the regmap lists registers which are not really supported in all platforms. The regmap needs to throw an error if those registers are accessed without existing. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
The existing machine_quirk() returns a pointer to a soc_acpi_mach structure. For SoundWire/SDCA support, we need a slightly different functionality where a quirk function either validates or NACKs an initial selection, based on additional firmware/DMI information. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In theory the dailinks are created based on the number of endpoints reported in ACPI match tables, so it should harmless to add a new dailink: RT712 VA would not use it since it has only 2 endpoints. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
In theory the dailinks are created based on the number of endpoints reported in ACPI match tables, so it should harmless to add a new dailink: RT713 VA would not use it since it has only 2 endpoints. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Add a filter to skip the RT172 VB configuration if a SmartMic Function is not found in the SDCA descriptors. If the ACPI information is incorrect this can only be quirked further with DMI information. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Use the new machine_check() callback to select an alternate topology for RT712-VB devices. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
bardliao
requested review from
lgirdwood,
plbossart,
ranj063,
kv2019i and
dbaluta
as code owners
|
@bardliao : I do have one question. When can we expect SDCA 1.0 migration support related patches going to land in kernel mainline. Any ETA planned for the same? |
Sorry @vijendarmukunda I didn't get your question. What are "SDCA 1.0 migration support related patches"? Is there anything we missed for supporting SDCA codecs? |
@bardliao : As per my understanding, Current codec drivers supports SDCAv0.6 version. |
|
I think perhaps that sort of framing is coming more from the Windows side of the world. From the Linux kernel side we should just be supporting both versions as there are parts in the wild using both. The new code being added here doesn't really change any of the existing support however and there is basically no SDCA support currently in the kernel, this is really the first part. |
I got your question now @vijendarmukunda. Yes, we are working on SDCA library. However, there is no ETA so far. The SDCA 1.0 codecs will use their own codec drivers like what we do today. We could work together on the SDCA library :) |
Lookup SDCA functions and version to identify rt712/rt713 B version. This PR is from #5128