Skip to content

[FEATURE] move to platform specific HDA tplg files #8683

Closed
Closed
[FEATURE] move to platform specific HDA tplg files#8683
Assignees
ujfalusi
Labels
enhancementNew feature or request
Milestone
v2.9

Description

@kv2019i
kv2019i
opened on Jan 2, 2024

Is your feature request related to a problem? Please describe.
With IPC4, the tplg files can contain platform specific configuration objects (like NHLT blobs). In practise, all Intel tplg files that have DAIs for DMIC or SSP, will have such blobcs. E.g. topology file like "sof-hda-generic-2ch.tplg" is no longer platform agnostic, so for platforms newer than Intel MTL, we need to ship multiple versions of the these topologies, and provide a unique naming so that kernel can look up the correct topology file.

Additionally, we must maintain backward compatibility for platforms already shipping (e.g. for IPC4, this means Intel MTL platforms that are included in SOF2.8 release).

Describe the solution you'd like
Add a platform prefix to all topologies that have platform dependent configuration objects. Keep old naming for platforms like Intel MTL that are already shipping.

Describe alternatives you've considered
Using different directories and duplicating all tplgs. This adds overhead to release process if we need to duplicate all topologies (even when they are in fact the same).

Additional context
Related to SOF2.8 release process lessons learnt, kernel PR thesofproject/linux#4382 and discussion about better system to package the SOF topology files for sof-bin distribution.

Activity

  1. kv2019i
    added
    enhancementNew feature or request
    on Jan 2, 2024
  2. kv2019i
    added this to the v2.9 milestone on Jan 2, 2024

  3. ujfalusi commented on Jan 3, 2024

    @ujfalusi
    ujfalusi
    on Jan 3, 2024
    Contributor

    @kv2019i, my proposal for the IPC4 tplg paths, which will scale well for the future and past (I will make a sof-docs update with this):
    The collision is really about the generic HDA topologies with DMIC (and some development ones using generic names). We could just try to separate these per architecture/platform but I feel that creating a clear rule for that is not going to be easy. We would need to define the 'generic', have different path lookup for them, etc.
    I would rather go via a simple and unimaginative approach and store all tplg files in separate directories. This would give us backwards compatibility with older kernels.

    Option A

    .
└── intel
    ├── sof-ace-tplg -> sof-ipc4-tplg/ace1
    └── sof-ipc4-tplg
        ├── ace1
        │   ├── sof-hda-generic-2ch.tplg
        │   ├── sof-hda-generic-4ch.tplg
        │   ├── sof-hda-generic-idisp.tplg
        │   ├── sof-hda-generic.tplg
        │   ├── sof-lnl-rt711-4ch.tplg
        │   ├── sof-lnl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-cs42l43-l0-cs35l56-l12.tplg
        │   ├── sof-mtl-es83x6-ssp1-hdmi-ssp02.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0-2ch-pdm1.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg
        │   ├── sof-mtl-max98357a-rt5682.tplg
        │   ├── sof-mtl-rt1019-rt5682.tplg
        │   ├── sof-mtl-rt1318-l12-rt714-l0.tplg
        │   ├── sof-mtl-rt5650-dts.tplg
        │   ├── sof-mtl-rt711-4ch.tplg
        │   ├── sof-mtl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-rt712-l0-rt1712-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12.tplg
        │   ├── sof-mtl-rt722-l0.tplg
        │   └── sof-mtl-sdw-cs42l42-l0-max98363-l2.tplg
        └── cavs2.5
            ├── sof-adl-rt711-4ch.tplg
            ├── sof-adl-rt711-l0-rt1316-l12-rt714-l3.tplg
            ├── sof-hda-generic-2ch.tplg
            ├── sof-hda-generic-4ch.tplg
            ├── sof-hda-generic-idisp.tplg
            ├── sof-hda-generic.tplg
            ├── sof-tgl-cs42l43-l3-cs35l56-l01.tplg
            ├── sof-tgl-rt711-rt1308-4ch.tplg
            ├── sof-tgl-rt711-rt1308-rt715.tplg
            ├── sof-tgl-rt711-rt1316-rt714.tplg
            ├── sof-tgl-rt712.tplg
            └── sof-tgl-rt715-rt711-rt1308-mono.tplg

    Option B

    .
└── intel
    ├── sof-ace-tplg -> sof-ipc4-tplg/ace1
    └── sof-ipc4-tplg
        ├── ace1
        │   ├── sof-hda-generic-2ch.tplg
        │   ├── sof-hda-generic-4ch.tplg
        │   ├── sof-hda-generic-idisp.tplg
        │   ├── sof-hda-generic.tplg
        │   ├── sof-lnl-rt711-4ch.tplg
        │   ├── sof-lnl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-cs42l43-l0-cs35l56-l12.tplg
        │   ├── sof-mtl-es83x6-ssp1-hdmi-ssp02.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0-2ch-pdm1.tplg
        │   ├── sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg
        │   ├── sof-mtl-max98357a-rt5682.tplg
        │   ├── sof-mtl-rt1019-rt5682.tplg
        │   ├── sof-mtl-rt1318-l12-rt714-l0.tplg
        │   ├── sof-mtl-rt5650-dts.tplg
        │   ├── sof-mtl-rt711-4ch.tplg
        │   ├── sof-mtl-rt711-l0-rt1316-l23-rt714-l1.tplg
        │   ├── sof-mtl-rt712-l0-rt1712-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg
        │   ├── sof-mtl-rt713-l0-rt1316-l12.tplg
        │   ├── sof-mtl-rt722-l0.tplg
        │   └── sof-mtl-sdw-cs42l42-l0-max98363-l2.tplg
        ├── ace2 -> ace1
        ├── adl -> cavs2.5
        ├── adl-n -> cavs2.5
        ├── adl-s -> cavs2.5
        ├── arl -> ace1
        ├── arl-s -> ace1
        ├── cavs2.5
        │   ├── sof-adl-rt711-4ch.tplg
        │   ├── sof-adl-rt711-l0-rt1316-l12-rt714-l3.tplg
        │   ├── sof-hda-generic-2ch.tplg
        │   ├── sof-hda-generic-4ch.tplg
        │   ├── sof-hda-generic-idisp.tplg
        │   ├── sof-hda-generic.tplg
        │   ├── sof-tgl-cs42l43-l3-cs35l56-l01.tplg
        │   ├── sof-tgl-rt711-rt1308-4ch.tplg
        │   ├── sof-tgl-rt711-rt1308-rt715.tplg
        │   ├── sof-tgl-rt711-rt1316-rt714.tplg
        │   ├── sof-tgl-rt712.tplg
        │   └── sof-tgl-rt715-rt711-rt1308-mono.tplg
        ├── ehl -> cavs2.5
        ├── lnl -> ace2
        ├── mtl -> ace1
        ├── rpl -> cavs2.5
        ├── rpl-s -> cavs2.5
        ├── tgl -> cavs2.5
        └── tgl-h -> cavs2.5

    Option A: separate directories for generations that needs different binary blobs, sof-ace-tplg symlinked to sof-ipc4-tplg/ace1.
    The rule is generation dependent:
    Tiger Lake | IPC4 | /lib/firmware/intel/sof-ipc4-tplg/cavs2.5/sof-CONFIG.tplg
    Meteor Lake and Lunar Lake | IPC4 | /lib/firmware/intel/sof-ipc4-tplg/ace1/sof-CONFIG.tplg

    Option B: adds symlinks to the generation directories as platform names, the rule is rather simple and can be automated easily:
    Tiger Lake and newer | IPC4 | /lib/firmware/intel/sof-ipc4-tplg/PLAT/sof-CONFIG.tplg

    It depends how we want to go about this, if we want to have the ability to support different firmware file layouts per IPC types [1] then Option B is the one that we should aim for.
    Note: CAVS2.5 support is not released as of now, we can re-define the paths still to make our life easier. It will only cause some headache for developers.

    [1] thesofproject/linux#4603, I have this reworked heavily rolling it in my wip branch.

  4. ujfalusi commented on Jan 3, 2024

    @ujfalusi
    ujfalusi
    on Jan 3, 2024
    Contributor

    Proposal for the IPC4 topology default paths: thesofproject/sof-docs#482

  5. kv2019i commented on Jan 3, 2024

    @kv2019i
    kv2019i
    on Jan 3, 2024
    CollaboratorAuthor

    Not choosing my preferred option yet, but for completeness, we have also

    Option C

    .
