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

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

 



No idea what that is. I can include delay.h just fine in the rest of the driver.

Must be something DC specific.

Regards,
Christian.

Am 17.09.20 um 16:39 schrieb 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@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&amp;data=02%7C01%7
C
qi
ngqing.zhuo%40amd.com%7C36c3bee68c28448769fa08d85a884619%7C3dd8961f
e
48
84e608e11a82d994e183d%7C0%7C0%7C637358888627498307&amp;sdata=mynpHp
i
up
J%2FU2o5gZNW%2Bft%2Fg2beFY86%2BzMRWoTZCghQ%3D&amp;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&amp;data=02%7C01%7CQ
i
ngqing.Zhuo%40amd.com%7Cd4acd0d5e65c49a7270f08d85ae37036%7C3dd8961fe4
8
84e608e11a82d994e183d%7C0%7C0%7C637359280197936127&amp;sdata=ahcoCqG9
1
EDMNlHNSk4Eimh1azMtRWSX%2BKyHCdpFq1Q%3D&amp;reserved=0

_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

  Powered by Linux