[BUG] sof-test scripts shall not assume settings based on kernel parameters

[plbossart]

Filing this as a bug because I truly think there's a conceptual issue.

Overtime, sof-test has become dependent on kernel parameters, such as

• ipc_type. This should ONLY be used for CAVS/IPC4 tests. In all 'normal' case the ipc_type is a given for each platform, e.g. anything MTL+ is ipc4
  the following snippet is completely wrong

is_ipc4()
{           
    local ipc_type
    ipc_file=/sys/module/snd_sof_pci/parameters/ipc_type
            
    # If /sys/module/snd_sof_pci/parameters/ipc_type does not exist
    # the DUT is running IPC3 mode <<< OF COURSE NOT ON MTL+!!!
    ipc_type=$(cat $ipc_file) || {
        return 1
    }
            
    # If /sys/module/snd_sof_pci/parameters/ipc_type exists
    # If the value of file ipc_type is:
    # -1: DUT runs IPC3 mode, is_ipc4 return 1(false)
    # 1: DUT runs IPC4 mode, is_ipc4 return 0(true)
    if [ "$ipc_type" -eq 1 ]; then
        return 0
    fi
    return 1
}

• fw_path. the default is set for the kernel. overrides should only be used for things like debug key.
• tplg_path

The premise of sof-test is that the test should run without any assumption on the environment, other than what is clearly described in env-check.sh

sof-test is used by CI, it shall not depend on CI settings.

[marc-hb]

the DUT is running IPC3 mode <<< OF COURSE NOT ON MTL+!!!

I agree it's wrong. I guess it wasn't when this code was written.

I think we all agree 100% that sof-test should be independent of CI. I filed and fixed many issues along this line. "Conceptual" sounds exaggerated: I think this is just a short-term hack and bug that lingered because of a lack of maintenance.

But now the question is: how can userspace reliably tell which IPC version is currently active? To avoid sof-test hacks, the kernel must expose interfaces that allow it to be tested.

Similar problem and question in

• provide interface to query loaded firmware and topology to userspace via debugfs linux#3867

[plbossart]

well, if we are in the questions stage, why would sof-test need to know which IPC type is used?

Apart from the logging I don't see any reason... And the code is just awfully convoluted between is_firmware_zephyr and is_ipc4 - which means the same ...

[plbossart]

just using the existence of this directory would be enough to know which logger to use:

/sys/kernel/debug/sof/mtrace

[kv2019i]

I think this code dates back to time when we only had cAVS2.5 support with opt-in IPC4 support (i.e. there were no by-default IPC4 platfroms). Move to IPC version agnostic sounds good as we'll now have platforms that can support both and platforms that can only support one.

[marc-hb]

/sys/kernel/debug/sof/mtrace

mtrace can be disabled in IPC4, we had test failures like that in the past. It's generally not the same thing, I don't think it would be a good assumption to make.

Why can't we find the ipc_type directly?

[marc-hb]

Also: mtrace is slow and inefficient shared memory, we may want to have some DMA-based, higher throughput logging in the future like we use to have in XTOS (in addition to SRAM).

Some users use "probes" as a logging alternative.

There's also a project to use Zephyr/MIPI SysT dictionary

Logging is complicated, much more complicated than the IPC3/IPC4 question.

The logging code in sof-test is also (too) complicated.

[plbossart]

Yeah, but for now we only use mtrace. Let's make sure sof-test works with what we have.
I don't really care about future plans to be brutally honest. For now we have LNL which isn't in CI, that's my main priority.

[plbossart]

thesofproject/linux#4902 should give us what the kernel selected, no need to use kernel parameters directly