[PATCH 04/15] drm/amd/display: Replace msleep with udelay while read edid return defer.

[Zhang, Jinlong]

HI Christian
While #include <linux/delay.h>, it prompt ..\..\..\..\..\dc\dce\dce_aux.c(31): fatal error C1083: Cannot open include file: 'linux/delay.h': No such file or directory
Could you help to check how to include the header of void usleep_range(unsigned long min, unsigned long max);

-----Original Message-----
From: Zhuo, Qingqing <Qingqing.Zhuo at amd.com> 
Sent: Thursday, September 17, 2020 9:02 PM
To: Koenig, Christian <Christian.Koenig at amd.com>; Alex Deucher <alexdeucher at gmail.com>
Cc: Brol, Eryk <Eryk.Brol at amd.com>; Li, Sun peng (Leo) <Sunpeng.Li at amd.com>; Lakha, Bhawanpreet <Bhawanpreet.Lakha at amd.com>; Siqueira, Rodrigo <Rodrigo.Siqueira at amd.com>; amd-gfx list <amd-gfx at lists.freedesktop.org>; Zhang, Jinlong <Jinlong.Zhang at amd.com>; Wentland, Harry <Harry.Wentland at amd.com>
Subject: RE: [PATCH 04/15] drm/amd/display: Replace msleep with udelay while read edid return defer.

[AMD Official Use Only - Internal Distribution Only]

Am 17.09.20 um 00:18 schrieb Alex Deucher:
>> On Wed, Sep 16, 2020 at 6:16 PM Zhuo, Qingqing <Qingqing.Zhuo at amd.com> wrote:
>>> [AMD Official Use Only - Internal Distribution Only]
>>>
>>>On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo <qingqing.zhuo at amd.com> wrote:
>>>> From: jinlong zhang <jinlong.zhang at amd.com>
>>>>
>>> >[why]
>>>>while read edid return defer, then it enter to msleep, but it 
>>>>actually took more time during msleep, this will cause remaining 
>>>>edid read fail.
>>>>
>>>> [how]
>>>> Replacing msleep with udelay, it will not take any extra time, edid return pass finally.
>>> How long of a delay are we talking about here?  Some platforms don't support long udelays and someone will send a patch to change this to msleep.
>>>
>>> Alex
>>>
>>> ---------------------
>>>
>>> Hi Alex,
>>>
>>> It's between 0-5ms for generic cases, though there exist some dongle workaround cases where we will do 70ms. Would this be a concern?
>> I think ARM has a limit of 2ms for udelay.

> Yeah, there is even a define somewhere for this.

> If you need a delay which is longer than this but still more precise than msleep() then there is the high precision timer sleep as alternative.

> I've forgotten the function name to use here, but there was a LWN article about this a few years ago. You just need to google a bit.

Hi Alex and Christian,

Thanks a lot for the input! Given what's been discussed, I will drop this patch for now.

Regards,
Lillian

>
> Regards,
> Christian.
>>
>> Alex
>>
>>> Thank you,
>>> Lillian
>>>
>>>
>>>> Signed-off-by: jinlong zhang <jinlong.zhang at amd.com>
>>>> Reviewed-by: Wenjing Liu <Wenjing.Liu at amd.com>
>>>> Acked-by: Qingqing Zhuo <qingqing.zhuo at amd.com>
>>>> ---
>>>> drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
>>>> b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
>>>> index 743042d5905a..cdcad82765e0 100644
>>>> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
>>>> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_aux.c
>>>> @@ -653,7 +653,7 @@ bool dce_aux_transfer_with_retries(struct ddc_service *ddc,
>>>>                                          if ((*payload->reply == AUX_TRANSACTION_REPLY_AUX_DEFER) ||
>>>>                                                  (*payload->reply == AUX_TRANSACTION_REPLY_I2C_OVER_AUX_DEFER)) {
>>>>                                                  if (payload->defer_delay > 0)
>>>> -                                                       msleep(payload->defer_delay);
>>>> +
>>>> + udelay(payload->defer_delay * 1000);
>>>>                                          }
>>>>                                  }
>>>>                                  break;
>>>> --
>>>> 2.17.1
>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx at lists.freedesktop.org
>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
>>>> i
>>>> st
>>>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7
>>>> C
>>>> qi
>>>> ngqing.zhuo%40amd.com%7C36c3bee68c28448769fa08d85a884619%7C3dd8961f
>>>> e
>>>> 48
>>>> 84e608e11a82d994e183d%7C0%7C0%7C637358888627498307&sdata=mynpHp
>>>> i
>>>> up
>>>> J%2FU2o5gZNW%2Bft%2Fg2beFY86%2BzMRWoTZCghQ%3D&reserved=0
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> t 
>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CQ
>> i
>> ngqing.Zhuo%40amd.com%7Cd4acd0d5e65c49a7270f08d85ae37036%7C3dd8961fe4
>> 8
>> 84e608e11a82d994e183d%7C0%7C0%7C637359280197936127&sdata=ahcoCqG9
>> 1
>> EDMNlHNSk4Eimh1azMtRWSX%2BKyHCdpFq1Q%3D&reserved=0