| Message ID | 20230719164141.228073-1-maarten.lankhorst@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | sound: Use -EPROBE_DEFER instead of i915 module loading. | expand |
Hi, On Wed, 19 Jul 2023, 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. thanks, series looks good to me now. We'll need to adopt the new gpu_bind parameter in a number of CI systems (where we test without i915/xe), but this looks perfectly doable. I'll give my Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> ... for the hdac_i915.c changes. For AVS and SOF, I'd ask for some more review time to allow Cezary, Pierre et al to weigh in. I don't personally recall e.g. where we've used CONFIG_SOF_FORCE_PROBE_WORKQUEUE and do we have grounds to keep it even if workqueue is no longer set for HDA codec support. Br, Kai
Hi Maarten, On 19/07/2023 19:41, 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. Apart from the few comments I had, this looks great and works OK on the machines I have tested (iow, no regression so far). Thank you for the work!
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? thanks, Takashi
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. Cheers, ~Maarten
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. thanks, Takashi
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
> 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. My understanding is that we only want to move the binding to the probe function and leave the workqueue removal for another day - possibly never.
On Fri, Aug 04, 2023 at 12:47:54PM +0200, Maarten Lankhorst wrote: > On 2023-08-01 18:32, Pierre-Louis Bossart wrote: > This mail can be applied with git am -c. > ------8<--------- > Now that we can use -EPROBE_DEFER, it's no longer required to spin off Don't do this, it breaks my automation and means I very nearly just skipped the patch entirely since it looked like the middle of some x86 discussion.
Hey, Den 2023-08-04 kl. 13:59, skrev Mark Brown: > On Fri, Aug 04, 2023 at 12:47:54PM +0200, Maarten Lankhorst wrote: >> On 2023-08-01 18:32, Pierre-Louis Bossart wrote: >> This mail can be applied with git am -c. >> ------8<--------- >> Now that we can use -EPROBE_DEFER, it's no longer required to spin off > Don't do this, it breaks my automation and means I very nearly just > skipped the patch entirely since it looked like the middle of some x86 > discussion. Yeah, it's replacing the patch from earlier. I can resend, but means having to add all acks, r-b'd, etc. :) If you have scripts that do that, all the better. Cheers, ~Maarten
On Fri, Aug 04, 2023 at 04:31:21PM +0200, Maarten Lankhorst wrote: > Den 2023-08-04 kl. 13:59, skrev Mark Brown: > > > On 2023-08-01 18:32, Pierre-Louis Bossart wrote: > > > This mail can be applied with git am -c. > > > ------8<--------- > > > Now that we can use -EPROBE_DEFER, it's no longer required to spin off > > Don't do this, it breaks my automation and means I very nearly just > > skipped the patch entirely since it looked like the middle of some x86 > > discussion. > Yeah, it's replacing the patch from earlier. I can resend, but means having > to add all acks, r-b'd, etc. :) *Defintely* do not do that: Please don't send new patches in reply to old patches or serieses, this makes it harder for both people and tools to understand what is going on - it can bury things in mailboxes and make it difficult to keep track of what current patches are, both for the new patches and the old ones. > If you have scripts that do that, all the better. If you're using b4 then b4 trailers --update.