Skip to content

DMIC Capture failure on HDA with cavs2.5 #9587

Closed

Description

@ranj063

All capture usecases are failing with the following error

[  273.932645] kernel: snd_sof:snd_sof_get_nhlt_endpoint_data: sof-audio-pci-intel-tgl 0000:00:1f.3: dai index 0 nhlt type 2 direction 1 dev type 0
[  273.932650] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: no matching blob for sample rate: 48000 sample width: 16 channels: 4
[  273.932704] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: failed to prepare widget dai-copier.DMIC.dmic01.capture
[  273.932740] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Failed to prepare connected widgets
[  273.932770] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed widget list set up for pcm 6 dir 1
[  273.932803] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_pcm_component_hw_params on 0000:00:1f.3: -22

Zephyr Daily test plan "daily_test_new"[*]: 46733, 46770

[*] string can be used as a filter in the URL

Activity

  1. added
    HDAApplies to HD-Audio bus for codec connection
    P1Blocker bugs or important features
    on Oct 16, 2024
  2. changed the title [-]Capture failure on HDA with cavs2.5[/-] [+]DMIC Capture failure on HDA with cavs2.5[/+] on Oct 16, 2024
  3. added
    bugSomething isn't working as expected
    on Oct 16, 2024
  4. self-assigned this
    on Oct 16, 2024
  5. ranj063 commented on Oct 16, 2024

    @ranj063
    CollaboratorAuthor

    I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

  6. marc-hb commented on Oct 16, 2024

    @marc-hb
    Collaborator

    Looking at result/planresult?planname=%5Edaily_test_new,

    • Last successful daily run was 46534

    Start Time: 2024-10-04 13:21:25 UT
    Linux Commit: 62f484728981
    KConfig Commit: 8189104a4f38
    SOF Commit: 9cdef9fc13bb
    Zephyr Commit: 155f3f3ba688

    • First failing daily run 46595

    Start Time: 2024-10-10 13:11:05 UTC
    Linux Commit: 7eab5d86f218
    KConfig Commit: 8189104a4f38
    SOF Commit: d2cf7c3cc859
    Zephyr Commit: 155f3f3ba688

    There's a very clear and dramatic drop in the PASS rate between these two consecutive runs. There's a big date gap between the two because of a planned power outage in Oregon during that week-end.

    (It's less clear but I suspect the PASS rate of result/planresult?planname=%5Edaily_lnl dropped at around the same time...? Harder to tell because unlike the other it's always been somewhat red so, as expected everyone stopped paying attention.)

  7. lgirdwood commented on Oct 17, 2024

    @lgirdwood
    Member

    I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

    @ranj063 So does this mean kernel cant find blob or the 32bit blob is missing form the topology(i.e. topology has 16bit blob only) ?

  8. ranj063 commented on Oct 17, 2024

    @ranj063
    CollaboratorAuthor

    I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

    @ranj063 So does this mean kernel cant find blob or the 32bit blob is missing form the topology(i.e. topology has 16bit blob only) ?

    @lgirdwood it looks like the 32-bit blob is missing from the topology. Im verifying it this morning

  9. ranj063 commented on Oct 17, 2024

    @ranj063
    CollaboratorAuthor

    the reason for the fialure was that the incorrect topology was being used on the device. For cavs2.5 platforms, when forcing the use of topology NHLT, we should copy sof-hda-generic-cavs25-4ch.tplg into sof-hda-generic-4ch.tplg before running the CI tests. But if the NHLT is included in the BIOS, that should be preferred over the topology NHLT.

  10. marc-hb commented on Oct 18, 2024

    @marc-hb
    Collaborator

    46891 passed, no idea why.

    (It's less clear but I suspect the PASS rate of result/planresult?planname=%5Edaily_lnl dropped at around the same time...? Harder to tell because unlike the other it's always been somewhat red so, as expected everyone stopped paying attention.)

    This recent, probably unrelated LNL regression and crash seems to be focused on multiple-pipeline tests. Has anyone filed a bug yet?

    Here's a non-daily, public example: https://sof-ci.01.org/softestpr/PR1236/build782/devicetest/index.html

  11. marc-hb commented on Oct 22, 2024

    @marc-hb
    Collaborator

    This recent, probably unrelated LNL regression and crash seems to be focused on multiple-pipeline tests. Has anyone filed a bug yet?

    Thanks @kv2019i

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

HDAApplies to HD-Audio bus for codec connectionP1Blocker bugs or important featuresbugSomething isn't working as expected

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions