similar to: [PATCH v2 1/2] disp: activate dual link TMDS links only when possible

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actual possible. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de> Signed-off-by: Ilia

On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 11/04/2015 08:41 AM, Ilia Mirkin wrote: >> From: Hauke Mehrtens <hauke at hauke-m.de> >> >> Without this patch a pixel clock rate above 165 MHz on a TMDS link is >> assumed to be dual link. This is true for DVI, but not for HDMI. HDMI >> supports no dual link, but it supports

On 11/04/2015 08:41 AM, Ilia Mirkin wrote: > From: Hauke Mehrtens <hauke at hauke-m.de> > > Without this patch a pixel clock rate above 165 MHz on a TMDS link is > assumed to be dual link. This is true for DVI, but not for HDMI. HDMI > supports no dual link, but it supports pixel clock rates above 165 MHz. > Only activate Dual Link mode when it is actual possible. >

This is the beginnings of HDMI 2.0 support. All of the "extra" features are left out, such as 12/16bpc, YUV420, etc. I've verified that with this code, a GP108 (GT1030) can switch between 4k at 60 and 1920x1080 at 60 on a LG 4K TV. Further, I've verified via i2c tools, that the SCDC writes really do happen. I suspect that the patch for keeping track of the high-speed TMDS

Prefer the parsed results for is_hdmi and has_audio in display info over calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(), respectively. Conveniently, this also removes the need to use edid_blob_ptr. Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: Danilo Krummrich <dakr at redhat.com> Cc: nouveau at lists.freedesktop.org

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

On Fri, Jan 12, 2024 at 11:50?AM Jani Nikula <jani.nikula at intel.com> wrote: > > Prefer the parsed results for is_hdmi and has_audio in display info over > calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(), > respectively. > > Conveniently, this also removes the need to use edid_blob_ptr. > > Cc: Karol Herbst <kherbst at redhat.com> > Cc:

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware

This is mainly for dropping interlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/dispnv50/disp.c | 5 +++++ > drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >

THIS IS UNTESTED for anything other than i915. Use previously parsed EDID where possible for display audio/hdmi detection. This in turn reduces edid_blob_ptr usage in a number of places. Further reduce edid_blob_ptr usage, and document that it should not be used by drivers directly. BR, Jani. Cc: Alain Volmat <alain.volmat at foss.st.com> Cc: Alex Deucher <alexander.deucher at

This removes user control to force a hdmimhz. Given the vast variety of hardware and display configurations out there, I don't see how a patch like this won't blow up in our faces. I'm not saying we shouldn't do it -- we should attempt to respect the various maximums in the vbios, but until we get a solid handle on things, we should allow more user-configurability, not less, for

Just a backport of the two patches for v5.9 that you'll want to apply. The first one was Cc'd to stable, but I forgot to Cc the second one as well. Lyude Paul (2): drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid() drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++---------------

v2: clean up left over comments don't overwrite hdmimhz parameter cap to 297MHz Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/dispnv50/disp.c | 5 +++++ drm/nouveau/nouveau_connector.c | 15 ++++++++++----- drm/nouveau/nouveau_encoder.h | 4 ++++ 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/dispnv50/disp.c

On Fri, Aug 3, 2018 at 4:08 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: >> v2: clean up left over comments >> don't overwrite hdmimhz parameter >> cap to 297MHz >> >> Signed-off-by: Karol Herbst <kherbst at redhat.com> >> --- >>

Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/dispnv50/disp.c | 5 +++++ drm/nouveau/nouveau_connector.c | 5 +++++ drm/nouveau/nouveau_encoder.h | 4 ++++ 3 files changed, 14 insertions(+) diff --git a/drm/nouveau/dispnv50/disp.c b/drm/nouveau/dispnv50/disp.c index 6f41a6a0..3a960664 100644 --- a/drm/nouveau/dispnv50/disp.c +++ b/drm/nouveau/dispnv50/disp.c @@

https://bugs.freedesktop.org/show_bug.cgi?id=40747 Summary: The new nouveau kernel module fails to use my monitor's native resolution Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place.