Re: [PATCH] drm/amd/powerplay: avoid DPM reenable process on Navi1x ASICs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 11, 2019 at 4:25 AM Evan Quan <evan.quan@xxxxxxx> wrote:
>
> Otherwise, without RLC reinitialization, the DPM reenablement
> will fail. That affects the custom pptable uploading.
>
> Change-Id: I6fe2ed5ce23f2a5b66f371c0b6d1f924837e5af6
> Signed-off-by: Evan Quan <evan.quan@xxxxxxx>
> ---
>  drivers/gpu/drm/amd/powerplay/amdgpu_smu.c    | 32 +++++++++++++++----
>  .../gpu/drm/amd/powerplay/inc/amdgpu_smu.h    |  1 +
>  2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> index 76a4154b3be2..a4d67b30fd72 100644
> --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> @@ -1293,10 +1293,25 @@ static int smu_hw_fini(void *handle)
>                 return ret;
>         }
>
> -       ret = smu_stop_dpms(smu);
> -       if (ret) {
> -               pr_warn("Fail to stop Dpms!\n");
> -               return ret;
> +       /*
> +        * For custom pptable uploading, skip the DPM features
> +        * disable process on Navi1x ASICs.
> +        *   - As the gfx related features are under control of
> +        *     RLC on those ASICs. RLC reinitialization will be
> +        *     needed to reenable them. That will cost much more
> +        *     efforts.
> +        *
> +        *   - SMU firmware can handle the DPM reenablement
> +        *     properly.
> +        */
> +       if (!smu->uploading_custom_pp_table ||
> +           !((adev->asic_type >= CHIP_NAVI10) &&
> +             (adev->asic_type <= CHIP_NAVI12))) {
> +               ret = smu_stop_dpms(smu);
> +               if (ret) {
> +                       pr_warn("Fail to stop Dpms!\n");
> +                       return ret;
> +               }
>         }
>
>         kfree(table_context->driver_pptable);
> @@ -1324,13 +1339,16 @@ int smu_reset(struct smu_context *smu)
>         struct amdgpu_device *adev = smu->adev;
>         int ret = 0;
>
> +       smu->uploading_custom_pp_table = true;
> +

Do we need to differentiate between reloading for a pptable update and
reloading for a gpu reset or suspend/resume or is that already
handled?
Shouldn't we be setting/clearing uploading_custom_pp_table in
smu_sys_set_pp_table() around the call to smu_reset()?

Alex

>         ret = smu_hw_fini(adev);
>         if (ret)
> -               return ret;
> +               goto out;
>
>         ret = smu_hw_init(adev);
> -       if (ret)
> -               return ret;
> +
> +out:
> +       smu->uploading_custom_pp_table = false;
>
>         return ret;
>  }
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> index 8120e7587585..215841f5fb93 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> @@ -391,6 +391,7 @@ struct smu_context
>
>         uint32_t smc_if_version;
>
> +       bool uploading_custom_pp_table;
>  };
>
>  struct i2c_adapter;
> --
> 2.24.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux