On Wed, 21 Jun 2017 17:23:57 +0200, Chris Wilson wrote: > > 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. Could you give a failing scenario? I'm not opposing to the suggested solution, we need to fix the mess in anyway, but I just would like to know how to trigger the problem easily. thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
