search for: drm_detect_hdmi_monitor

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 Signed-off-...

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

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: Lyude Paul <lyude at redhat.com> > Cc: Danilo Krummrich <dakr at redhat.com> > Cc: nouvea...

...v50_display.c @@ -773,7 +773,6 @@ nv50_crtc_set_scale(struct nouveau_crtc *nv_crtc, bool update) */ if (nv_connector && ( nv_connector->underscan == UNDERSCAN_ON || (nv_connector->underscan == UNDERSCAN_AUTO && - nv_connector->edid && drm_detect_hdmi_monitor(nv_connector->edid)))) { u32 bX = nv_connector->underscan_hborder; u32 bY = nv_connector->underscan_vborder; -- 2.4.10

I've sent this some moths ago, let's try again... BR, Jani. Jani Nikula (6): drm/nouveau: convert to using is_hdmi and has_audio from display info drm/radeon: convert to using is_hdmi and has_audio from display info drm/radeon: remove radeon_connector_edid() and stop using edid_blob_ptr drm/amdgpu: remove amdgpu_connector_edid() and stop using edid_blob_ptr drm/edid:

...Only enable dual-link if: + * - Need to (i.e. rate > 165MHz) + * - DCB says we can + * - Not an HDMI monitor, since there's no dual-link + * on HDMI. + */ + if (mode->clock >= 165000 && + nv_encoder->dcb->duallink_possible && + !drm_detect_hdmi_monitor(nv_connector->edid)) + proto |= 0x4; } else { proto = 0x2; } diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c index 186fd3a..f031466 100644 --- a/drm/nouveau/nvkm/engine/disp/gf119.c +++ b/drm/nouveau/nvkm/engine/disp/gf119.c @@ -158,7 +158,7...

...dual-link + * on HDMI. Of course in order to determine that, + * we need the EDID. So if no EDID, just let it + * slide. + */ + if (mode->clock >= 165000 && + nv_encoder->dcb->duallink_possible && + (!nv_connector->edid || + !drm_detect_hdmi_monitor(nv_connector->edid))) + proto |= 0x4; } else { proto = 0x2; } diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c b/drm/nouveau/nvkm/engine/disp/gf119.c index 186fd3a..f031466 100644 --- a/drm/nouveau/nvkm/engine/disp/gf119.c +++ b/drm/nouveau/nvkm/engine/disp/gf119.c @@ -158,7 +158,7...

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

...io(nv_connector->edid)) return; @@ -810,7 +808,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_atomic_state *state, int ret; int size; - nv_connector = nv50_outp_get_new_connector(nv_encoder, state); + nv_connector = nv50_outp_get_new_connector(state, nv_encoder); if (!drm_detect_hdmi_monitor(nv_connector->edid)) return; @@ -1616,8 +1614,7 @@ nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state *st { struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder); struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc); - struct nouveau_connec...

...rm_encoder *encoder, struct drm_display_mode *mode) }; struct nouveau_connector *nv_connector; u32 max_ac_packet; + union hdmi_infoframe avi_frame; + union hdmi_infoframe vendor_frame; + int ret; + int size; + int frame = 0; nv_connector = nouveau_encoder_connector_get(nv_encoder); if (!drm_detect_hdmi_monitor(nv_connector->edid)) return; + /* Audio InfoFrame apparently not required (supplied by HDA device?) */ + + ret = drm_hdmi_avi_infoframe_from_display_mode(&avi_frame.avi, mode); + if (ret >= 0) { + /* We have an AVI InfoFrame, populate it to the display */ + args.pwr.flags |= NV50_D...

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

...ctor *nv_connector; struct drm_hdmi_info *hdmi; u32 max_ac_packet; union hdmi_infoframe avi_frame; @@ -808,7 +822,6 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_atomic_state *state, int ret; int size; - nv_connector = nv50_outp_get_new_connector(state, nv_encoder); if (!drm_detect_hdmi_monitor(nv_connector->edid)) return; @@ -854,7 +867,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_atomic_state *state, + args.pwr.vendor_infoframe_length; nvif_mthd(&disp->disp->object, 0, &args, size); - nv50_audio_enable(encoder, state, mode); + nv50_audio_ena...

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

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

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

...coder *nv_encoder = nouveau_encoder(encoder); @@ -752,7 +803,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_display_mode *mode) int ret; int size; - nv_connector = nouveau_encoder_connector_get(nv_encoder); + nv_connector = nv50_outp_get_new_connector(nv_encoder, state); if (!drm_detect_hdmi_monitor(nv_connector->edid)) return; @@ -798,7 +849,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_display_mode *mode) + args.pwr.vendor_infoframe_length; nvif_mthd(&disp->disp->object, 0, &args, size); - nv50_audio_enable(encoder, mode); + nv50_audio_enable(enco...

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

This is an initial implementation of HDMI 3D mode support for the nouveau kernel driver. It works on all of the hardware that I have available to test at the moment, but I am unsure as to the overall approach taken for setting HDMI InfoFrames, there's no support for g84 or gf119 disps, and the criteria for enabling stereo support for an output seems a bit iffy. The first four patches arrange

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

Hello, This is an attempt at providing generic support for underscan connector props. We already have 3 drivers defining the same underscan, underscan vborder and underscan hborder properties (amd, radeon and nouveau) and I am about to add a new one, hence my proposal to put the prop parsing code in the core and add ->underscan fields to drm_connector_state. In this v2, I also converted the