Re: [PATCH 2/2] drm/amdgpu/display: use msleep rather than udelay for long delays

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

 




On 2022-01-25 06:32, Lazar, Lijo wrote:
> 
> 
> On 1/20/2022 11:34 PM, Alex Deucher wrote:
>> Some architectures (e.g., ARM) throw an compilation error if the
>> udelay is too long.  In general udelays of longer than 2000us are
>> not recommended on any architecture.  Switch to msleep in these
>> cases.
>>
>> Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
>> ---
>>   drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> index aa1c67c3c386..eb4432dca761 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>> @@ -6941,7 +6941,7 @@ bool dpcd_write_128b_132b_sst_payload_allocation_table(
>>               }
>>           }
>>           retries++;
>> -        udelay(5000);
>> +        msleep(5);
> 
> msleep is not recommended for sleeps < 20ms. The original code (modified in patch 1) seems to do such a check. As per kernel doc, if precision matters recommendation is to use usleep_range().
> 

If I remember right the sleep (non-polling) function can take (significantly) longer than the requested time, but never shorter. This should be fine in this case.

Harry

> Thanks,
> Lijo
> 
>>       }
>>         if (!result && retries == max_retries) {
>> @@ -6993,7 +6993,7 @@ bool dpcd_poll_for_allocation_change_trigger(struct dc_link *link)
>>               break;
>>           }
>>   -        udelay(5000);
>> +        msleep(5);
>>       }
>>         if (result == ACT_FAILED) {
>>




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

  Powered by Linux