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

Possible missed trace logs at the beginning #3448

Closed
dbaluta opened this issue Feb 20, 2022 · 2 comments
Closed

Possible missed trace logs at the beginning #3448

dbaluta opened this issue Feb 20, 2022 · 2 comments
Assignees

Comments

@dbaluta
Copy link
Collaborator

dbaluta commented Feb 20, 2022

Looking at the code in snd_sof_init_trace_ipc we have:

int snd_sof_init_trace_ipc(struct snd_sof_dev *sdev)
{
/* .. */
       /* send IPC to the DSP */
       ret = sof_ipc_tx_message(sdev->ipc,
                                params.hdr.cmd, &params, sizeof(params),
                               &ipc_reply, sizeof(ipc_reply));

<<<HERE>>
       ret = snd_sof_dma_trace_trigger(sdev, SNDRV_PCM_TRIGGER_START);
       sdev->dtrace_is_enabled = true;
}

Then at snd_sof_trace_update_pos we have:

int snd_sof_trace_update_pos(struct snd_sof_dev *sdev,
»       »       »            struct sof_ipc_dma_trace_posn *posn)
{

        if (sdev->dtrace_is_enabled && sdev->host_offset != posn->host_offset) {                                                                                                                                   
               sdev->host_offset = posn->host_offset;
              wake_up(&sdev->trace_sleep);
        }

It is possible that the reply for SOF_IPC_TRACE_DMA_PARAMS_EXT to arrive at the marker <<<HERE>> so, snd_sof_trace_update_pos will miss the DMA trace position update because dtrace_is_enabled is set too late.

This happens all the time on i.MX with the result that we cannot see the DMA trace boot logs until later when some other log messages are generated.

Is this a known issue on other platforms?

Cc: @marc-hb

@ujfalusi
Copy link
Collaborator

On Intel platforms the copy to host buffer can only work after the snd_sof_dma_trace_trigger(sdev, SNDRV_PCM_TRIGGER_START) call as before that the DMA is not working.

Now the dtrace in firmware uses sync dma copy, so this should be fine.

But on architectures where the DMA is not split like it is with HDA, this could cause ignored updates.

@dbaluta, in sof-dev we now have three states for the dtrace:

enum sof_dtrace_state {
	SOF_DTRACE_DISABLED,
	SOF_DTRACE_STOPPED,
	SOF_DTRACE_ENABLED,
};

I think we could try to change the logic that we switch from DISABLED to STOPPED before sending the PARAMS_EXT and we only ignore the position update notification if the state is DISABLED.
This way we would record the new position and in theory you should be able to get the log right away.

@dbaluta dbaluta closed this as completed Feb 25, 2022
marc-hb added a commit to marc-hb/sof-test that referenced this issue Jul 14, 2022
I added this wait for D3 in commit 6a8871f ("check-sof-logger:
reload drivers first") that made the test more deterministic but I'm not
100% sure why it's now waiting for D3. Probably to minimize changes
because before the addition of reload_drivers() the DSP was most likely
in D3.

While I recently made cavstool compatible with D3, the protocol used by
cavstool is still different from the other traces: it won't print ANY
log while the DSP is off. So change the test behavior to grab logs
immediately after reloading the drivers / rebooting the DSP.

This may also help with
thesofproject/sof#4333,
thesofproject/linux#3448
and others linked from there.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to marc-hb/sof-test that referenced this issue Jul 15, 2022
I added this wait for D3 in commit 6a8871f ("check-sof-logger:
reload drivers first") that made the test more deterministic but I'm not
100% sure why it's now waiting for D3. Probably to minimize changes
because before the addition of reload_drivers() the DSP was most likely
in D3.

While I recently made cavstool compatible with D3, the protocol used by
cavstool is still different from the other traces: it won't print ANY
log while the DSP is off. So change the test behavior to grab logs
immediately after reloading the drivers / rebooting the DSP.

This may also help with
thesofproject/sof#4333,
thesofproject/linux#3448
and others linked from there.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb added a commit to thesofproject/sof-test that referenced this issue Jul 19, 2022
I added this wait for D3 in commit 6a8871f ("check-sof-logger:
reload drivers first") that made the test more deterministic but I'm not
100% sure why it's now waiting for D3. Probably to minimize changes
because before the addition of reload_drivers() the DSP was most likely
in D3.

While I recently made cavstool compatible with D3, the protocol used by
cavstool is still different from the other traces: it won't print ANY
log while the DSP is off. So change the test behavior to grab logs
immediately after reloading the drivers / rebooting the DSP.

This may also help with
thesofproject/sof#4333,
thesofproject/linux#3448
and others linked from there.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants