On Thu, Sep 17, 2020 at 4:26 AM Christian König
<ckoenig.leichtzumer...@gmail.com> wrote:
>
> Am 17.09.20 um 00:18 schrieb Alex Deucher:
> > On Wed, Sep 16, 2020 at 6:16 PM Zhuo, Qingqing <qingqing.z...@amd.com> 
> > wrote:
> >> [AMD Official Use Only - Internal Distribution Only]
> >>
> >> On Wed, Sep 16, 2020 at 3:42 PM Qingqing Zhuo <qingqing.z...@amd.com> 
> >> wrote:
> >>> From: jinlong zhang <jinlong.zh...@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.

I think usleep_range() is what you want.

Alex

>
> Regards,
> Christian.
>
> >
> > Alex
> >
> >> Thank you,
> >> Lillian
> >>
> >>
> >>> Signed-off-by: jinlong zhang <jinlong.zh...@amd.com>
> >>> Reviewed-by: Wenjing Liu <wenjing....@amd.com>
> >>> Acked-by: Qingqing Zhuo <qingqing.z...@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@lists.freedesktop.org
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >>> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=02%7C01%7Cqi
> >>> ngqing.zhuo%40amd.com%7C36c3bee68c28448769fa08d85a884619%7C3dd8961fe48
> >>> 84e608e11a82d994e183d%7C0%7C0%7C637358888627498307&amp;sdata=mynpHpiup
> >>> J%2FU2o5gZNW%2Bft%2Fg2beFY86%2BzMRWoTZCghQ%3D&amp;reserved=0
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reply via email to