[PATCH 2/2] drm/amdgpu/display: use msleep rather than udelay for long delays
Harry Wentland
harry.wentland at amd.com
Tue Jan 25 15:33:46 UTC 2022
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 at amd.com>
>> ---
>> 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) {
>>
More information about the amd-gfx
mailing list