On Tue, Dec 01, 2020 at 10:38:57PM +0000, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-12-01 16:05:17) > > On Fri, Nov 27, 2020 at 10:05:48PM +0000, Chris Wilson wrote: > > > Switch off the scanout during driver unregister, so we can shutdown the > > > HW immediately for unbind. > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > --- > > > drivers/gpu/drm/i915/i915_drv.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > > > index 320856b665a1..62d188e5cb8d 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > @@ -738,6 +738,7 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) > > > * events. > > > */ > > > drm_kms_helper_poll_fini(&dev_priv->drm); > > > + drm_atomic_helper_shutdown(&dev_priv->drm); > > > > Looks like we already have this in remove(). Is that too late? > > For the operations we do during unbind, yes. > > For the core_hotplug/rebind dance, we have to reset the GPU while we > still have runtime-pm operational and have pushed the reset to > unregister (from experimentation that's as late as we can put it where > the GPU works after rebinding and we don't corrupt the system on unbind, > with the current hooks). You can guess how well gen3 likes that. > > But I don't think the right answer is to skip the reset for gen3. > Suppose we enable context support for gen3, then the reset would be > required as well, and so we would still need the whole display > shenanigans to turn it off. Moving the modeset to turn the display off > to the end of userspace seems reasonable. Yeah, just a bit odd to have the same call twice in the sequence. Can we remove the second call at least? Also a bit annoying the unload sequence no longer matches the suspend sequence. Well, I guess it was never 100% anyway but I think it was a bit closer before this patch. But the whole thing is rather messy anyway so I guess t's not significantly worse after this. Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
