Messages in this thread | | | Date | Tue, 1 Aug 2023 09:27:47 +0200 | Subject | Re: [PATCH v2 0/9] sound: Use -EPROBE_DEFER instead of i915 module loading. | From | 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
| |