Vega 56 failing to process EDID from VR Headset

[Paul Menzel]

Dear James,


Am 13.04.22 um 00:13 schrieb James Dutton:
> On Tue, 12 Apr 2022 at 07:13, Paul Menzel wrote:
>> Am 11.04.22 um 23:39 schrieb James Dutton:
>> So, did you do any changes to Linux? Why do you think the EDID is at fault?
>>
>> […]
>>
>> I suggest to analyze, why `No DP link bandwidth` is logged. The macro is
>> `DC_NO_DP_LINK_BANDWIDTH`, and you should first check why
>> `dp_validate_mode_timing()` in
>> `drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c` returns false.

>> PS: Using the issue tracker [1] might make it easier to keep track of
>> this problem, and also to attach all the necessary information.
>>
>>
>> [1]: https://gitlab.freedesktop.org/drm/amd/-/issues/

> I will do some more investigation. In addition to it not processing
> the EDID particularly well...
> Since my email, I have found out that it is failing to complete CR
> (Clock Recovery) on Link 0,2, but it works on 1,3 at HBR2. All 4 Links
> work at HBR1.   (I need the HBR2 working)
> The CR negotiation in the code looks a bit wrong to me, so I will look
> into that a bit more.
> Looking at the current amdgpu source code   (I am using Mainline
> kernel version 5.17.1), it appears to retry CR negotiation, but each
> time it uses the same settings, rather than try different driver
> parameters, as recommended in the DP standards and compliance test
> documents.

[…]

Awesome, that you review the code with your expertise. Though I suggest 
to look at and work on agd5f/amd-staging-drm-next [1], having the latest 
code for the driver.

> Once I know more, I will put all the info in the issue track, as you
> suggest.

I am looking forward to it. To not get lost in all the problems, one 
email or issue per problem might be a good way forward, and adding 
people adding the code (`git blame -w`) to Cc might also help.

Happy debugging and hacking!


Kind regards,

Paul


[1]: https://gitlab.freedesktop.org/agd5f/linux/