ASoC: SOF: trace: sdev->host_offset management changes

[ujfalusi]

Hi,

The READ_ONCE(sdev->host_offset) alone does nothing to prevent any race regarding to host_offset change race prevention.
Introduce a new helper to do this in a correct way and while at it, print out the new offset for us to see where we are.

Additional debug prints can be added to track what is copied to user space with a simple change:

diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c
index 76c763da5804..32c3c0d8a75e 100644
--- a/sound/soc/sof/trace.c
+++ b/sound/soc/sof/trace.c
@@ -334,8 +334,10 @@ static ssize_t sof_dfsentry_trace_read(struct file *file, char __user *buffer,
 	}
 
 	/* no new trace data */
-	if (!avail)
+	if (!avail) {
+		dev_dbg(sdev->dev, "trace: nothing to copy\n");
 		return 0;
+	}
 
 	/* make sure count is <= avail */
 	if (count > avail)
@@ -349,6 +351,8 @@ static ssize_t sof_dfsentry_trace_read(struct file *file, char __user *buffer,
 	 */
 	snd_dma_buffer_sync(&sdev->dmatb, SNDRV_DMA_SYNC_CPU);
 	/* copy available trace data to debugfs */
+	dev_dbg(sdev->dev, "trace: copy to user from offset : %#llx, count: %#zx\n",
+		lpos, count);
 	rem = copy_to_user(buffer, ((u8 *)(dfse->buf) + lpos), count);
 	if (rem)
 		return -EFAULT;

[plbossart]

isn't this super-verbose? I wonder if this is going to fill the console with too many logs.

[ujfalusi]

If the debug is enabled we are printing the IPC messages (two per message). With this change it will look like this:

ipc rx: 0x90020000: GLB_TRACE_MSG: DMA_POSITION
trace: new host_offset: 0x7920
ipc rx done: 0x90020000: GLB_TRACE_MSG: DMA_POSITION

Instead of an empty indication that the position is updated we will know the value as well.
Then we have another print when the host_offset is reset to 0 (either because of closing the trace file or restart), but it is still one additional message.

It is not going to fill the console, but I always wondered what is the content behind the dtrace position update.

I can drop this print if you think we should not have it.

[ujfalusi]

I will create a draft PR on top of this to print the trace file reads as well in hope that we can catch the empty trace with that and have some clue on what is going on.

[ujfalusi]

Changes since v1:

• Rebased on sof-dev (ipc3-dtrace introduction)

[ujfalusi]

Changes since v2:

• rebased on topic/sof-dev

[plbossart]

can we remove this? I don't know what problem this tries to fix.

[ujfalusi]

certainly, this is needed for one of my DUTs, otherwise the dmesg is flooded with this message for some reason and I keep forgetting to drop this when I'm done testing before sending the PR.

I should have a hook to blow up when I try to push this patch to other branch than my wip...

[plbossart]

so this is going to conflict with your very own PR #3662 changes, specifically 024c2eb

[ujfalusi]

Yes, I'm aware of that, they are of different topic and I don't want to mix them. I'm fine with fixing up either when the time comes.

[plbossart]

@ujfalusi rebase needed.

[ujfalusi]

Changes since v3:

• dropped the unrelated patches
• the acpi hack, the printing of the new offset value and the move of the dtrace status change to avoid missing position updates (PR ASoC: SOF: trace: Make sure we are not missing the first host_offset … #3523 is the proposed solution)

[plbossart]

Any other review? @dbaluta @bardliao @ranj063 @marc-hb

[plbossart]

@ujfalusi conflict?

[ujfalusi]

@ujfalusi conflict?

Yes, I know, I'll update it tomorrow.

[ujfalusi]

Changes since v4:

• rebased on sof-dev to resolve conflict.