-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASoC: SOF: ipc: introduce cont_update_posn in sof_ipc_stream_params s… #3353
ASoC: SOF: ipc: introduce cont_update_posn in sof_ipc_stream_params s… #3353
Conversation
Please reference the discussion in thesofproject/sof#5137 (comment) Thank. |
f735554
to
3e154f1
Compare
@@ -85,8 +85,9 @@ struct sof_ipc_stream_params { | |||
|
|||
uint32_t host_period_bytes; | |||
uint16_t no_stream_position; /**< 1 means don't send stream position */ | |||
uint16_t cont_update_posn; /**< 1 means continue update stream position */ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we just take only 1 byte from reserved area. We are wasting so much space to keep a boolean information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dbaluta yes, I could modify it as one byte. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will set the cont_update_posn
to one in kernel unconditionally or what is the condition to set it?
Iow, will the use of this new flag going to be:
+ if (v->abi_version >= SOF_ABI_VER(3, 21, 0))
+ msg->cont_update_posn = 1;
If it is then I argue that there is no point of having this flag in the first place and just do it unconditionally in firmware?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ujfalusi Currently I propose to set it in the stream callback function pcm_hw_params e.g.
#define CONTINUOUS_UPDATE_POSITION 1
static int mt8195_dsp_pcm_hw_params(struct snd_sof_dev *sdev,
struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct sof_ipc_stream_params *ipc_params)
{
struct sof_ipc_fw_version *v = &sdev->fw_ready.version;
if (v->abi_version >= SOF_ABI_VER(3, 21, 0))
ipc_params->cont_update_posn = CONTINUOUS_UPDATE_POSITION;
return 0;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be the default across all platforms, I don't really see a reason why this capability needs to be added 4 times when we all have to support the Chrome conformance suite. @cujomalainey any comments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed, given we know the current default does not pass the test, lets push this into the core and replace the existing default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yaochunhung can you please add a user for this new capability?
93e9868
to
0e4fe79
Compare
Corresponding FW PR is thesofproject/sof#5137 |
@yaochunhung ABI is 3.21, this will need updated in header file. |
@lgirdwood The original abi in kernel looks like different from firmware(kernel only 3.18, firmware 3.20). Should I need to make them consistent? Thanks |
0e4fe79
to
0a9ab54
Compare
@lgirdwood I have updated abi version v3.21. please help to check it. thanks. |
@yaochunhung wrote:
The kernel side header is currently a bit under discussion, see #3298
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @yaochunhung , this looks like a good addition to the IPC interface. I have some comments on how this is implemented, please see inline.
@yaochunhung I am not sure I understand the ask, and this seems to be an IPC interface change without the matching firmware changes? If the idea was to have the firmware send an IPC message, hence an interrupt, on a very frequent basis, then this idea will by construction get in the way of power savings. You might want to use the memory windows or some sort of shared SRAM to provide the precise position instead. It's my understanding that ChromeOS relies on the no-interrupt mode when available, so it's be rather odd to have an interrupt added just to add more precision to the elapsed time? |
@plbossart I only update IPC message more frequently and send interrupt to host based on original host period size. Please see firmware patch thesofproject/sof@af602b1 snd_pcm_uframes_t mtk_adsp_pcm_pointer(struct snd_sof_dev *sdev,
struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = asoc_substream_to_rtd(substream);
struct snd_soc_component *scomp = sdev->component;
struct snd_sof_pcm *spcm;
struct sof_ipc_stream_posn posn;
struct snd_sof_pcm_stream *stream;
snd_pcm_uframes_t pos;
int ret;
spcm = snd_sof_find_spcm_dai(scomp, rtd);
if (!spcm) {
dev_warn_ratelimited(sdev->dev, "warn: can't find PCM with DAI ID %d\n",
rtd->dai_link->id);
return 0;
}
stream = &spcm->stream[substream->stream];
ret = snd_sof_ipc_msg_data(sdev, stream->substream, &posn, sizeof(posn));
if (ret < 0) {
dev_warn(sdev->dev, "failed to read stream position: %d\n", ret);
return 0;
}
memcpy(&stream->posn, &posn, sizeof(posn));
pos = spcm->stream[substream->stream].posn.host_posn;
pos = bytes_to_frames(substream->runtime, pos);
return pos;
} |
I don't follow at all, your reply mentions both interrupts generated by the firmware and IPC initiated by the kernel. which is it? if you only send an IPC from the kernel to the firmware on a .pointer callback, then what does this patch actually do? conversely, if the firmware can send notifications to the kernel on a position update, then why would you need to request the position on a .pointer as well? Too many questions as you can see... |
@plbossart For mt8195, I set no_stream_position as zero and DSP will send stream position in the host_update_position function. where I said "original host period size" is the host_period_bytes which is set in host_params(the value is sent from host side, sof_pcm_hw_params: pcm.params.host_period_bytes = params_period_bytes(params);) === DSP firmware part ===
src/audio/host.c
if (hd->host_period_bytes != 0 &&
hd->report_pos >= hd->host_period_bytes) {
hd->report_pos = 0;
/* send timestamped position to host
* (updates position first, by calling ops.position())
*/
pipeline_get_timestamp(dev->pipeline, dev, &hd->posn);
mailbox_stream_write(dev->pipeline->posn_offset,
&hd->posn, sizeof(hd->posn));
ipc_msg_send(hd->msg, &hd->posn, false);
} In the .pointer callback function, I use snd_sof_ipc_msg_data to read the host stream position. ===kernel part===
sound\soc\sof\mediatek\mt8195\mt8195.c)
static int mt8195_ipc_msg_data(struct snd_sof_dev *sdev,
struct snd_pcm_substream *substream,
void *p, size_t sz)
{
if (!substream || !sdev->stream_box.size) {
sof_mailbox_read(sdev, sdev->dsp_box.offset, p, sz);
} else {
struct sof_mtk_adsp_stream *mstream = substream->runtime->private_data;
/* The stream might already be closed */
if (!mstream)
return -ESTRPIPE;
sof_mailbox_read(sdev, mstream->stream.posn_offset, p, sz);
}
return 0;
} For why need to provide this callback function. It is because when I test alsa_conformance_test, I found there are two points to update hw pointer. One is snd_pcm_period_elapsed, and it is called by IPC notification from DSP(SOF_IPC_STREAM_POSITION). Another is called from snd_pcm_common_ioctl(snd_pcm_hwsync) and it is not triggered by DSP IPC notification(Maybe somewhere in the host but I am not familiar with alsa_conformane_test codes and not sure how it can trigger snd_pcm_hwsync.) Therefore I implement this .pointer callback function to get more precisive value from DSP side. Thanks. |
0a9ab54
to
f837de3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not getting the idea, see comments on the firmware side. You have not addressed my concerns on the number of interrupts generated by the firmware.
@lgirdwood I have rebase to resolve the conflicts. Thanks. |
@plbossart @ranj063 @ujfalusi is there anything blocking this now from kernel side ? |
there's an unexplained jump from ABI 19 to 21, and no user of that new flag... |
FW ABI bump that we forgot to expand to Linux kernel ABI is this:
|
@ranj063 IIRC this was all part of the DMA flow update for PM (which is now all working), could we be only missing the ABI vesion update here ? |
@yaochunhung can you make a summary of this PR? Is it ready for merge? Are there any open issues? |
Ack - lest unblock this ASAP, all ABI is blocked on this. |
once #3603 is merged, this PR can be rebased and merged. |
@lgirdwood @kv2019i @ujfalusi can you approve #3603 so that this PR can proceed. |
3fcd766
to
e2a32dd
Compare
@lgirdwood @plbossart @dbaluta, I rebase this PR, please help to check it. thanks. |
SOFCI TEST |
#define SOF_ABI_MINOR 20 | ||
#define SOF_ABI_PATCH 1 | ||
#define SOF_ABI_MINOR 21 | ||
#define SOF_ABI_PATCH 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I screwed up and should have reset this patch level earlier. I added #3610 to fix this, you'll have to rebase when it's merged. My bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart Never mind, I will rebase this PR when #3610 is merged. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart I rebase this PR, thanks.
…truct The host stream position is updated when no_stream_position is set as 0. However current implementation updates host stream position only when report data is larger than or equal to host period size which is decided by the period size of host side. It maybe cause host stream position update not in time. Therefore this patch introduces another field "cont_update_posn", a boolean value aimed to update host stream position continuously and based on period size of pipeline. It can get better precise when need to update host stream position from firmware. Signed-off-by: YC Hung <yc.hung@mediatek.com>
e2a32dd
to
9b9d863
Compare
@lgirdwood @plbossart @dbaluta Please help to check if this PR is good to merge? Thanks. |
@lgirdwood there is a boot failure for ADLP not sure it this PR has any thing to do with it. |
@kv2019i ok with you? |
…truct
The host stream position is updated when no_stream_position is set as 0.
However current implementation updates host stream position only when report
data is larger than or equal to host period size which is decided by the
period size of host side. It maybe cause host stream position update not
in time. Therefore this patch introduces another field "cont_update_posn",
a boolean value aimed to update host stream position continuously and based
on period size of pipeline. It can get better precise when need to update
host stream position from firmware.
Signed-off-by: YC Hung yc.hung@mediatek.com