Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp538685ybi; Thu, 30 May 2019 02:42:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqyL7Akv3EgW1WGK0AuBjgI9HAQQN6g//VXQGxMmoLHySH8474fNbuaghSHsdZZHP+gSyURm X-Received: by 2002:a63:7146:: with SMTP id b6mr3025578pgn.426.1559209346440; Thu, 30 May 2019 02:42:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559209346; cv=none; d=google.com; s=arc-20160816; b=AcgF1tlt4/DUAOStqLHr0dx00SZWd9tMjsnbTLrmtRv4JllaKeJ7psx6O2RrPIQiY+ oyXz9G4qjcE04ggZBKHGbnLB6MpmlOf2nYhcb43XpNH4stcGhDw1CPQYRGYMi3UI6aqg QjYLLNtv1hmf+5MfQs+dAG1Vlqqj5cNqRgv/+Pwtmj5x4F5Y5KM3rLQbdREux87gX639 6A3j87iOQrQKT2Rjv5dkXDBRTeSHKF0CIEtxjF2VS/piupMIipingFfc5yeqBrCK7YhF IHCIFD+vKtAaAE3aSPLGnSZ0Op7CL9hnGbn922/jqLf1aJDcDMNXlJQZYklcSpvov4WV gpKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version; bh=jKQoWU4haOKvJrNL02yl7RD2TohL+nhrreVuJ6Wwcn0=; b=Pl2K/gRmdAXSEWdWZRpD5UXEZkbZI2E+rpqRquMYrOsHm2C8OZZq6kEzF8f9ewRrma q2irs1cuBGuzQnnKb0G7S/QdfG8lTNf+joH+kItndKR5ks2YzQrERndsrDq9kNZHcH6G 4XJgZmw9VsZ4plQJO3pDgb38IVZ+E2z4tkrEB2KSqJ+niv3Pu/yEQpD3PrSXg1ZC4wty EhOXET603XvnbqPGBH8T7zThSLPXN86xZ7v9VnyLYBiiEzfybKHh5RX+K/yBfWRkfJUy EZNy9h9E/eHosYyie3j5NJnWdwDUMAkD95vva6zkvzDTgofKpKqxVBrcopwxS4WT+bPb MLJg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 102si2986799plf.250.2019.05.30.02.42.09; Thu, 30 May 2019 02:42:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727724AbfE3JkX convert rfc822-to-8bit (ORCPT + 99 others); Thu, 30 May 2019 05:40:23 -0400 Received: from mail.fireflyinternet.com ([109.228.58.192]:53813 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727171AbfE3JkX (ORCPT ); Thu, 30 May 2019 05:40:23 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 16731982-1500050 for multiple; Thu, 30 May 2019 10:40:12 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Janusz Krzysztofik , intel-gfx@lists.freedesktop.org From: Chris Wilson In-Reply-To: <20190530092426.23880-2-janusz.krzysztofik@linux.intel.com> Cc: Daniel Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Michal Wajdeczko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Janusz Krzysztofik References: <20190530092426.23880-1-janusz.krzysztofik@linux.intel.com> <20190530092426.23880-2-janusz.krzysztofik@linux.intel.com> Message-ID: <155920920944.2224.169121808439828849@skylake-alporthouse-com> User-Agent: alot/0.6 Subject: Re: [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release() Date: Thu, 30 May 2019 10:40:09 +0100 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Janusz Krzysztofik (2019-05-30 10:24:26) > In order to support driver hot unbind, some cleanup operations, now > performed on PCI driver remove, must be called later, after all device > file descriptors are closed. > > Split out those operations from the tail of pci_driver.remove() > callback and put them into drm_driver.release() which is called as soon > as all references to the driver are put. As a result, those cleanups > will be now run on last drm_dev_put(), either still called from > pci_driver.remove() if all device file descriptors are already closed, > or on last drm_release() file operation. > > Signed-off-by: Janusz Krzysztofik > --- > drivers/gpu/drm/i915/i915_drv.c | 17 +++++++++++++---- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_gem.c | 10 +++++++++- > 3 files changed, 23 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 83d2eb9e74cb..8be69f84eb6d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -738,6 +738,7 @@ static int i915_load_modeset_init(struct drm_device *dev) > > cleanup_gem: > i915_gem_suspend(dev_priv); > + i915_gem_fini_hw(dev_priv); > i915_gem_fini(dev_priv); > cleanup_modeset: > intel_modeset_cleanup(dev); > @@ -1685,7 +1686,6 @@ static void i915_driver_cleanup_hw(struct drm_i915_private *dev_priv) > pci_disable_msi(pdev); > > pm_qos_remove_request(&dev_priv->pm_qos); > - i915_ggtt_cleanup_hw(dev_priv); > } > > /** > @@ -1909,6 +1909,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) Would it make sense to rename load/unload from the legacy drm stubs over to match the pci entry points? > out_cleanup_hw: > i915_driver_cleanup_hw(dev_priv); > + i915_ggtt_cleanup_hw(dev_priv); > out_cleanup_mmio: > i915_driver_cleanup_mmio(dev_priv); > out_runtime_pm_put: > @@ -1960,21 +1961,29 @@ void i915_driver_unload(struct drm_device *dev) > cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work); > i915_reset_error_state(dev_priv); > > - i915_gem_fini(dev_priv); > + i915_gem_fini_hw(dev_priv); > > intel_power_domains_fini_hw(dev_priv); > > i915_driver_cleanup_hw(dev_priv); > - i915_driver_cleanup_mmio(dev_priv); > > enable_rpm_wakeref_asserts(dev_priv); > - intel_runtime_pm_cleanup(dev_priv); > } > > static void i915_driver_release(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = to_i915(dev); > > + disable_rpm_wakeref_asserts(dev_priv); > + > + i915_gem_fini(dev_priv); > + > + i915_ggtt_cleanup_hw(dev_priv); > + i915_driver_cleanup_mmio(dev_priv); > + > + enable_rpm_wakeref_asserts(dev_priv); > + intel_runtime_pm_cleanup(dev_priv); We should really propagate the release nomenclature down and replace our mixed fini/cleanup. Consistency is helpful when trying to work out which phase the code is in. > i915_driver_cleanup_early(dev_priv); > i915_driver_destroy(dev_priv); > } > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index a2664ea1395b..d08e7bd83544 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -3047,6 +3047,7 @@ void i915_gem_init_mmio(struct drm_i915_private *i915); > int __must_check i915_gem_init(struct drm_i915_private *dev_priv); > int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv); > void i915_gem_init_swizzling(struct drm_i915_private *dev_priv); > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv); > void i915_gem_fini(struct drm_i915_private *dev_priv); > int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv, > unsigned int flags, long timeout); > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 7cafd5612f71..c6a8e665a6ba 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4667,7 +4667,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv) > return ret; > } > > -void i915_gem_fini(struct drm_i915_private *dev_priv) > +void i915_gem_fini_hw(struct drm_i915_private *dev_priv) > { > GEM_BUG_ON(dev_priv->gt.awake); > > @@ -4681,6 +4681,14 @@ void i915_gem_fini(struct drm_i915_private *dev_priv) > intel_uc_fini_hw(dev_priv); > intel_uc_fini(dev_priv); > intel_engines_cleanup(dev_priv); intel_engines_cleanup -> i915_gem_fini -- that is in principle just freeing structs. One side effect it does have is to make all engines unavailable (but it doesn't update the engine_mask so the inconsistency might catch us out if it is not one of the last cleanup actions). intel_uc_fini() is a bit of a mixed bag. It looks like it flushes runtime state, so preferrably that flush should be moved to the _fini_hw so that _fini is pure cleanup. So for the time being, best to leave intel_uc_fini() here. > + mutex_unlock(&dev_priv->drm.struct_mutex); > + > + i915_gem_drain_freed_objects(dev_priv); > +} > + > +void i915_gem_fini(struct drm_i915_private *dev_priv) > +{ > + mutex_lock(&dev_priv->drm.struct_mutex); > i915_gem_contexts_fini(dev_priv); > i915_gem_fini_scratch(dev_priv); > mutex_unlock(&dev_priv->drm.struct_mutex); That split looks sensible to me, with the consideration as to whether defer intel_engines_cleanup() as well, Reviewed-by: Chris Wilson -Chris