ASoC: SOF: ipc4-control: Use SOF_CTRL_CMD_BINARY as numid for bytes_ext #5281
Conversation
ujfalusi
requested review from
lgirdwood,
plbossart,
ranj063,
kv2019i,
dbaluta and
bardliao
as code owners
sound/soc/sof/ipc4-control.c
Outdated
| @@ -613,7 +613,11 @@ static int _sof_ipc4_bytes_ext_get(struct snd_sof_control *scontrol, | |||
| if (data_size > size) | |||
| return -ENOSPC; | |||
|
|
|||
| header.numid = scontrol->comp_id; | |||
| /* | |||
There was a problem hiding this comment.
and oh the link is a SOF commit? is that correct?
There was a problem hiding this comment.
@ujfalusi @singalsu is this when you do a get for reading the blob back from the DSP?
This is when user space asking for the binary content.
With IPC3 the numid was hardwired to SOF_CTRL_CMD_BINARY but IPC4 uses the component ID, which is more aligned with the numid.
Afaik it works correctly with the comp_id, but @singalsu is experimenting with some new way and that needs the numid to be SOF_CTRL_CMD_BINARY for some reason, I guess he can explain it here.
In any case, I will update the commit message and/or comment.
There was a problem hiding this comment.
and oh the link is a SOF commit? is that correct?
We don't have an issue filed for this and @singalsu only mentioned it in a comment which I tried to link. I'll drop the link tag.
There was a problem hiding this comment.
@ranj063 The issue is that it's confusing that the get response is not the same as the data that the control was set with. Also, the get response is different from every instance of component. e.g. different instances of IIR return different header despite that if they were set up with the same blob in set.
This header wasn't earlier visible but since UCMv2 chose to use the blob format with the header (#9092) I'm now changing sof-ctl to use same format.
ujfalusi
force-pushed
the
peter/sof/pr/ipc4-control-constant-numid-for-bytes-ext-01
branch
from
6f82180 to
afa5ed6
Compare
The header.numid is set to scontrol->comp_id in bytes_ext_get and it is ignored during bytes_ext_put. The use of comp_id is not quite great as it is kernel internal identification number. Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the numid during put to provide consistent and compatible identification number as IPC3. For IPC4 existing tooling also ignored the numid but with the use of SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped, providing better user experience. Reported-by: Seppo Ingalsuo <[email protected]> Closes: thesofproject#5282 Fixes: a062c88 ("ASoC: SOF: ipc4-control: Add support for bytes control get and put") Cc: [email protected] Signed-off-by: Peter Ujfalusi <[email protected]>
ujfalusi
changed the title
|
Changes since v1:
|
The header.numid is set to scontrol->comp_id in bytes_ext_get and it is
ignored during bytes_ext_put.
The use of comp_id is not quite great as it is kernel internal
identification number.
Set the header.numid to SOF_CTRL_CMD_BINARY during get and validate the
numid during put to provide consistent and compatible identification
number as IPC3.
For IPC4 existing tooling also ignored the numid but with the use of
SOF_CTRL_CMD_BINARY the different handling of the blobs can be dropped,
providing better user experience.
Reported-by: Seppo Ingalsuo [email protected]
Closes: #5282
Fixes: a062c88 ("ASoC: SOF: ipc4-control: Add support for bytes control get and put")
Cc: [email protected]
Signed-off-by: Peter Ujfalusi [email protected]