For this, I believe we're updating `table_context->overdrive_table` with the values set by the user, wouldn't the intended behavior here be to restore the settings that were there on boot?
If so, I think we'd have to cache the overdrive table that was there on boot, and use that in the response for `PP_OD_RESTORE_DEFAULT_TABLE`, no? I'm doing some testing on this patchset, but on initial lookover that's the only thing I saw. I could be mistaken, but I think this just writes the overdrive table that we are currently using over again instead of writing the default one. On 1/25/20 11:48 AM, Alex Deucher wrote: > Was missing before. > > Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020 > Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> > --- > drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c > b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c > index d2d45181ae23..f60762f9b143 100644 > --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c > +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c > @@ -2062,6 +2062,14 @@ static int navi10_od_edit_dpm_table(struct smu_context > *smu, enum PP_OD_DPM_TABL > if (ret) > return ret; > od_table->UclkFmax = input[1]; > + break; > + case PP_OD_RESTORE_DEFAULT_TABLE: > + ret = smu_update_table(smu, SMU_TABLE_OVERDRIVE, 0, > table_context->overdrive_table, false); > + if (ret) { > + pr_err("Failed to export over drive table!\n"); > + return ret; > + } > + > break; > case PP_OD_COMMIT_DPM_TABLE: > navi10_dump_od_table(od_table); > _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
