Re: [PATCH v2 0/9] sound: Use -EPROBE_DEFER instead of i915 module loading.

[Maarten Lankhorst]

Hey,

Den 2023-07-31 kl. 21:32, skrev Takashi Iwai:
> On Mon, 31 Jul 2023 18:37:36 +0200,
> Maarten Lankhorst wrote:
> > Hey,
> >
> > Den 2023-07-31 kl. 17:51, skrev Takashi Iwai:
> > > On Wed, 19 Jul 2023 18:41:32 +0200,
> > > Maarten Lankhorst wrote:
> > > > Explicitly loading i915 becomes a problem when upstreaming the new intel driver
> > > > for Tiger Lake and higher graphics (xe). By loading i915, it doesn't wait for
> > > > driver load of xe, and will fail completely before it loads.
> > > >
> > > > -EPROBE_DEFER has to be returned before any device is created in probe(),
> > > > otherwise the removal of the device will cause EPROBE_DEFER to try again
> > > > in an infinite loop.
> > > >
> > > > The conversion is done in gradual steps. First I add an argument to
> > > > snd_hdac_i915_init to allow for -EPROBE_DEFER so I can convert each driver
> > > > separately. Then I convert each driver to move snd_hdac_i915_init out of the
> > > > workqueue. Finally I drop the ability to choose modprobe behavior after the
> > > > last user is converted.
> > > >
> > > > I suspect the avs and skylake drivers used snd_hdac_i915_init purely for the
> > > > modprobe, but I don't have the hardware to test if it can be safely removed.
> > > > It can still be done easily in a followup patch to simplify probing.
> > > >
> > > > ---
> > > > New since first version:
> > > >
> > > > - snd_hda_core.gpu_bind is added as a mechanism to force gpu binding,
> > > >     for testing. snd_hda_core.gpu_bind=0 forces waiting for GPU bind to
> > > >     off, snd_hda_core.gpu_bind=1 forces waiting for gpu bind. Default
> > > >     setting depends on whether kernel booted with nomodeset.
> > > > - Incorporated all feedback review.
> > > Maarten, are you working on v3 patch set?
> > > Or, for moving forward, should we merge v2 now and fix the rest based
> > > on that later?
> > I've been working on a small change to keep the workqueue in SOF and
> > only move the binding to the probe function to match what
> > snd-hda-intel is doing, but I don't know if that is needed?
> >
> > It was a bit unclear to me based on feedback if I should try to kill
> > the workqueue on all drivers (but with no way to test), or keep it
> > around.
> I guess it's still safer to keep the workqueue in many drivers.  There
> can be modprobe or firmware loading at any later stage.
> We can get rid of the workqueue once after confirming that it's really
> safe, too.
>
> So, if you can work on the patch set in that regard, it's fine, I can
> wait for it.

I've finished that patch, but it caused regressions (oops) while 
rebooting. I think it's safer to kill the workqueue for SOC, and then 
convert all other drivers later.

Cheers,

~Maarten