ASoC: SOF: Clarify and extend the IPC ops optionality #3986
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Other topology ops have been treated as optional, including the route_free. Handle the route_setup in a conforming way as optional callback. Note: we do not have checks for the callbacks itself which makes them all optional in practice. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The core treats all function pointer in sof_ipc_tplg_ops as optional. Update the documentation to reflect this. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
In preparation to a case when the DSP is not used. In this case the IPC communication itself has no meaning and we might not even have sdev->ipc allocated at all. The sof_ipc_get_ops() macro can be used to get a named IPC ops struct or return NULL if the sdev->ipc is not allocated. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The IPC ops are optional, but they require that the ops struct is to be allocated with all callbacks set to NULL. Update the code to extend the optionality to: sdev->ipc == NULL sdev->ipc->ops == NULL sdev->ipc->ops->[pcm] == NULL sdev->ipc->ops->[pcm]->ops == NULL (treated optional currently) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The IPC ops are optional, but they require that the ops struct is to be allocated with all callbacks set to NULL. Update the code to extend the optionality to: sdev->ipc == NULL sdev->ipc->ops == NULL sdev->ipc->ops->[tplg] == NULL sdev->ipc->ops->[tplg]->control == NULL sdev->ipc->ops->[tplg]->control->ops == NULL (treated optional currently) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The IPC ops are optional, but they require that the ops struct is to be allocated with all callbacks set to NULL. Update the code to extend the optionality to: sdev->ipc == NULL sdev->ipc->ops == NULL sdev->ipc->ops->[ops_group] == NULL sdev->ipc->ops->[pcmops_group]->ops == NULL (treated optional currently) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The IPC ops are optional, but they require that the ops struct is to be allocated with all callbacks set to NULL. Update the code to extend the optionality to: sdev->ipc == NULL sdev->ipc->ops == NULL sdev->ipc->ops->[tplg] == NULL sdev->ipc->ops->[tplg]->ops == NULL (treated optional currently) At the same time standardize the naming of the ops pointer to tplg_ops Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The IPC ops are optional, but they require that the ops struct is to be allocated with all callbacks set to NULL. Update the code to extend the optionality to: sdev->ipc == NULL sdev->ipc->ops == NULL sdev->ipc->ops->[pm/tplg] == NULL (treated optional for pm currently) sdev->ipc->ops->[pm/tplg]->ops == NULL (treated optional currently) Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The code treats the fw_tracing as optional feature but the documentation was not reflecting this. Correct it by explicitly stating that the fw_tracing is optional. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
For the sake of safety use the sof_ipc_get_ops() to fetch the fw_tracing ops to avoid cases when either sdev->ipc or sdev->ipc->ops might be NULL. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
If the sdev->fw_trace_is_supported is true then we must have the fw_tracing ops set, no need to check again. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
ujfalusi
requested review from
ajitkupandey,
bardliao,
dbaluta,
juimonen,
kuanhsuncheng,
kv2019i,
lgirdwood,
lyakh,
plbossart,
ranj063,
singalsu and
yaochunhung
as code owners
plbossart
approved these changes
Nov 2, 2022
ranj063
approved these changes
Nov 2, 2022
bardliao
approved these changes
Nov 3, 2022
Member
|
SOFCI TEST |
RanderWang
approved these changes
Nov 4, 2022
Member
|
UP_HDA not tested due to known issue -> merging |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
The existing code uses mixed definition and implementation regarding if the IPC ops is mandatory or optional.
With upcoming support for DSPless mode when the DSP and thus IPC is not used for hardware verification purpose we will have a situation when not only the ops but the IPC as whole will be not used.
This series extends the ops optionality further to cover the IPC as well and make the ops handling aligned in the core by using a helper.