Skip to content
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

Conversation

yaochunhung
Copy link

@yaochunhung yaochunhung commented Jan 4, 2022

…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

@yaochunhung
Copy link
Author

Please reference the discussion in thesofproject/sof#5137 (comment) Thank.

@@ -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 */

Copy link
Collaborator

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.

Copy link
Author

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

Copy link
Collaborator

@ujfalusi ujfalusi Jan 10, 2022

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?

Copy link
Author

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;
}

Copy link
Member

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?

Copy link
Member

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

Copy link
Member

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?

@yaochunhung yaochunhung force-pushed the sof-continuous-update-flag branch 2 times, most recently from 93e9868 to 0e4fe79 Compare January 5, 2022 00:59
@lgirdwood lgirdwood added the ABI involves ABI changes, need extra attention label Jan 5, 2022
@lgirdwood
Copy link
Member

Corresponding FW PR is thesofproject/sof#5137

@lgirdwood
Copy link
Member

@yaochunhung ABI is 3.21, this will need updated in header file.

@yaochunhung
Copy link
Author

yaochunhung commented Jan 5, 2022

@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
https://github.com/thesofproject/linux/blob/topic/sof-dev/include/uapi/sound/sof/abi.h#L29

@yaochunhung
Copy link
Author

@lgirdwood I have updated abi version v3.21. please help to check it. thanks.

@kv2019i
Copy link
Collaborator

kv2019i commented Jan 10, 2022

@yaochunhung wrote:

@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 https://github.com/thesofproject/linux/blob/topic/sof-dev/include/uapi/sound/sof/abi.h#L29

The kernel side header is currently a bit under discussion, see #3298
and #3296 .

Let's try to merge PR3298 first and then you can bump to 3.21 in this PR.
@yaochunhung I have up on PR3296. Please just bump the version to 3.21 in your PR directly.

Copy link
Collaborator

@kv2019i kv2019i left a 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.

@plbossart
Copy link
Member

@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?

@yaochunhung
Copy link
Author

@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
In host side, I implement pcm pointer callback as below(Sorry I didn't send this PR yet due to it is related with #3258 since I need to modify mt8195_ipc_msg_data)

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;
}

@plbossart
Copy link
Member

@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 In host side, I implement pcm pointer callback as below(Sorry I didn't send this PR yet due to it is related with #3258 since I need to modify mt8195_ipc_msg_data)

I don't follow at all, your reply mentions both interrupts generated by the firmware and IPC initiated by the kernel. which is it?
What does 'original host period size' mean? We don't modify period sizes in SOF, we take what the application specified. Are you talking about the firmware host period, which represents a buffer in DSP memory, or a kernel period, which represents a buffer in system DDR?

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...

@yaochunhung
Copy link
Author

@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.

Copy link
Member

@plbossart plbossart left a 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.

@yaochunhung
Copy link
Author

@lgirdwood I have rebase to resolve the conflicts. Thanks.

@lgirdwood
Copy link
Member

@plbossart @ranj063 @ujfalusi is there anything blocking this now from kernel side ?

ranj063
ranj063 previously approved these changes Apr 14, 2022
@plbossart
Copy link
Member

@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...

@dbaluta
Copy link
Collaborator

dbaluta commented Apr 14, 2022

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:

commit f6c48532717220a9390e664d6c73e7e6df944206
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Wed Oct 6 10:12:48 2021 -0700

    IPC: DAI: Expand DAI_CONFIG IPC flags
    
    Some DAI components, such as HDaudio, need to be stopped in two steps
    a) stop the DAI component
    b) stop the DAI DMA
    
    This patch enables this two-step stop by expanding the DAI_CONFIG
    IPC flags and split them into 2 parts.
    
    The 4 LSB bits indicate when the DAI_CONFIG IPC is sent, ex: hw_params,
    hw_free or pause. The 4 MSB bits are used as the quirk flags to be used
    along with the command flags. The quirk flag called
    SOF_DAI_CONFIG_FLAGS_2_STEP_STOP shall be set along with the HW_PARAMS
    command flag, i.e. before the pipeline is started so that the stop/pause
    trigger op in the FW can take the appropriate action to either
    perform/skip the DMA stop. If set, the DMA stop will be executed when the
    DAI_CONFIG IPC is sent during hw_free. In the case of pause, DMA pause
    will be handled when the DAI_CONFIG IPC is sent with the PAUSE command
    flag.
    
    Along with this, modify the signature for the hda_ctrl_dai_widget_setup/
    hda_ctrl_dai_widget_free() functions to take additional flags as an
    argument and modify all users to pass the appropriate quirk flags. Only
    the HDA DAI's need to pass the SOF_DAI_CONFIG_FLAGS_2_STEP_STOP quirk
    flag during hw_params to indicate that it supports two-step stop and
    pause.
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

diff --git a/src/include/kernel/abi.h b/src/include/kernel/abi.h
index b9847c7de..c9db26448 100644
--- a/src/include/kernel/abi.h
+++ b/src/include/kernel/abi.h
@@ -29,7 +29,7 @@
 
 /** \brief SOF ABI version major, minor and patch numbers */
 #define SOF_ABI_MAJOR 3
-#define SOF_ABI_MINOR 19
+#define SOF_ABI_MINOR 20
 #define SOF_ABI_PATCH 0

@lgirdwood
Copy link
Member

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:

commit f6c48532717220a9390e664d6c73e7e6df944206
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Wed Oct 6 10:12:48 2021 -0700

@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 ?

@dbaluta
Copy link
Collaborator

dbaluta commented Apr 20, 2022

@yaochunhung can you make a summary of this PR? Is it ready for merge? Are there any open issues?

@lgirdwood lgirdwood added the P1 Blocker bugs or important features label Apr 20, 2022
@lgirdwood
Copy link
Member

@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.

@plbossart
Copy link
Member

once #3603 is merged, this PR can be rebased and merged.

@plbossart
Copy link
Member

@lgirdwood @kv2019i @ujfalusi can you approve #3603 so that this PR can proceed.

@yaochunhung
Copy link
Author

@lgirdwood @plbossart @dbaluta, I rebase this PR, please help to check it. thanks.

@miRoox
Copy link

miRoox commented Apr 22, 2022

SOFCI TEST

#define SOF_ABI_MINOR 20
#define SOF_ABI_PATCH 1
#define SOF_ABI_MINOR 21
#define SOF_ABI_PATCH 0
Copy link
Member

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.

Copy link
Author

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.

Copy link
Author

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>
@yaochunhung
Copy link
Author

@lgirdwood @plbossart @dbaluta Please help to check if this PR is good to merge? Thanks.

@dbaluta
Copy link
Collaborator

dbaluta commented May 2, 2022

@lgirdwood there is a boot failure for ADLP not sure it this PR has any thing to do with it.

@dbaluta
Copy link
Collaborator

dbaluta commented May 3, 2022

@kv2019i ok with you?

@plbossart plbossart merged commit 3ea17bd into thesofproject:topic/sof-dev May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ABI involves ABI changes, need extra attention P1 Blocker bugs or important features
Projects
Development

Successfully merging this pull request may close these issues.

None yet

10 participants