On Thu, Sep 17, 2020 at 10:39 AM Zhang, Jinlong <Jinlong.Zhang@xxxxxxx> wrote:
>
> 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);
That should do it. DC code has #include <linux/delay.h> in a bunch of
other files.
Alex
>
> -----Original Message-----
> From: Zhuo, Qingqing <Qingqing.Zhuo@xxxxxxx>
> Sent: Thursday, September 17, 2020 9:02 PM
> To: Koenig, Christian <Christian.Koenig@xxxxxxx>; Alex Deucher <alexdeucher@xxxxxxxxx>
> Cc: Brol, Eryk <Eryk.Brol@xxxxxxx>; Li, Sun peng (Leo) <Sunpeng.Li@xxxxxxx>; Lakha, Bhawanpreet <Bhawanpreet.Lakha@xxxxxxx>; Siqueira, Rodrigo <Rodrigo.Siqueira@xxxxxxx>; amd-gfx list <amd-gfx@xxxxxxxxxxxxxxxxxxxxx>; Zhang, Jinlong <Jinlong.Zhang@xxxxxxx>; Wentland, Harry <Harry.Wentland@xxxxxxx>
> 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@xxxxxxx> wrote:
> >>> [AMD Official Use Only - Internal Distribution Only]
> >>>
> >>>On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo <qingqing.zhuo@xxxxxxx> wrote:
> >>>> From: jinlong zhang <jinlong.zhang@xxxxxxx>
> >>>>
> >>> >[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@xxxxxxx>
> >>>> Reviewed-by: Wenjing Liu <Wenjing.Liu@xxxxxxx>
> >>>> Acked-by: Qingqing Zhuo <qingqing.zhuo@xxxxxxx>
> >>>> ---
> >>>> 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@xxxxxxxxxxxxxxxxxxxxx
> >>>> 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@xxxxxxxxxxxxxxxxxxxxx
> >> 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
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
