[AMD Official Use Only - AMD Internal Distribution Only] > Does min need this too or just max? Same question on smu14.
Yes, after confirmed with PMFW team that only 'max' needs to patch this convert, the PMFW will clamp the input value to align the internal fmin/fmax value. And this change will be corrected before submitting this patch. Best Regards, Kevin -----Original Message----- From: Lazar, Lijo <[email protected]> Sent: Friday, January 23, 2026 01:22 To: Alex Deucher <[email protected]> Cc: Wang, Yang(Kevin) <[email protected]>; [email protected]; Zhang, Hawking <[email protected]>; Deucher, Alexander <[email protected]>; Feng, Kenneth <[email protected]> Subject: Re: [PATCH 1/2] drm/amd/pm: fix smu v13 soft clock frequency setting issue On 22-Jan-26 10:32 PM, Alex Deucher wrote: > On Wed, Jan 21, 2026 at 1:27 AM Lazar, Lijo <[email protected]> wrote: >> >> >> >> On 21-Jan-26 8:44 AM, Yang Wang wrote: >>> resolve the issue where some freq frequencies cannot be set >>> correctly due to insufficient floating-point precision. >>> >>> Signed-off-by: Yang Wang <[email protected]> >>> --- >>> drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 1 + >>> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 2 ++ >>> 2 files changed, 3 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h >>> b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h >>> index efeaa3d57712..b0d6b7b0946d 100644 >>> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h >>> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h >>> @@ -55,6 +55,7 @@ >>> #define SMUQ10_TO_UINT(x) ((x) >> 10) >>> #define SMUQ10_FRAC(x) ((x) & 0x3ff) >>> #define SMUQ10_ROUND(x) ((SMUQ10_TO_UINT(x)) + ((SMUQ10_FRAC(x)) >>> >= 0x200)) >>> +#define SMU_V13_SOFT_FREQ_ROUND(x) ((x) + 1) >>> >>> extern const int pmfw_decoded_link_speed[5]; >>> extern const int pmfw_decoded_link_width[7]; diff --git >>> a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c >>> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c >>> index 51f96fdcec24..e27ea0879429 100644 >>> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c >>> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c >>> @@ -1554,6 +1554,7 @@ int smu_v13_0_set_soft_freq_limited_range(struct >>> smu_context *smu, >>> return clk_id; >>> >>> if (max > 0) { >>> + max = SMU_V13_SOFT_FREQ_ROUND(max); >> >> Looks more like a firmware issue. Isn't firmware supposed to round it >> to the closest DPM level frequency? > > Arguably yes, but at this point, it's easier to fix in the driver for > existing programs considering all of the firmware out in the wild. > The question then is will just (x + 1) alone get to the right frequency? Or should the logic be like what firmware is expected to do to find the nearest dpm frequency? Thanks, Lijo > Alex > >> >> Thanks, >> Lijo >> >>> if (automatic) >>> param = (uint32_t)((clk_id << 16) | 0xffff); >>> else >>> @@ -1565,6 +1566,7 @@ int smu_v13_0_set_soft_freq_limited_range(struct >>> smu_context *smu, >>> } >>> >>> if (min > 0) { >>> + min = SMU_V13_SOFT_FREQ_ROUND(min); > > Does min need this too or just max? Same question on smu14. With > that clarified the patch is: > Reviewed-by: Alex Deucher <[email protected]> > > Alex > > >>> if (automatic) >>> param = (uint32_t)((clk_id << 16) | 0); >>> else >>
