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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
