All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel J Blueman <daniel@quora.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	stable@vger.kernel.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.
Date: Thu, 22 Sep 2022 12:23:23 +0300	[thread overview]
Message-ID: <87illf7ofo.fsf@intel.com> (raw)
In-Reply-To: <20220921173914.1606359-1-rodrigo.vivi@intel.com>


Cc: Rafael

On Wed, 21 Sep 2022, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> The force_probe protection actively avoids the probe of i915 to
> manage a device that is currently under development. It is a nice
> protection for future users when getting a new platform but using
> some older kernel.
>
> However, when we avoid the probe we don't take back the registration
> of the device. We cannot give up the registration anyway since we can
> have multiple devices present. For instance an integrated and a discrete
> one.
>
> When this scenario occurs, the user will not be able to change any
> of the runtime pm configuration of the unmanaged device. So, it will
> be blocked in D0 state wasting power. This is specially bad in the
> case where we have a discrete platform attached, but the user is
> able to fully use the integrated one for everything else.
>
> So, let's put the protected and unmanaged device in D3. So we can
> save some power.
>
> Reported-by: Daniel J Blueman <daniel@quora.org>
> Cc: stable@vger.kernel.org
> Cc: Daniel J Blueman <daniel@quora.org>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 77e7df21f539..fc3e7c69af2a 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
>  #include <drm/drm_color_mgmt.h>
>  #include <drm/drm_drv.h>
>  #include <drm/i915_pciids.h>
> +#include <linux/pm_runtime.h>
>  
>  #include "gt/intel_gt_regs.h"
>  #include "gt/intel_sa_media.h"
> @@ -1304,6 +1305,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  {
>  	struct intel_device_info *intel_info =
>  		(struct intel_device_info *) ent->driver_data;
> +	struct device *kdev = &pdev->dev;
>  	int err;
>  
>  	if (intel_info->require_force_probe &&
> @@ -1314,6 +1316,12 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  			 "module parameter or CONFIG_DRM_I915_FORCE_PROBE=%04x configuration option,\n"
>  			 "or (recommended) check for kernel updates.\n",
>  			 pdev->device, pdev->device, pdev->device);
> +
> +		/* Let's not waste power if we are not managing the device */
> +		pm_runtime_use_autosuspend(kdev);
> +		pm_runtime_allow(kdev);
> +		pm_runtime_put_autosuspend(kdev);
> +
>  		return -ENODEV;
>  	}

-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Daniel J Blueman <daniel@quora.org>,
	stable@vger.kernel.org, Rodrigo Vivi <rodrigo.vivi@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.
Date: Thu, 22 Sep 2022 12:23:23 +0300	[thread overview]
Message-ID: <87illf7ofo.fsf@intel.com> (raw)
In-Reply-To: <20220921173914.1606359-1-rodrigo.vivi@intel.com>


Cc: Rafael

On Wed, 21 Sep 2022, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> The force_probe protection actively avoids the probe of i915 to
> manage a device that is currently under development. It is a nice
> protection for future users when getting a new platform but using
> some older kernel.
>
> However, when we avoid the probe we don't take back the registration
> of the device. We cannot give up the registration anyway since we can
> have multiple devices present. For instance an integrated and a discrete
> one.
>
> When this scenario occurs, the user will not be able to change any
> of the runtime pm configuration of the unmanaged device. So, it will
> be blocked in D0 state wasting power. This is specially bad in the
> case where we have a discrete platform attached, but the user is
> able to fully use the integrated one for everything else.
>
> So, let's put the protected and unmanaged device in D3. So we can
> save some power.
>
> Reported-by: Daniel J Blueman <daniel@quora.org>
> Cc: stable@vger.kernel.org
> Cc: Daniel J Blueman <daniel@quora.org>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Anshuman Gupta <anshuman.gupta@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 77e7df21f539..fc3e7c69af2a 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -25,6 +25,7 @@
>  #include <drm/drm_color_mgmt.h>
>  #include <drm/drm_drv.h>
>  #include <drm/i915_pciids.h>
> +#include <linux/pm_runtime.h>
>  
>  #include "gt/intel_gt_regs.h"
>  #include "gt/intel_sa_media.h"
> @@ -1304,6 +1305,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  {
>  	struct intel_device_info *intel_info =
>  		(struct intel_device_info *) ent->driver_data;
> +	struct device *kdev = &pdev->dev;
>  	int err;
>  
>  	if (intel_info->require_force_probe &&
> @@ -1314,6 +1316,12 @@ static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  			 "module parameter or CONFIG_DRM_I915_FORCE_PROBE=%04x configuration option,\n"
>  			 "or (recommended) check for kernel updates.\n",
>  			 pdev->device, pdev->device, pdev->device);
> +
> +		/* Let's not waste power if we are not managing the device */
> +		pm_runtime_use_autosuspend(kdev);
> +		pm_runtime_allow(kdev);
> +		pm_runtime_put_autosuspend(kdev);
> +
>  		return -ENODEV;
>  	}

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2022-09-22  9:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 17:39 [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device Rodrigo Vivi
2022-09-21 17:39 ` Rodrigo Vivi
2022-09-21 19:56 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-09-21 21:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-09-22  7:56 ` [Intel-gfx] [PATCH] " Tvrtko Ursulin
2022-09-22  7:56   ` Tvrtko Ursulin
2022-09-22  9:43   ` Rodrigo Vivi
2022-09-22  9:43     ` Rodrigo Vivi
2022-09-22 11:09     ` Gupta, Anshuman
2022-09-22 12:40       ` Gupta, Anshuman
2022-09-22 12:40         ` Gupta, Anshuman
2022-09-23 18:20         ` Vivi, Rodrigo
2022-09-23 18:20           ` Vivi, Rodrigo
2022-09-24 17:52           ` Rafael J. Wysocki
2022-09-24 17:52             ` Rafael J. Wysocki
2022-09-22  9:23 ` Jani Nikula [this message]
2022-09-22  9:23   ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87illf7ofo.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel@quora.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.