* Vega 56 failing to process EDID from VR Headset
@ 2022-04-11 21:39 James Dutton
2022-04-12 6:13 ` Paul Menzel
0 siblings, 1 reply; 6+ messages in thread
From: James Dutton @ 2022-04-11 21:39 UTC (permalink / raw)
To: amd-gfx
Hi,
I have an Oculus Rift S, that I am trying to get working in Linux.
I have an AMD Vega 56 graphics card.
The VR headset plugs into a display port of the Vega56.
The amdgpu driver sees the connection, and tries to process it.
The problem is it cannot process the EDID, so fails to recognise the
VR headset, and the VR headset does not work as a result.
Please find the EDID below.
I am guessing that the following is causing the problem:
Established Timings I & II: none
Standard Timings: none
Forcing the driver to understand the Detailed mode, to which it is failing.
If it helps, when attached to windows 10, it uses 1440x2560, portrait mode.
Some dmesg lines that may be useful:
// We should pick 1440x2560 as Windows picks that, but for some reason
is rejects it with error 10.
[10402.650734] [drm:create_validate_stream_for_sink [amdgpu]] Mode
1440x2560 (clk 571570) failed DC validation with error 10 (No DP link
bandwidth)
[10402.650991] [drm:update_stream_scaling_settings [amdgpu]]
Destination Rectangle x:0 y:0 width:1440 height:2560
[10402.651225] [drm:create_validate_stream_for_sink [amdgpu]] Mode
1440x2560 (clk 571570) failed DC validation with error 10 (No DP link
bandwidth)
Can anyone help give me with some pointers as to how to get the amdgpu
driver to accept this EDID?
edid-decode (hex):
00 ff ff ff ff ff ff 00 3e d2 12 00 00 00 00 00
01 1d 01 04 a5 00 00 00 0e 00 00 00 00 00 00 00
00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 45 df a0 38 51 00 ee a5 d2 0c
f1 0c 00 00 00 00 00 10 00 00 00 ff 00 31 57 4d
47 48 35 32 30 47 41 39 35 32 00 00 00 fc 00 52
69 66 74 20 53 0a 20 20 20 20 20 20 00 00 00 10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33
----------------
EDID version: 1.4
Manufacturer: OVR Model 18 Serial Number 0
Made in week 1 of 2019
Digital display
8 bits per primary color channel
DisplayPort interface
Image size is variable
Gamma: 1.00
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
Default (sRGB) color space is primary color space
First detailed timing includes the native pixel format and preferred
refresh rate
Color Characteristics
Red: 0.0000, 0.0000
Green: 0.0000, 0.0000
Blue: 0.0000, 0.0000
White: 0.0000, 0.0000
Established Timings I & II: none
Standard Timings: none
Detailed mode: Clock 571.570 MHz, digital composite
1440 1650 1662 1752 (210 12 90)
2560 2623 2624 4078 ( 63 1 1454)
-hsync
VertFreq: 80.000 Hz, HorFreq: 326.239 kHz
Display Product Serial Number: 1WMGH520GA952
Display Product Name: Rift S
Dummy Descriptor
Checksum: 0x33
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Vega 56 failing to process EDID from VR Headset
2022-04-11 21:39 Vega 56 failing to process EDID from VR Headset James Dutton
@ 2022-04-12 6:13 ` Paul Menzel
2022-04-12 22:13 ` James Dutton
0 siblings, 1 reply; 6+ messages in thread
From: Paul Menzel @ 2022-04-12 6:13 UTC (permalink / raw)
To: James Dutton; +Cc: amd-gfx
Dear James,
Am 11.04.22 um 23:39 schrieb James Dutton:
> I have an Oculus Rift S, that I am trying to get working in Linux.
Please always mention the Linux kernel version.
> I have an AMD Vega 56 graphics card.
>
> The VR headset plugs into a display port of the Vega56.
> The amdgpu driver sees the connection, and tries to process it.
> The problem is it cannot process the EDID, so fails to recognise the
> VR headset, and the VR headset does not work as a result.
> Please find the EDID below.
> I am guessing that the following is causing the problem:
> Established Timings I & II: none
> Standard Timings: none
> Forcing the driver to understand the Detailed mode, to which it is failing.
> If it helps, when attached to windows 10, it uses 1440x2560, portrait mode.
> Some dmesg lines that may be useful:
> // We should pick 1440x2560 as Windows picks that, but for some reason
> is rejects it with error 10.
> [10402.650734] [drm:create_validate_stream_for_sink [amdgpu]] Mode
> 1440x2560 (clk 571570) failed DC validation with error 10 (No DP link
> bandwidth)
> [10402.650991] [drm:update_stream_scaling_settings [amdgpu]]
> Destination Rectangle x:0 y:0 width:1440 height:2560
> [10402.651225] [drm:create_validate_stream_for_sink [amdgpu]] Mode
> 1440x2560 (clk 571570) failed DC validation with error 10 (No DP link
> bandwidth)
(Please use an email program, which does not wrap lines after 72
characters.)
> Can anyone help give me with some pointers as to how to get the amdgpu
> driver to accept this EDID?
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.
Kind regards,
Paul
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Vega 56 failing to process EDID from VR Headset
2022-04-12 6:13 ` Paul Menzel
@ 2022-04-12 22:13 ` James Dutton
2022-04-13 7:11 ` Paul Menzel
0 siblings, 1 reply; 6+ messages in thread
From: James Dutton @ 2022-04-12 22:13 UTC (permalink / raw)
To: Paul Menzel; +Cc: amd-gfx
On Tue, 12 Apr 2022 at 07:13, Paul Menzel <pmenzel@molgen.mpg.de> 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.
>
>
> Kind regards,
>
> Paul
>
>
> 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/
Hi,
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.
My understanding is that it is supposed to start low, and then
gradually increases the driven levels until it gets CR.
Another aspect of the driver that I think could be improved could be
it keeping link state of the various interfaces separate.
1) Link up/down status on the signalling channel, where it gets EDID from.
2) Link up/down status on each of data Link 0,1,2,3. And what speeds
have been tested and work on each data Link, and what the "sink"
advertises as available.
At the moment, if anything goes wrong, it forgets all the information
it has and makes the kernel think it is disconnected. That makes it a
little difficult to diagnose where the problem is.
On other systems I have worked on, it has been useful to have the
EDID, even if the data links are all down.
Once I know more, I will put all the info in the issue track, as you suggest.
Kind Regards
James
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Vega 56 failing to process EDID from VR Headset
2022-04-12 22:13 ` James Dutton
@ 2022-04-13 7:11 ` Paul Menzel
2022-04-15 8:49 ` James Dutton
2022-04-15 15:03 ` James Dutton
0 siblings, 2 replies; 6+ messages in thread
From: Paul Menzel @ 2022-04-13 7:11 UTC (permalink / raw)
To: James Dutton; +Cc: amd-gfx
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Vega 56 failing to process EDID from VR Headset
2022-04-13 7:11 ` Paul Menzel
@ 2022-04-15 8:49 ` James Dutton
2022-04-15 15:03 ` James Dutton
1 sibling, 0 replies; 6+ messages in thread
From: James Dutton @ 2022-04-15 8:49 UTC (permalink / raw)
To: Paul Menzel; +Cc: amd-gfx
On Wed, 13 Apr 2022 at 08:11, Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> Dear James,
>
> > 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.
>
Just a small update. I have CR negotiation working now.
I have found out what I suspected. Although the amdgpu driver has code
in it that looks like CR negotiation is implemented, it does not
actually do any negotiation at all.
I still have some work to do, to also get EQ negotiation working.
Once I have a patch that is tidy enough, I will raise a bug request
and attach the patch to it.
I am just pleased that this is a software problem, and not my screen at fault.
Someone mentioned that the amdgpu driver is DP compliance tested
periodically. In short, I don't think any of those Link negotiation DP
compliance tests are actually valid, based on what I have found, so it
might be sensible for the person who runs the Link negotiation DP
compliance test suite to double check it is actually doing its job.
Summary: During CR negotiation, it only ever outputs a swing of 0,
and never 1,2 or 3 as it should.
So, my guess is only Screens on relatively short cables have ever
worked with the Linux amdgpu driver.
Although longer cables might work for some, it probably gets a bit hit
and miss for them.
Kind Regards
James
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Vega 56 failing to process EDID from VR Headset
2022-04-13 7:11 ` Paul Menzel
2022-04-15 8:49 ` James Dutton
@ 2022-04-15 15:03 ` James Dutton
1 sibling, 0 replies; 6+ messages in thread
From: James Dutton @ 2022-04-15 15:03 UTC (permalink / raw)
To: Paul Menzel; +Cc: amd-gfx
Hi,
I have raised a bug:
https://gitlab.freedesktop.org/drm/amd/-/issues/1975
I have also attached a patch to the bug, that fixes the CR negotiation problem.
My Oculus Rift S headset now works, with the included patch.
The patch fixes DP CR and EQ negotiation.
Kind Regards
James
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-04-15 15:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-11 21:39 Vega 56 failing to process EDID from VR Headset James Dutton
2022-04-12 6:13 ` Paul Menzel
2022-04-12 22:13 ` James Dutton
2022-04-13 7:11 ` Paul Menzel
2022-04-15 8:49 ` James Dutton
2022-04-15 15:03 ` James Dutton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.