thesofproject
DSP Ops tester - Take 3
This PR adds the API for enabling testing the DSP ops in the driver for testing the FW boot flow, PM flow etc. It introduces a new kernel config to enable the testing debugfs interface. When enabled, normal audio operations will be disabled.
For now the following ops are supported for testing:
- boot_fw : To boot a firmware file pass from userspace by setting the fw_filename and fw_path debugfs files
- dsp_power_state: To set the DSP state. CUrrent only D3 is supported with this op. SUpport for other states will be added soon.
- fw_state: To check the current fw boot state
I am not on-board with the directions, the simple "echo 1 > boot" or echo 3 > dsp_state is too simple for scripting. These transitions take time, so there's no way for a script to know how long it needs to wait and if the transition was successful.
to note:
boot: echo on > "/sys/bus/pci/devices/0000:00:1f.3/power/control"
power off: echo auto > "/sys/bus/pci/devices/0000:00:1f.3/power/control"
I would recommend writing a 2-page summary of what we want to achieve, requirements included, otherwise we'll have lots of code review without first agreeing on what we want to achieve.
@ranj063, I'm still not sure about the use of this. We will introduce a new flow which will be tested and it is different than what we normally use, and we draw conclusion based on the test results?
I also think that if this mode is selected then we should not load topology, not create sound card. I see this as a really dangerous feature which can introduce unexpected side-effects on the normal use of the stack.
Yes, agreed. Thats what the mode does. There's no audio functionality when this mode is selected
(can't reply to the original anymore because Github does not like force pushes)
The IMR boot is the target, I don't think anyone is interested in a fresh boot, historically this created all kinds of issues in stress tests.
I don't understand this. AFAIK, the purpose of this PR is to debug boot issues. We know booting from IMR versus not have had different sets of issues in the past. So shouldn't this PR allow testing both? I don't known which default would be best but I feel like both should be possible.
Looks ok to me, I am just not sure what the next steps are?
@plbossart the first tiny next step is to have the fw boot script run with our CI to do the stress test. I also want to keep building the test script library to add more things like PM flows, DMA flows, topology loading, IPC etc
@plbossart just a minor change to add the fw filename and fw_path string lengths
@ujfalusi any objection to merging this? This will help me build upon it and add more test cases.