Quoting Daniel Vetter (2017-06-21 16:08:54) > So back when the i915 power well support landed in > > commit 99a2008d0b32d72dfc2a54e7be1eb698dd2e3bd6 > Author: Wang Xingchao <xingchao.wang@xxxxxxxxxxxxxxx> > Date: Thu May 30 22:07:10 2013 +0800 > > ALSA: hda - Add power-welll support for haswell HDA > > the logic to handle the cross-module depencies was hand-rolled using a > async work item, and that just doesn't work. > > The correct way to handle cross-module deps is either: > - request_module + failing when the other module isn't there > > OR > > - failing the module load with EPROBE_DEFER. > > You can't mix them, if you do then the entire load path just > busy-spins blowing through cpu cycles forever with no way to stop > this. > > snd-hda-intel does mix it, because the hda codec drivers are loaded > using request_module, but the i915 depency is handled using > PROBE_DEFER (or well, should be, but I haven't found any code at all). > This is a major pain when trying to debug i915 load failures. > > This patch here is a horrible hackish attempt at somewhat correctly > wriing EPROBE_DEFER through. Stuff that's missing: > - Check all the other places where load errors are conveniently > dropped on the floor. > - Also fix up the firmware_cb path. > - Drop the debug noise I've left in to make it clear this isn't > anything for merging. This tames "hdaudio hdaudioC0D0: Unable to bind the codec" which was continuously spewing previously, and now the system is usable again. Thanks, -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
