On Thu, Jan 22, 2026 at 12:22 PM Lazar, Lijo <[email protected]> wrote:
>
>
>
> 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?
According to the PMFW team, yes. I think the issue is the int to
float conversion rounds up rather than down.
Alex
>
> 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
> >>
>
