All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Ma Jun <Jun.Ma2@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Alexander.Deucher@amd.com, Kenneth.Feng@amd.com, kevinyang.wang@amd.com
Subject: Re: [PATCH] drm/amdgpu: Add a new module param to disable d3cold
Date: Wed, 29 Nov 2023 09:35:25 -0600	[thread overview]
Message-ID: <d21116d8-9747-4b0f-b574-18b0d5558f16@amd.com> (raw)
In-Reply-To: <20231129085156.30698-1-Jun.Ma2@amd.com>

On 11/29/2023 02:51, Ma Jun wrote:
> Some platforms can't resume from d3cold state, So add a
> new module parameter to disable d3cold state for debugging
> purpose or workaround.
> 
> Signed-off-by: Ma Jun <Jun.Ma2@amd.com>
> ---

This patch is essentially an 'amdgpu knob' for d3cold on the root port. 
At least for debugging purposes we also have a sysfs file 
'd3cold_allowed' that will enact the same behavior.

I do have a patch that I proposed to PCI core that stops d3cold_allowed 
from working in favor of requesting pcie_port_pm=off to be used instead 
for debugging purposes.

However that's a 'relatively big' debugging knob however as it will 
apply to all PCIe root ports.

Considering above I'm in favor of this being available as a localized 
debugging path for just the root port the dGPU is connected to.

Some comments below though:

>   drivers/gpu/drm/amd/amdgpu/amdgpu.h        | 1 +
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +++++++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c    | 8 ++++++++
>   3 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index a9f54df9d33e..db9f60790267 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -166,6 +166,7 @@ extern char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];
>   extern int amdgpu_dpm;
>   extern int amdgpu_fw_load_type;
>   extern int amdgpu_aspm;
> +extern int amdgpu_d3cold;
>   extern int amdgpu_runtime_pm;
>   extern uint amdgpu_ip_block_mask;
>   extern int amdgpu_bapm;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 22b6a910b7f2..90501c44e7d0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -264,6 +264,13 @@ bool amdgpu_device_supports_px(struct drm_device *dev)
>   bool amdgpu_device_supports_boco(struct drm_device *dev)
>   {
>   	struct amdgpu_device *adev = drm_to_adev(dev);
> +	struct pci_dev *parent;
> +
> +	if (!amdgpu_d3cold) {
> +		parent = pcie_find_root_port(adev->pdev);
> +		pci_d3cold_disable(parent);
> +		return false;
> +	}
>   
>   	if (adev->has_pr3 ||
>   	    ((adev->flags & AMD_IS_PX) && amdgpu_is_atpx_hybrid()))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 5f14f04cb553..c9fbb8bd4169 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -145,6 +145,7 @@ char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];
>   int amdgpu_dpm = -1;
>   int amdgpu_fw_load_type = -1;
>   int amdgpu_aspm = -1;
> +int amdgpu_d3cold = -1;

If this was chained to a larger workaround (such as automatically 
applying to a DMI quirk) it would make sense as int and with using
-1 for auto.  However there is a pretty dramatic downside for using this 
knob that it can break s2idle.

In my testing I've found that the following happens on an A+A design 
after s2idle with this parameter in use.

[   70.572270] pcieport 0000:01:00.0: Unable to change power state from 
D3cold to D0, device inaccessible
[   70.572481] pcieport 0000:02:00.0: Unable to change power state from 
D3cold to D0, device inaccessible
[   72.855769] amdgpu 0000:03:00.0: not ready 1023ms after resume; waiting
[   73.943545] amdgpu 0000:03:00.0: not ready 2047ms after resume; waiting
[   76.055602] amdgpu 0000:03:00.0: not ready 4095ms after resume; waiting
[   80.279550] amdgpu 0000:03:00.0: not ready 8191ms after resume; waiting
[   88.983562] amdgpu 0000:03:00.0: not ready 16383ms after resume; waiting
[  105.879581] amdgpu 0000:03:00.0: not ready 32767ms after resume; waiting
[  142.743646] amdgpu 0000:03:00.0: not ready 65535ms after resume; 
giving up
[  142.743793] amdgpu 0000:03:00.0: Unable to change power state from 
D3cold to D0, device inaccessible
[  142.804011] snd_hda_intel 0000:03:00.1: Unable to change power state 
from D3cold to D0, device inaccessible

So I don't see us ever automatically using this and it should be 
debugging only.  IOW this doesn't need to be integer; it can be boolean.

>   int amdgpu_runtime_pm = -1;
>   uint amdgpu_ip_block_mask = 0xffffffff;
>   int amdgpu_bapm = -1;
> @@ -359,6 +360,13 @@ module_param_named(fw_load_type, amdgpu_fw_load_type, int, 0444);
>   MODULE_PARM_DESC(aspm, "ASPM support (1 = enable, 0 = disable, -1 = auto)");
>   module_param_named(aspm, amdgpu_aspm, int, 0444);
>   
> +/**
> + * DOC: d3cold (int)

If you flip it to boolean as I suggested this should probably either 
rename to disable_d3cold or you should default to TRUE.

> + * To disable d3cold (1 = enable, 0 = disable). The default is -1 (auto, enabled).
> + */
> +MODULE_PARM_DESC(d3cold, "d3cold support (1 = enable, 0 = disable, -1 = auto)");
> +module_param_named(d3cold, amdgpu_d3cold, int, 0444);
> +
>   /**
>    * DOC: runpm (int)
>    * Override for runtime power management control for dGPUs. The amdgpu driver can dynamically power down


  reply	other threads:[~2023-11-29 15:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29  8:51 [PATCH] drm/amdgpu: Add a new module param to disable d3cold Ma Jun
2023-11-29 15:35 ` Mario Limonciello [this message]
2023-11-29 18:40   ` Alex Deucher
2023-11-30  9:46   ` Ma, Jun
2023-11-29 16:39 ` Alex Deucher
2023-11-30  6:29   ` Ma, Jun
2023-11-30  9:18     ` Lazar, Lijo
2023-11-30 10:47       ` Ma, Jun
2023-11-30 10:55         ` Lazar, Lijo
2023-11-30 14:21     ` Alex Deucher

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=d21116d8-9747-4b0f-b574-18b0d5558f16@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Jun.Ma2@amd.com \
    --cc=Kenneth.Feng@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=kevinyang.wang@amd.com \
    /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.