└── intel
    ├── sof-ace-tplg -> sof-ipc4-tplg
    └── sof-ipc4-tplg
       ├── sof-hda-generic-2ch.tplg -> sof-mtl-hda-generic-2ch.tplg
       ├── sof-hda-generic-4ch.tplg -> sof-mtl-hda-generic-4ch.tplg
       ├── sof-hda-generic.tplg -> sof-mtl-hda-generic.tplg
       ├── sof-hda-generic-idisp.tplg -> sof-mtl-hda-generic-idisp.tplg
       ├── sof-mtl-hda-generic-4ch.tplg
       ├── sof-mtl-hda-generic-2ch.tplg
       ├── sof-mtl-hda-generic.tplg
       ├── sof-mtl-hda-generic-idisp.tplg
       ├── sof-lnl-rt711-4ch.tplg
       ├── sof-lnl-rt711-l0-rt1316-l23-rt
...

  6. kv2019i commented on Jan 3, 2024

    @kv2019i
    kv2019i
    on Jan 3, 2024
    CollaboratorAuthor

    For option C, we could take advantage of the fact that the HW specific portions of the (otherwise generic) tplg files only come into play if we override the ACPI NHLT data. So for newer platforms (!= MTL), we could modify the kernel logic to look up "snd-PLAT-hda-generic[-ext].tplg" in case tplg NHLT override is used (kernel will know about this).

    This would be easier to implement in context of current SOF tplg2 build rules.

  7. ujfalusi commented on Jan 3, 2024

    @ujfalusi
    ujfalusi
    on Jan 3, 2024
    Contributor

    Not choosing my preferred option yet, but for completeness, we have also

    Option C

    .
└── intel
    ├── sof-ace-tplg -> sof-ipc4-tplg
    └── sof-ipc4-tplg
       ├── sof-hda-generic-2ch.tplg -> sof-mtl-hda-generic-2ch.tplg
       ├── sof-hda-generic-4ch.tplg -> sof-mtl-hda-generic-4ch.tplg
       ├── sof-hda-generic.tplg -> sof-mtl-hda-generic.tplg
       ├── sof-hda-generic-idisp.tplg -> sof-mtl-hda-generic-idisp.tplg
       ├── sof-mtl-hda-generic-4ch.tplg
       ├── sof-mtl-hda-generic-2ch.tplg
       ├── sof-mtl-hda-generic.tplg
       ├── sof-mtl-hda-generic-idisp.tplg
       ├── sof-lnl-rt711-4ch.tplg
       ├── sof-lnl-rt711-l0-rt1316-l23-rt
