Hi,
On Tue, Apr 26, 2022 at 8:37 AM Abhinav Kumar quic_abhinavk@quicinc.com wrote:
Can you provide the exact EDID from the failing test case? Maybe that will help shed some light on what's going on. I looked at the original commit and it just referred to 4.2.2.1, which I assume is "EDID Read upon HPD Plug Event", but that doesn't give details that seem relevant to the discussion here.
Yes so it is 4.2.2.1 and 4.2.2.6.
That alone wont give the full picture.
So its a combination of things.
While running the test, the test equipment published only one mode. But we could not support that mode because of 2 lanes. Equipment did not add 640x480 to the list of modes. DRM fwk will also not add it because count_modes is not 0 ( there was one mode ). So we ended up making these changes.
Ah! This is useful context and makes tons of sense.
This really feels like something that could be handled in the core. OK, See:
https://lore.kernel.org/r/20220426114627.2.I4ac7f55aa446699f8c200a23c1046325...
I guess maybe what's happening is that the test case is giving an EDID where all the modes are not supportable by the current clock rate / lanes? ...and then somehow we're not falling back to 640x480. It's always possible that this is a userspace problem.
In any case, would you object to a revert of the patches in the short term?
Not sure, if you saw this change kuogee posted last night. https://patchwork.freedesktop.org/patch/483415/ We did decided to remove all the code related to these test cases and handle them in IGT.
I hadn't seen it yet and I wasn't CCed. :( I'll take a look now.