On Fri, 04 Oct 2019 16:35:26 +0200, Kai Vehmanen wrote:
Hey all,
while debugging issues with some Intel platforms related to display audio codec probe (see https://lists.freedesktop.org/archives/intel-gfx/2019-October/214621.html ), I found a discrepancy in behaviour between snd-hda-intel and SOF, despite using the same snd-hda-codec-hdmi as the codec driver.
The specific problem I was debugging appears in a stress test (designed to uncover the above display driver issue) where driver-unload, s3-suspend, resume and driver-reload is done in a loop and repeated for hundreds of iterations. When using SOF, I would get occasional probe fail due to a missing HDA irq. The AZX snd_hda_intel driver nicely survives this test. The explanation seems to be differences in the hdac get_response() implementation.
While the specific issue could be solved with other means, the git history shows a number of rare issues with HDA codecs where polling has helped. It would seem best to align the logic with the AZX driver implementation that has seen much more usage over the years. This will benefit SOF and any other users of the HDAC library.
While it's OK to add the polling support in the core code, I suspect that the main problem gets solved by setting the write_sync flag as the commit 2756d9143aa5. For SOF/SST, you may set the flag unconditionally since they support only the new chipsets.
I've been traveling (still for the next week), so the further reply may be delayed.
thanks,
Takashi