All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.