The logger test case has a design limitation in that it
assumes the SOF DSP to remain powered up between driver reload
and start of the logger. This creates a possibility for a race
with runtime PM (RPM).

If the DSP goes to runtime suspend during this window, it is not
guaranteed that the SOF driver will provide any logs. Some logging
mechanisms save the logs that were emitted before suspend
(sof-logger/IPC3), but some not (cavstool/IPC3 and mtrace/IPC4).

To limit the window , add a simple ping of all PCM nodes just
before logger process is started. This is a crude mechanism but
something that works with all variants of SOF. End result is that
DSP will be resumed to D0 just before the logger test starts.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

The check for DSP boot assumes SOF is always card0 in the system,
and this leads to failure.

Fix the issue by using the existing sof_firmware_boot_complete()
check to wait for DSP boot to successfully complete.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

lib.sh:sof_firmware_boot_complete() ensures DSP has booted, but it does
not guarantee SOF driver probe has completed. So it is still possible
some of the interfaces SOF driver exposes to user-space are not available
(including interfaces needed to run loggers).

Tracing is initialized before ALSA card registration in SOF diver (see
snd_sof_device_probe() in SOF driver), so by waiting for ALSA card to
show up in procfs, we can guarantee tracing related interfaces have been
initialized.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>