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/
