topology: Use generic name for 8qxp/8qm

[dbaluta]

i.MX8QXP / i.MX8QM have the same configuration w.r.t topology.
But since we firstly added support for 8qxp all the names use
8qxp and then for 8qm we just borrow the files but using the 8qxp
naming.

This sometimes might cause confusion. So, we group under the
umbrella of imx8 naming both i.mx8qxp and i.mx8qm.

Signed-off-by: Daniel Baluta daniel.baluta@nxp.com

[dbaluta]

@zrombel can you please check the installer/checktree task:

 # Update sof-apl-nocodec.tplg when adding or removing a default platform
diff -u tests/staging_sof_ref.txt /home/runner/work/sof/sof/installer/../installer-builds/staging_sof_tree.txt
# Check two random topologies are there
test -f staging/sof-tplg/sof-apl-nocodec.tplg
test -f staging/sof-tplg/sof-imx8qxp-nocodec.tplg

Since we now changed the name of topologies it can no longer find them. It looks like it expects to find some predefined topology names.

[iuliana-prodan]

@dbaluta Totally agree with this patch, but we need a corresponding one in Linux for the dts, otherwise will have no topology to load.
Later edit: I just saw the dts patch on our internal tree :)

[marc-hb]

This broke the installer test. Please extend this search/replace to the installer/GNUmakefile.
git grep imx8qxp is your friend.

Cc: @ranj063 , @fredoh9 who noticed the breakage.

[marc-hb]

@zrombel can you please check the installer/checktree task:

No need for @zrombel 's magic QuickBuild powers here, this is just a simple github action / very small script. You can copy/paste the commands run by github to reproduce:

make -C installer
make -C installer checktree

EDIT: to remove some platforms check installer/README

[dbaluta]

Hi @marc-hb thanks for pointing this out. Fixed with #4116

[lgirdwood]

This broke the installer test. Please extend this search/replace to the installer/GNUmakefile.
git grep imx8qxp is your friend.

Cc: @ranj063 , @fredoh9 who noticed the breakage.

Sounds like we need this test in CI ?

[dbaluta]

@lgirdwood this is already in CI. It is the Job named checktree. In my comments above I mentioned that it looks to be broken but I didn't know how to fix. So @marc-hb pointed my in the right direction.

[iuliana-prodan]

@lgirdwood since we are talking about CI - where can we find out the tests run by CI?
Like, for example, 14_04_TestDemuxSynchronizedCapture48000Hz24b32b4ch, from PR_REGRESSION.

[lgirdwood]

@dbaluta thanks got you - I must have missed that in the report.
@iuliana-prodan I think we have to ask @kkarask and @wszypelt

[kkarask]

@iuliana-prodan Tests are on internal Intel repo.
Topology from this test:

       pipe_plb
    +-------------------------------+
    | +------+   +------+   +-----+ |                                                 +------+
    | | Host |-->| Buff |-->| Dai |-------------------------------------------------->| SSPx |
    | +------+   +------+   +-----+ |                                                 +------+
    +-------------------------------+                                                    |
                                                                                         |
                                                                                         |
        pipe_cap                                                                         |
    +----------------------------------------------------------------------------+       |
    | +-------+   +------+   +-----+   +------+   +-------+   +------+   +-----+ |    +------+
    | | Host1 |<--| Buff |<--| Vol |<--| Buff |<--| DeMux |<--| Buff |<--| Dai |<-----| SSPx |
    | +-------+   +------+   +-----+   +------+   +-------+   +------+   +-----+ |    +------+
    +-------------------------------------------------|--------------------------+
                                                      |
        pipe_cap                                      |
    +-------------------------------------------+     |
    | +-------+   +------+   +-----+   +------+ |     |
    | | Host2 |<--| Buff |<--| Vol |<--| Buff |<------+
    | +-------+   +------+   +-----+   +------+ |
    +-------------------------------------------+

[iuliana-prodan]

@kkarask This topology is also in Intel's internal repo or is from SOF repo (maybe one from here)?

Thank you!

[wszypelt]

@iuliana-prodan
Sorry, but this topology only exists in Intel's internal repository.

[lgirdwood]

@iuliana-prodan
Sorry, but this topology only exists in Intel's internal repository.

Hmm, I think all topologies used by CI to test features should be upstream otherwise it's difficult for developers to re-test on any failures.
@marc-hb @aiChaoSONG - how many Jenkins topologies are not upstream ?
@zrombel @kkarask @wszypelt - same question for internal CI ?

@wszypelt btw, you should have a SOF project invite in your mailbox (maybe it's in SPAM folder).

[zrombel]

@lgirdwood Python test do not use topologies defined in m4 file. Python tests are focusing on testing specific functionalities of FW and its components, they mimic driver by sending IPCs on its own and create topology dynamically depending on test case scenario. So I don't really se how to upstream those topologies.

[lgirdwood]

@lgirdwood Python test do not use topologies defined in m4 file. Python tests are focusing on testing specific functionalities of FW and its components, they mimic driver by sending IPCs on its own and create topology dynamically depending on test case scenario. So I don't really se how to upstream those topologies.

ok, got you - so this will need someone from python tool to support any queries.