...

    Which would not work on CAVS2.5 platforms..

  8. ujfalusi commented on Jan 3, 2024

    @ujfalusi
    ujfalusi
    on Jan 3, 2024
    Contributor

    @kv2019i, @plbossart, we have one default_tplg_path per IPC version via struct sof_dev_desc and I pretty much want to avoid magically crafted ones - which is not even possible to pass since the desc is marked as static.

    I guess we could try to generate the generic topology file name to include the platform, but then for lnl we should have it generate the sof-mtl-hda-generic* name, is that really make sense?

  9. kv2019i commented on Jan 3, 2024

    @kv2019i
    kv2019i
    on Jan 3, 2024
    CollaboratorAuthor

    I think for cAVS2.5 and LNL we could have kernel generate sof-tgl-hda-generic and sof-lnl-hda-generic (and so forth) as we have not shipped (IPC4) binaries for those platforms yet. But ack, not ideal either.

  10. mengdonglin commented on Jan 3, 2024

    @mengdonglin
    mengdonglin
    on Jan 3, 2024
    Collaborator

    Not choosing my preferred option yet, but for completeness, we have also
    Option C
    ...
    Which would not work on CAVS2.5 platforms.
    @ujfalusi I think we can keep using avs-tplg for CAVS2.5 platforms as they're not for production till now :)

  11. plbossart commented on Jan 3, 2024

    @plbossart
    plbossart
    on Jan 3, 2024
    Member

    For option C, we could take advantage of the fact that the HW specific portions of the (otherwise generic) tplg files only come into play if we override the ACPI NHLT data. So for newer platforms (!= MTL), we could modify the kernel logic to look up "snd-PLAT-hda-generic[-ext].tplg" in case tplg NHLT override is used (kernel will know about this).

    This would be easier to implement in context of current SOF tplg2 build rules.

    This topology override is creating a mess we don't really need for 'generic' platforms such as HDAudio+DMIC.

    Having to deal with multiple topology files because the ACPI/NHLT blobs MIGHT not be correct and the user MIGHT select topology-based information is rather nuts. There are mechanisms to override NHLT now if it's really invalid.

    I really wonder what benefits we reap with the release in sof-bin of topology-based blobs...

  12. ujfalusi commented on Jan 4, 2024

    @ujfalusi
    ujfalusi
    on Jan 4, 2024
    Contributor

    For option C, we could take advantage of the fact that the HW specific portions of the (otherwise generic) tplg files only come into play if we override the ACPI NHLT data. So for newer platforms (!= MTL), we could modify the kernel logic to look up "snd-PLAT-hda-generic[-ext].tplg" in case tplg NHLT override is used (kernel will know about this).
    This would be easier to implement in context of current SOF tplg2 build rules.

    This topology override is creating a mess we don't really need for 'generic' platforms such as HDAudio+DMIC.

    Having to deal with multiple topology files because the ACPI/NHLT blobs MIGHT not be correct and the user MIGHT select topology-based information is rather nuts. There are mechanisms to override NHLT now if it's really invalid.

    I really wonder what benefits we reap with the release in sof-bin of topology-based blobs...

    @plbossart, what about the platforms w/o ACPI/NHLT blob in ROM?

  13. ujfalusi commented on Jan 4, 2024

    @ujfalusi
    ujfalusi
    on Jan 4, 2024
    Contributor

    @ujfalusi I think we can keep using avs-tplg for CAVS2.5 platforms as they're not for production till now :)

    @mengdonglin, imho we need to define a layout which will work for the future and that should include not (yet) supported architectures, like CAVS2.5.
    The avs-tplg is wrong, these topologies work with SOF, not with reference firmware.

  14. ujfalusi commented on Jan 4, 2024

    @ujfalusi
    ujfalusi
    on Jan 4, 2024
    Contributor

    @kv2019i, @plbossart, @marc-hb, regarding to Option C..

    For that we would likely need to merge the two separate tplg builds under one target [1]
    Then if we have this, we need to symlink each platform to it's architecture specific hda-generic-2/4ch:

    sof-hda-generic.tplg # for _all_ platforms!!!!!
