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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux