<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - Hardware polling takes over a second with DisplayPort connected" href="https://bugs.freedesktop.org/show_bug.cgi?id=81258#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - Hardware polling takes over a second with DisplayPort connected" href="https://bugs.freedesktop.org/show_bug.cgi?id=81258">bug 81258</a> from <a class="email" href="mailto:tprevite@gmail.com" title="Todd Previte <tprevite@gmail.com>"> Todd Previte</a> <pre>Can you switch your monitor back to 1.1a and see if it still issues all those defers? >From the log, it looks like we're spending an inordinate amount of time waiting for the display to respond to the EDID request(s). From the beginning to the end of the first block of defers if about 0.65 seconds. That's just for the first EDID read. Part of the reason for this is the number of retries and the transaction delays required by the Displayport specification. Each deferred transaction must be reattempted 7 times and each time it waits the normal 400us plus an additional 500-600us to give the sink more time to respond. So each defer costs roughly 1ms of time. A minimum of 8 transactions is required to read an entire 128-byte EDID block (16 bytes maximum per I2C-over-AUX transaction). However, the sink device is not required to reply with all of the data for the transaction. It can ACK with partial data and continue the transaction on the next request. So what should have been a single 16-byte transaction could turn into five 3-byte transactions and one 1-byte transaction. Each of these transactions can also be deferred up to 7 times, so those individual transaction delays that seem somewhat insignificant can really start to add up. -T</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>