sof-hda-generic-idisp.tplg # for _all_ platforms!!!!!
sof-cavs25-hda-generic-2ch.tplg
sof-cavs25-hda-generic-4ch.tplg
sof-ace1-hda-generic-2ch.tplg
sof-ace1-hda-generic-4ch.tplg
...
sof-tgl-hda-generic-2ch.tplg -> sof-cavs25-hda-generic-2ch.tplg
sof-tgl-hda-generic-4ch.tplg -> sof-cavs25-hda-generic-4ch.tplg
...
sof-adl-hda-generic-2ch.tplg -> sof-cavs25-hda-generic-2ch.tplg
sof-adl-hda-generic-4ch.tplg -> sof-cavs25-hda-generic-4ch.tplg
...
sof-mtl-hda-generic-2ch.tplg -> sof-ace1-hda-generic-2ch.tplg
sof-mtl-hda-generic-4ch.tplg -> sof-ace1-hda-generic-4ch.tplg
...
sof-lnl-hda-generic-2ch.tplg -> sof-ace1-hda-generic-2ch.tplg
sof-lnl-hda-generic-4ch.tplg -> sof-ace1-hda-generic-4ch.tplg

    Which is going to be fun to document, sof-bin-ize, and handle in kernel... It is doable, but really we want to go here?

    [1] 0001-topology2-Merge-things-as-sof-ipc4-tplg.patch.txt

  15. plbossart commented on Jan 4, 2024

    @plbossart
    plbossart
    on Jan 4, 2024
    Member

    @plbossart, what about the platforms w/o ACPI/NHLT blob in ROM?

    These platforms are non-Windows and essentially Chrome only - there is already an overlay mechanism managed by Google.

    The exception to the rule might be the UpExtreme or RVPs tweaked to deal with different IOs, but those are test platforms that can deal with Intel-specific handling.

    The point is that I don't think anyone will ever use the blobs from topology on platforms designed for Windows.

  16. kv2019i commented on Jan 4, 2024

    @kv2019i
    kv2019i
    on Jan 4, 2024
    CollaboratorAuthor

    @plbossart @ujfalusi So what if we remove the NHLT blobs from "sof-hda-generic*" , merge the two source directories and add new rules for platform specific HDA tplgs (if needed at all, we can start without).

    Only problem is whether this will cause regression as we've shipped sof-hda-generic-xch.tplg in SOF2.7 and SOF2.8. This has not been the default and we know of no users (e.g. via bugs), but this is anyway a concern to address.

  17. ujfalusi commented on Jan 4, 2024

    @ujfalusi
    ujfalusi
    on Jan 4, 2024
    Contributor

    @kv2019i, if we don't have NHLT blob in the "sof-hda-generic*" then there is no need for platforms specific ones. The only reason we need platform specific ones is because of the NHLT blob in the tplg, well specifically of the DMIC blobs in the NHLT in the tplg.

    The sof-hda-generic-xch.tplg variant is still needed afaik in case the machine have dmic, no? We just not include NHLT into them.

  18. plbossart commented on Jan 4, 2024

    @plbossart
    plbossart
    on Jan 4, 2024
    Member

    I think @ujfalusi is right, the topology has reference to 2 or 4 channels for the PCM capabilities, no matter if we have blobs or not.

    Edit: and the 0ch matters are well, we remove the PCM path entirely IIRC

  19. ujfalusi commented on Jan 4, 2024

    @ujfalusi
    ujfalusi
    on Jan 4, 2024
    Contributor

    another tree across the tracks...
    The ACE1 topology includes DEEPBUFFER_D0I3_COMPATIBLE=true for the hda-generic ones while the CAVS flavor does not, so we need separate generic ones because of this?

  20. plbossart commented on Jan 4, 2024

    @plbossart
    plbossart
    on Jan 4, 2024
    Member

    another tree across the tracks... The ACE1 topology includes DEEPBUFFER_D0I3_COMPATIBLE=true for the hda-generic ones while the CAVS flavor does not, so we need separate generic ones because of this?

    I don't recall if this is intentional or just us being sloppy or cautious/not wanting to introduce a new feature on older platform. @ranj063 might remember?

  21. ujfalusi commented on Jan 5, 2024

    @ujfalusi
    ujfalusi
    on Jan 5, 2024
    Contributor

    @plbossart, @ranj063, at least it works fine (DEEPBUFFER_D0I3_COMPATIBLE=true) on TGL...

    [ 2576.962675] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx      : 0x48000000|0x12: MOD_SET_D0IX
[ 2576.962955] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx reply: 0x68000000|0x12: MOD_SET_D0IX
[ 2576.962974] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx done : 0x48000000|0x12: MOD_SET_D0IX
[ 2576.962980] snd_sof_intel_hda_common:hda_dsp_state_log: sof-audio-pci-intel-tgl 0000:00:1f.3: Current DSP power state: D0I3

  22. ujfalusi commented on Jan 5, 2024

    @ujfalusi
    ujfalusi
    on Jan 5, 2024
    Contributor

    To be able to have generic hda we need this PR: #8700
    and with that we can provide nice sof-ipc4-tplg directory to be used by all architectures:

    ls -al tools/build_tools/topology/topology2/sof-ipc4-tplg/ | grep tplg
