Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3825767ybi; Mon, 3 Jun 2019 00:31:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqw2bnOHsb5qDBYVCcQOL36jApFc1uwDwSggDkHjuQ6FGx23+lnkjfppE3SjRRZD+0bM66yk X-Received: by 2002:aa7:8dd6:: with SMTP id j22mr30173492pfr.192.1559547092067; Mon, 03 Jun 2019 00:31:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559547092; cv=none; d=google.com; s=arc-20160816; b=IjfHVtoZUeGDELwFatI3SAYRVzGZyK5v+yYivNoP4C5DZfTRO2gP4LjiwtKjnFaAap gbI0fgDhCDkxFjiL/VRizsSCier6PZ1SSt5+3QxaLD5xVkaPKDrz/drB0LCXRAbluIjN 4KZUIPvEXVS5MQhmXOf5tP6+fgCvGYBM8qWIN7/ggwEkZzsDcxGclfBpNdNMpgM1+9Mg T/uPxBz1AxFfPdaBhHEPYwI6qxOngPGpwom3vF1aG9c9E4T/6Nq7wNLOBS4u8862/Fvz 2CtYw1T8ImqyQdfpJ+rboGraT4+HcQMI2OKBqC9Dbou1kLllLP8cSSyPgPohYYxP94bG FdTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=OBEcUSBuSXIEvv5YvVgrfg8sH2Ivurz6vfRZ/RbnW8s=; b=o0uqBPV8MNL2e2cdaYzXNkoveGeXYGKO1+jegJqIWTjuJ+i9djILLZyeUrW+xx+EFU /bYDBj+TtWMa4IAbIoP9ZJDDgKcIbBeA0rGXYwM4P+bwa6mLkhMx+j6nX4eqncwYhDR9 AlNIWQ4CxfRLGcs02P67rRAf0dd4dTnsHtkjPDo9XTUb2K3Zhr7f+r7WFHchqTGAvuPh pfjePXDPV4B23TnnNO0rJKpsXifGQUdBQm7NCWu1leDU47t+NW8xMHkDFbMXIh5x45Bh 0R/lu2zFGOndUjqVv/KK1qP+voU9b/PqseO23AdhB8ex7w6JiLKYuuMx+rPxqY4h9kWo Uwgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=c3r2VBDO; 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 f69si5612537pjg.43.2019.06.03.00.31.14; Mon, 03 Jun 2019 00:31:32 -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; dkim=fail header.i=@ffwll.ch header.s=google header.b=c3r2VBDO; 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 S1727183AbfFCH2Y (ORCPT + 99 others); Mon, 3 Jun 2019 03:28:24 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:43288 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726406AbfFCH2X (ORCPT ); Mon, 3 Jun 2019 03:28:23 -0400 Received: by mail-ed1-f65.google.com with SMTP id w33so25476874edb.10 for ; Mon, 03 Jun 2019 00:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=OBEcUSBuSXIEvv5YvVgrfg8sH2Ivurz6vfRZ/RbnW8s=; b=c3r2VBDOcjk/IaoS1iEhdnBHs0a2Os6YL6UFYKEI8rzefd59imwg2qAw7zk4Xx1a4y wXrbqPurvCbQaQIeDSV4qLR69dILNEj5dgavlAWWYSiH+jfoSh4kCg2CP7IhOVtfIhvB 2mKh2BMDOiYB8g3NYojM92OqHDEvev8cNy7MI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=OBEcUSBuSXIEvv5YvVgrfg8sH2Ivurz6vfRZ/RbnW8s=; b=KQYM7KKR+L6KNcKUi5jCQAJvsSEXpRzoOnfo4AAWDruK6YkMsEwTv5rueFfjF6Ccsz kAhsT3HfXdaNT2DlZVyf6/iX+MDBnnFw57zB0W/P9A7Rdn+Wka89tVPkAnQRhLektPkV KW4iOuITsTILRyWesrZV14k1ItjrTAMrTMCTmxmD9s194k9VA14s6WEuOI5mUjIeDuGh t24cBlJZfJ48zMJuIxzheHb0by0Uf4Qg4W14PxsJjKEA+iMUBG22GJW2aIc+tekxBHpF oqCWq5jIzvO4s96gFKKOHfKAKGy4WcWwmAr8uRUqT9Vfx0vQmi3tRqDD7TE0T/dhly3y r4vQ== X-Gm-Message-State: APjAAAW5ju+rskzL2lHxRvEL6sickaIiMLWTux6RNaGKXhqeVI/Y/KjL +QgZqA5qAtQZ37yZf4RyMN59ow== X-Received: by 2002:a17:906:f0d7:: with SMTP id dk23mr1922389ejb.232.1559546901731; Mon, 03 Jun 2019 00:28:21 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id i13sm3756347edq.58.2019.06.03.00.28.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Jun 2019 00:28:21 -0700 (PDT) Date: Mon, 3 Jun 2019 09:28:18 +0200 From: Daniel Vetter To: Chris Wilson Cc: Janusz Krzysztofik , intel-gfx@lists.freedesktop.org, Daniel Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Michal Wajdeczko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/1] drm/i915: Split off pci_driver.remove() tail to drm_driver.release() Message-ID: <20190603072818.GA21222@phenom.ffwll.local> Mail-Followup-To: Chris Wilson , Janusz Krzysztofik , intel-gfx@lists.freedesktop.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Michal Wajdeczko , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20190530092426.23880-1-janusz.krzysztofik@linux.intel.com> <20190530092426.23880-2-janusz.krzysztofik@linux.intel.com> <155920920944.2224.169121808439828849@skylake-alporthouse-com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155920920944.2224.169121808439828849@skylake-alporthouse-com> X-Operating-System: Linux phenom 4.14.0-3-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote: > 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? +1 on that rename, load/unload is really terribly confusing and has horrible semantics in the dri1 shadow attach world ... -Daniel > > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch