search for: max_clock

While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the minimum possible bpc here, not the reported bpc from the connector. See: https://lists.freed...

...00, Ville Syrj?l? wrote: > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > While I thought I had this correct (since it actually did reject modes > > like I expected during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refers to the max symbol > > rate supported by the encoder, so limiting clock to ds_clock using max() > > doesn't make sense. Additionally, we want to check against 6bpc for the > > time being since that's the minimum possible bpc here, not the reported > > bpc from...

.../nouveau/nouveau_connector.c @@ -1023,29 +1023,6 @@ get_tmds_link_bandwidth(struct drm_connector *connector) return 112000 * duallink_scale; } -enum drm_mode_status -nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode, - const unsigned min_clock, - const unsigned max_clock, - unsigned int *clock_out) -{ - unsigned int clock = mode->clock; - - if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == - DRM_MODE_FLAG_3D_FRAME_PACKING) - clock *= 2; - - if (clock < min_clock) - return MODE_CLOCK_LOW; - if (clock > max_clock) - return MODE_CLOCK_HIGH; -...

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 ++++++---------------

On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > While I thought I had this correct (since it actually did reject modes > like I expected during testing), Ville Syrjala from Intel pointed out > that the logic here isn't correct. max_clock refers to the max symbol > rate supported by the encoder, so limiting clock to ds_clock using max() > doesn't make sense. Additionally, we want to check against 6bpc for the > time being since that's the minimum possible bpc here, not the reported > bpc from the connector. See:...

...ote: > > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > > While I thought I had this correct (since it actually did reject modes > > > like I expected during testing), Ville Syrjala from Intel pointed out > > > that the logic here isn't correct. max_clock refers to the max symbol > > > rate supported by the encoder, so limiting clock to ds_clock using max() > > > doesn't make sense. Additionally, we want to check against 6bpc for the > > > time being since that's the minimum possible bpc here, not the reported >...

...and otherwise use 8? On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul <lyude at redhat.com> wrote: > > While I thought I had this correct (since it actually did reject modes > like I expected during testing), Ville Syrjala from Intel pointed out > that the logic here isn't correct. max_clock refers to the max symbol > rate supported by the encoder, so limiting clock to ds_clock using max() > doesn't make sense. Additionally, we want to check against 6bpc for the > time being since that's the minimum possible bpc here, not the reported > bpc from the connector. See:...

...quot;nouveau_display.h" @@ -1033,6 +1034,24 @@ get_tmds_link_bandwidth(struct drm_connector *connector) return 112000 * duallink_scale; } +enum drm_mode_status +nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode, + const unsigned min_clock, + const unsigned max_clock, + unsigned *clock) +{ + if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == + DRM_MODE_FLAG_3D_FRAME_PACKING) + *clock *= 2; + + if (*clock < min_clock) + return MODE_CLOCK_LOW; + if (*clock > max_clock) + return MODE_CLOCK_HIGH; + + return MODE_OK; +} + static enum drm_mode_...

...cted; + return connector_status_connected; } @@ -176,8 +181,6 @@ void nouveau_dp_irq(struct nouveau_drm *drm, /* TODO: * - Use the minimum possible BPC here, once we add support for the max bpc * property. - * - Validate the mode against downstream port caps (see - * drm_dp_downstream_max_clock()) * - Validate against the DP caps advertised by the GPU (we don't check these * yet) */ @@ -188,15 +191,19 @@ nv50_dp_mode_valid(struct drm_connector *connector, unsigned *out_clock) { const unsigned min_clock = 25000; - unsigned max_clock, clock; + unsigned max_clock, ds_clo...

...> > On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul <lyude at redhat.com> wrote: > > While I thought I had this correct (since it actually did reject modes > > like I expected during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refers to the max symbol > > rate supported by the encoder, so limiting clock to ds_clock using max() > > doesn't make sense. Additionally, we want to check against 6bpc for the > > time being since that's the minimum possible bpc here, not the reported > > bpc from...

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

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 actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

...se DCB_OUTPUT_DP: > if (mode->flags & DRM_MODE_FLAG_INTERLACE && > - !nv_encoder->dp.caps.interlace) > + !nv_encoder->caps.dp_interlace) > return MODE_NO_INTERLACE; > > max_clock = nv_encoder->dp.link_nr; You probably meant for this hunk to go into an earlier patch. -ilia

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

...ector_mode_valid(struct drm_connector *connector, case DCB_OUTPUT_TV: return get_slave_funcs(encoder)->mode_valid(encoder, mode); case DCB_OUTPUT_DP: + if (mode->flags & DRM_MODE_FLAG_INTERLACE && + !nv_encoder->dp.caps.interlace) + return MODE_NO_INTERLACE; + max_clock = nv_encoder->dp.link_nr; max_clock *= nv_encoder->dp.link_bw; clock = clock * (connector->display_info.bpc * 3) / 10; diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h index 3517f920bf89..2a8a7aec48c4 100644 --- a/drivers/gpu/drm/nou...

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

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