Skip to content

Driver support for firmware recovery #452

Closed

Description

@plbossart

When the firmware gets stuck or unresponsive (IPC timeouts), the driver just bails out and the only way to recover is to reboot. That's not acceptable for a number of products.

The SOF driver needs to implement a recovery mechanism where it detects the firmware has gone off tracks (e.g. with a 5s watchdog), and restores the configuration (hardware reset, firmware download, pipelines and controls restored). We already have this sequence for resume so it shouldn't be too hard.

Note that this request is not asking for seamless operation. Applications will likely time out and likely stop, so collaboration with userspace is likely required to reenable playback/capture. The ask is really to avoid a reboot and restart cleanly.

Activity

  1. wenqingfu commented on Dec 17, 2018

    @wenqingfu

    extended work of thesofproject/sof#710?

  2. plbossart commented on Dec 17, 2018

    @plbossart
    MemberAuthor
  3. ranj063 commented on Dec 21, 2018

    @ranj063
    Collaborator

    @plbossart looking into the hda_dsp_core_reset_power_down() method in hds-dsp.c, we seem to be placing the core in reset before powering down and when the firmware is unresponsive, this also seems to fail. This is required when we want to shutdown gracefully.

    In the case of panic, would it be acceptable to just power down the cores instead of placing them in reset?

  4. plbossart commented on Dec 21, 2018

    @plbossart
    MemberAuthor
  5. xiulipan commented on Feb 10, 2019

    @xiulipan

    @plbossart @ranj063
    Actually now when a panic happened. If runtime_pm is not disabled, it will automatically recovery the DSP by runtime_suspend and runtime_resume.

    This now brings some difficulty in debug as all the logs and dumped exception info is gone with that suspend/resume.

    As for the recovery mode, I think we may need to add flag or debugfs controller to disable the FW recovery for DEBUG usage.

  6. plbossart commented on Feb 11, 2019

    @plbossart
    MemberAuthor
  7. wenqingfu commented on Apr 1, 2019

    @wenqingfu

    @kv2019i , would you be able to take this one? thanks!

  8. kv2019i commented on Apr 2, 2019

    @kv2019i
    Collaborator

    @wenqingfu wrote:

    @kv2019i , would you be able to take this one? thanks!

    Ack. I'm currently looking at tracing issues during suspend and runtime supsned (old issue #248
    and newer #486), will work on these first (good way to learn the tracing part first) and then move to this.

  9. kv2019i commented on Apr 17, 2019

    @kv2019i
    Collaborator

    Hello, I now pushed initial patchset to address this issue (PR841). I ended up taking a slightly different path than what you've discussed earlier, so please check the code and see whether this is on the right track or not.

  10. added
    NotableEnhancement is significant or notable for release.
    on Jun 21, 2019
  11. kv2019i commented on May 19, 2021

    @kv2019i
    Collaborator

    @ujfalusi got #1675 so passing this as well :)

  12. removed their assignment
    on May 19, 2021
  13. added a commit that references this issue on Aug 26, 2021
  14. plbossart commented on Aug 12, 2024

    @plbossart
    MemberAuthor

    duplicate of #1675

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

Metadata

Metadata

Assignees

Labels

NotableEnhancement is significant or notable for release.enhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions