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

Debug stream debugfs #5154

Open
wants to merge 4 commits into
base: topic/sof-dev
Choose a base branch
from

Conversation

jsarha
Copy link

@jsarha jsarha commented Aug 23, 2024

This commit simply maps the identified debug-stream debug window slot as a debugfs file.

sound/soc/sof/ipc4-debug-stream.c Outdated Show resolved Hide resolved
sound/soc/sof/ipc4-debug-stream.c Outdated Show resolved Hide resolved
sound/soc/sof/ipc4-debug-stream.h Outdated Show resolved Hide resolved
sound/soc/sof/ipc4-debug-stream.c Outdated Show resolved Hide resolved
if (!buf)
return -ENOMEM;

sof_mailbox_read(sdev, offset, buf, SOF_IPC4_DEBUG_SLOT_SIZE);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would not make sense to skip the magic number as the telemetry does?
If so, then probably creating a single function to get the content of a debug slot by type and use that in both?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @ujfalusi , I do not follow. What magic number you are referring to?

About unifying the telemetry and debug-stream code I agree on general level, but there is the exception part in the current telemetry code, that I do not fully comprehend. And then telemetry debugfs does not support seek and there are some other subtle differences. To unify the code I should know how telemetry debugfs file is used, so that I can verify it works with code borrowed from debug-stream -side. The other way around wont work, as my python debug-stream client disagrees with the telemetry debugfs implementation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsarha, the first u32 in a slot is the magic number or tag or slot type, it is SOF_IPC4_DEBUG_SLOT_DEBUG_STREAM in this case. For telemetry it is SOF_IPC4_DEBUG_SLOT_TELEMETRY.
The real data is after this magic number.

The sof_ipc4_query_exception_address() is just wrapping the sof_ipc4_find_debug_slot_offset_by_type() call and skips the magic number to get a pointer for the slot data.
The telemetry.c uses memcpy_fromio() instead sof_mailbox_read(), they do the same at the end.

If I look at the two files from a distance, they are 99% identical with the only difference is:
SOF_IPC4_DEBUG_SLOT_DEBUG_STREAM vs SOF_IPC4_DEBUG_SLOT_TELEMETRY
"debug_stream" vs "exception"

The only tricky part is how to know which slot you need to return, for which the debug-dsp-ops.c file gives an answer.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I know how the debug slots work, and I understand the basic structure, but while I was implementing debug-stream, I started off with how telemetry debugfs was implemented, but needed to change couple of things to get it to work.

Only thing is, that I would like to test the telemetry still works, if I unify the debugfs behind a single function that follows the debug-stream implementation... but I have no idea how telemetry should be used and I can not find any client etc. But yes, maybe I just do it and hope the possible issues will come up in review.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsarha, the first u32 in a slot is the magic number or tag or slot type, it is SOF_IPC4_DEBUG_SLOT_DEBUG_STREAM in this case. For telemetry it is SOF_IPC4_DEBUG_SLOT_TELEMETRY. The real data is after this magic number.

Oh, sorry @ujfalusi I read hastily. This is not how the debug slots work. The slot allocation is done in the descriptor slot:

https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/intel/intel_adsp/common/include/adsp_debug_window.h

And the whole allocated 4k slot can be used freely, no need to skip any words. And I rather not skip any words in the generic debug slot debufs mapping, just because its required in telemetry slot when its used for exception dumping.

Maybe I could parameterize it, thou that would look funny too. It would be really helpful to know how (with what tool?) the exception file is used. I'd rather skip the first word in the exception interpreting tool than in in the generic debug slot debugfs implementation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, yes, you are right. The telemetry slot itself can be split up to different sections and internally it is using 'separator magic' numbers for identification (in theory, but that's another story).
So, here, the ipc4-telemetry.c is exposing the 'exception' section of the telemetry slot, which I guess is the only one present when an exception happens and it will overtake the whole telemetry slot.
This is the reason why the first u32 is skipped I guess, it is a marker in the scope of the telemetry slot.

Copy link
Collaborator

@ujfalusi ujfalusi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsarha, what I would do is:
rename the ipc4-telemetry.c to ipc4-debugfs.c or something generic and use this to export the raw slots on the needed base.
You can have a single exported function as entry point, you can even move here the sof_ipc4_find_debug_slot_offset_by_type() function...

I know, mtrace is also uses debug slot, but it has been special cased out...

The ipc4-telemetry.h should remain as it is.

Jyri Sarha added 4 commits August 30, 2024 00:59
Adds sof_ipc4_create_debug_slot_debugfs_node() -function for mapping
an SOF Intel ipc4 debug window slot as debugfs file. The actual slot
is specified with slot_type parameter that are defined in
include/sound/sof/ipc4/header.h and the slot is found with
sof_ipc4_find_debug_slot_offset_by_type(). It also takes the
data_offset parameter that specifies where the payload data in the
slot begins. The portion that is mapped to the debugfs file is
everything after the offset. The last parameter is the name of the
file.

Signed-off-by: Jyri Sarha <[email protected]>
Add new debug window slot type for debug-stream protocol. For details see
src/debug/debug_stream/debug_stream_slot.h under SOF sources [1].

[1] https://github.com/thesofproject/sof

Signed-off-by: Jyri Sarha <[email protected]>
Maps debug-stream debug window slot as debugfs file with
sof_ipc4_create_debug_slot_debugfs_node() -function.

Signed-off-by: Jyri Sarha <[email protected]>
… file

Remove ipc4-telemetry.[ch] and use sof_ipc4_create_debug_slot_debugfs_node()
instead for mapping "exception" debugfs file. In running system the
SOF_IPC4_DEBUG_SLOT_TELEMETRY is used for telemetry data, but if configured,
Zephyr exception data is dumped in the same debug window slot, right after
the separator word.

Signed-off-by: Jyri Sarha <[email protected]>
@jsarha
Copy link
Author

jsarha commented Aug 30, 2024

@jsarha, what I would do is: rename the ipc4-telemetry.c to ipc4-debugfs.c or something generic and use this to export the raw slots on the needed base. You can have a single exported function as entry point, you can even move here the sof_ipc4_find_debug_slot_offset_by_type() function...

I know, mtrace is also uses debug slot, but it has been special cased out...

The ipc4-telemetry.h should remain as it is.

@ujfalusi I took a shot at this. I still try make sure the zephyr tool can still read the execption file.

@jsarha
Copy link
Author

jsarha commented Sep 25, 2024

@ujfalusi @kv2019i , according to my tests the exception debugfs file works just as well after this change as it did before. That is, neither version works. I have no idea where the problem is, but I am quite sure this version is equivalent to the older version, so I'd hope to get this merged.

@lgirdwood
Copy link
Member

@jsarha @ujfalusi ping - can we unblock ?

@jsarha
Copy link
Author

jsarha commented Oct 23, 2024

@jsarha @ujfalusi ping - can we unblock ?

This is not as important anymore as before, as the latest debug_stream.py is able to access its debug-window-slot directly using cavstool.py functions. However, I still think the debugfs file is a cleaner way to do this, so I still think this PR is valid.

@lgirdwood
Copy link
Member

@jsarha @ujfalusi ping - can we unblock ?

This is not as important anymore as before, as the latest debug_stream.py is able to access its debug-window-slot directly using cavstool.py functions. However, I still think the debugfs file is a cleaner way to do this, so I still think this PR is valid.

ok, we can park now and see how well existing tools work - if slow or inconsistent we can continue here.

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

Successfully merging this pull request may close these issues.

4 participants