Thank you for your contribution! Sashiko AI review found 3 potential issue(s) 
to consider:
- [High] drm/amdgpu: runtime PM reference leak in amdgpu_pm_acpi_event_handler()
- [High] drm/amdgpu: negative return treated as active in 
amdgpu_pm_acpi_event_handler()
- [Medium] drm/amdgpu: missed SMU AC/DC update in 
amdgpu_pm_acpi_event_handler() during resume
--

commit 5f8266206967cf1a10c12c800fc318910f1e455a
Author: Andre Eikmeyer <[email protected]>

drm/amdgpu: Skip AC/DC notification while the GPU is runtime suspended

This commit updates amdgpu_pm_acpi_event_handler() to check if a GMUX GPU is
runtime active via pm_runtime_get_if_active() before sending AC/DC power
source notifications to the SMU. When the GPU is suspended, it records the
updated power state in adev->pm.ac_power so it can be applied upon resume.

> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c 
> b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> index 808be6c425bff..b64f0b681fe1a 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c

[ ... ]

> @@ -498,20 +499,26 @@ int amdgpu_dpm_smu_i2c_bus_access(struct amdgpu_device 
> *adev,
>  
>  void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
>  {
> +     int active = 0;
> +
>       if (adev->pm.dpm_enabled) {
>               mutex_lock(&adev->pm.mutex);
> +             active = adev->pm.rpm_mode == AMDGPU_RUNPM_GMUX ?
> +                             pm_runtime_get_if_active(adev->dev) : 1;

[Severity: Medium]
Can an AC/DC notification be missed if an ACPI event races with runtime
resume?

During rpm_resume() -> amdgpu_pmops_runtime_resume() ->
amdgpu_device_resume(), dev->power.runtime_status remains RPM_RESUMING until
amdgpu_pmops_runtime_resume() returns.

Inside amdgpu_device_resume(), adev->pm.ac_power is consumed without holding
adev->pm.mutex during amdgpu_device_ip_resume() -> pp_resume() ->
hwmgr_resume() on PowerPlay GPUs and during amdgpu_device_ip_late_init() ->
smu_late_init() on swsmu GPUs:

drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:amdgpu_device_resume() {
        ...
        r = amdgpu_device_ip_resume(adev);
        ...
        r = amdgpu_device_ip_late_init(adev);
        if (r)
                goto exit;

        queue_delayed_work(system_dfl_wq, &adev->delayed_init_work,
                           msecs_to_jiffies(AMDGPU_RESUME_MS));
exit:
        ...
        /* Make sure IB tests flushed */
        flush_delayed_work(&adev->delayed_init_work);
}

If amdgpu_pm_acpi_event_handler() runs after IP resume/late_init has already
applied the power state, while flush_delayed_work() or the remainder of
amdgpu_pmops_runtime_resume() is still executing, pm_runtime_get_if_active()
sees runtime_status == RPM_RESUMING and returns 0. Would that cause the
handler to skip notifying the SMU after the resume path has already passed
the point where adev->pm.ac_power is applied, leaving the GPU with stale
AC/DC limits?

> +
>               if (power_supply_is_system_supplied() > 0)
>                       adev->pm.ac_power = true;
>               else
>                       adev->pm.ac_power = false;
>  
> -             if (adev->powerplay.pp_funcs &&
> -                 adev->powerplay.pp_funcs->notify_ac_dc)
> -                     amdgpu_dpm_notify_ac_dc(adev);
> -
> -             if (is_support_sw_smu(adev))
> -                     smu_set_ac_dc(adev->powerplay.pp_handle, true);
> +             if (active) {

[Severity: High]
Should this check be (active > 0) instead of (active)?

pm_runtime_get_if_active() returns 1 when the device is active, 0 when it is
not active, and -EINVAL without incrementing dev->power.usage_count when
runtime PM is disabled (dev->power.disable_depth > 0 or !CONFIG_PM).

On GMUX systems, amdgpu_pci_probe() sets DPM_FLAG_SMART_PREPARE |
DPM_FLAG_SMART_SUSPEND | DPM_FLAG_MAY_SKIP_RESUME, which allows a
runtime-suspended GMUX GPU (powered off, with adev->pm.dpm_enabled still true
on PowerPlay GPUs) to remain suspended across system sleep while the PM core
increments dev->power.disable_depth during __device_suspend_late() through
dpm_resume_early().

If an ACPI AC/DC event runs while disable_depth > 0, active will be -EINVAL
and if (active) will evaluate to true, calling amdgpu_dpm_notify_ac_dc() or
smu_set_ac_dc() without a runtime PM reference while the GPU may be powered
off.

> +                     if (adev->powerplay.pp_funcs &&
> +                         adev->powerplay.pp_funcs->notify_ac_dc)
> +                             amdgpu_dpm_notify_ac_dc(adev);
>  
> +                     if (is_support_sw_smu(adev))
> +                             smu_set_ac_dc(adev->powerplay.pp_handle, true);
> +             }

[Severity: High]
Does amdgpu_pm_acpi_event_handler() leak the runtime PM usage reference on
adev->dev when the GPU is active?

When adev->pm.rpm_mode == AMDGPU_RUNPM_GMUX and the GPU is in the RPM_ACTIVE
state, pm_runtime_get_if_active(adev->dev) increments dev->power.usage_count
and returns 1. Because there is no matching pm_runtime_put_autosuspend() or
pm_runtime_put() call after notifying the SMU, won't each ACPI AC/DC event
while the GPU is active permanently leak a runtime PM reference and prevent
the GPU from runtime suspending again?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=12

Reply via email to