On 2019-07-18 11:16 p.m., Nathan Chancellor wrote:
> On Wed, Jul 03, 2019 at 10:52:16PM -0700, Nathan Chancellor wrote:
>> clang warns:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:336:8:
>> warning: implicit conversion from enumeration type 'enum smu_clk_type'
>> to different enumeration type 'enum amd_pp_clock_type'
>> [-Wenum-conversion]
>> dc_to_smu_clock_type(clk_type),
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_pp_smu.c:421:14:
>> warning: implicit conversion from enumeration type 'enum
>> amd_pp_clock_type' to different enumeration type 'enum smu_clk_type'
>> [-Wenum-conversion]
>> dc_to_pp_clock_type(clk_type),
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> There are functions to properly convert between all of these types, use
>> them so there are no longer any warnings.
>>
>> Fixes: a43913ea50a5 ("drm/amd/powerplay: add function get_clock_by_type_with_latency for navi10")
>> Fixes: e5e4e22391c2 ("drm/amd/powerplay: add interface to get clock by type with latency for display (v2)")
>> Link: https://github.com/ClangBuiltLinux/linux/issues/586
>> Signed-off-by: Nathan Chancellor <natechancellor@xxxxxxxxx>
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
>> index eac09bfe3be2..0f76cfff9d9b 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
>> @@ -333,7 +333,7 @@ bool dm_pp_get_clock_levels_by_type(
>> }
>> } else if (adev->smu.funcs && adev->smu.funcs->get_clock_by_type) {
>> if (smu_get_clock_by_type(&adev->smu,
>> - dc_to_smu_clock_type(clk_type),
>> + dc_to_pp_clock_type(clk_type),
smu_funcs->get_clock_by_type doesn't seem to be hooked up anywhere,
so this looks to be the most correct.
Although it makes more sense to use smu_clk_types here rather than
amd_pp_clock_type - any reason why this isn't the case?
>> &pp_clks)) {
>> get_default_clock_levels(clk_type, dc_clks);
>> return true;
>> @@ -418,7 +418,7 @@ bool dm_pp_get_clock_levels_by_type_with_latency(
>> return false;
>> } else if (adev->smu.ppt_funcs && adev->smu.ppt_funcs->get_clock_by_type_with_latency) {
>> if (smu_get_clock_by_type_with_latency(&adev->smu,
>> - dc_to_pp_clock_type(clk_type),
>> + dc_to_smu_clock_type(clk_type),
This is slightly concerning. The functions are doing the right thing,
but amd_pp_clock_type doesn't map 1-1 to smu_clk_type... In any case,
this looks good to me.
Reviewed-by: Leo Li <sunpeng.li@xxxxxxx>
>> &pp_clks))
>> return false;
>> }
>> --
>> 2.22.0
>>
>
> Gentle ping for review, this is the last remaining warning that I see
> from amdgpu on next-20190718.
>
> Cheers,
> Nathan
>
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