-rw-r--r-- 1 user user 53471 Jan  5 10:51 sof-ace1-nhlt-hda-generic-2ch.tplg
-rw-r--r-- 1 user user 53471 Jan  5 10:51 sof-ace1-nhlt-hda-generic-4ch.tplg
-rw-r--r-- 1 user user 52835 Jan  5 10:51 sof-adl-rt711-4ch.tplg
-rw-r--r-- 1 user user 53006 Jan  5 10:51 sof-adl-rt711-l0-rt1316-l12-rt714-l3.tplg
-rw-r--r-- 1 user user 53471 Jan  5 10:51 sof-cavs25-nhlt-hda-generic-2ch.tplg
-rw-r--r-- 1 user user 53471 Jan  5 10:51 sof-cavs25-nhlt-hda-generic-4ch.tplg
-rw-r--r-- 1 user user 47250 Jan  5 10:51 sof-hda-generic-2ch.tplg
-rw-r--r-- 1 user user 47250 Jan  5 10:51 sof-hda-generic-4ch.tplg
-rw-r--r-- 1 user user 18046 Jan  5 10:51 sof-hda-generic-idisp.tplg
-rw-r--r-- 1 user user 34266 Jan  5 10:51 sof-hda-generic.tplg
-rw-r--r-- 1 user user 37787 Jan  5 10:51 sof-lnl-rt711-4ch.tplg
-rw-r--r-- 1 user user 37958 Jan  5 10:51 sof-lnl-rt711-l0-rt1316-l23-rt714-l1.tplg
-rw-r--r-- 1 user user 38142 Jan  5 10:51 sof-mtl-cs42l43-l0-cs35l56-l12.tplg
-rw-r--r-- 1 user user 36713 Jan  5 10:51 sof-mtl-es83x6-ssp1-hdmi-ssp02.tplg
-rw-r--r-- 1 user user 82587 Jan  5 10:51 sof-mtl-max98357a-rt5682-ssp2-ssp0-2ch-pdm1.tplg
-rw-r--r-- 1 user user 82587 Jan  5 10:51 sof-mtl-max98357a-rt5682-ssp2-ssp0.tplg
-rw-r--r-- 1 user user 78871 Jan  5 10:51 sof-mtl-max98357a-rt5682.tplg
-rw-r--r-- 1 user user 58315 Jan  5 10:51 sof-mtl-rt1019-rt5682.tplg
-rw-r--r-- 1 user user 34686 Jan  5 10:51 sof-mtl-rt1318-l12-rt714-l0.tplg
-rw-r--r-- 1 user user 86251 Jan  5 10:51 sof-mtl-rt5650-dts.tplg
-rw-r--r-- 1 user user 37787 Jan  5 10:51 sof-mtl-rt711-4ch.tplg
-rw-r--r-- 1 user user 37958 Jan  5 10:51 sof-mtl-rt711-l0-rt1316-l23-rt714-l1.tplg
-rw-r--r-- 1 user user 31214 Jan  5 10:51 sof-mtl-rt712-l0-rt1712-l3.tplg
-rw-r--r-- 1 user user 53006 Jan  5 10:51 sof-mtl-rt713-l0-rt1316-l12-rt1713-l3.tplg
-rw-r--r-- 1 user user 48178 Jan  5 10:51 sof-mtl-rt713-l0-rt1316-l12.tplg
-rw-r--r-- 1 user user 31214 Jan  5 10:51 sof-mtl-rt722-l0.tplg
-rw-r--r-- 1 user user 70599 Jan  5 10:51 sof-mtl-sdw-cs42l42-l0-max98363-l2.tplg
-rw-r--r-- 1 user user 38142 Jan  5 10:51 sof-tgl-cs42l43-l3-cs35l56-l01.tplg
-rw-r--r-- 1 user user 60639 Jan  5 10:51 sof-tgl-rt711-rt1308-4ch.tplg
-rw-r--r-- 1 user user 47650 Jan  5 10:51 sof-tgl-rt711-rt1308-rt715.tplg
-rw-r--r-- 1 user user 53016 Jan  5 10:51 sof-tgl-rt711-rt1316-rt714.tplg
-rw-r--r-- 1 user user 46314 Jan  5 10:51 sof-tgl-rt712.tplg
-rw-r--r-- 1 user user 46272 Jan  5 10:51 sof-tgl-rt715-rt711-rt1308-mono.tplg

    Note: we would provide the two type of generic HDA with the blobs included as cavs25-nhlt and ace1-nhlt files just in case.

  23. kv2019i
    assigned
    ujfalusi
    on Jan 23, 2024

  24. ujfalusi commented on Jan 23, 2024

    @ujfalusi
    ujfalusi
    on Jan 23, 2024
    Contributor

    @kv2019i, I think this is done, or done in a different way by - creating different files per DSP arch:

    $ tree tools/build_tools/topology/topology2/target/sof-ipc4-tplg | grep generic
├── sof-hda-generic-2ch.tplg
├── sof-hda-generic-4ch.tplg
├── sof-hda-generic-ace1-2ch.tplg
├── sof-hda-generic-ace1-4ch.tplg
├── sof-hda-generic-cavs25-2ch.tplg
├── sof-hda-generic-cavs25-4ch.tplg
├── sof-hda-generic-idisp.tplg
├── sof-hda-generic.tplg

  25. kv2019i commented on Jan 24, 2024

    @kv2019i
    kv2019i
    on Jan 24, 2024
    CollaboratorAuthor

    @ujfalusi Indeed, the original problem is now addressed, so we can close this. Thank you!

  26. kv2019i
    closed this as completedon Jan 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions