search for: ds_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.freedesktop.org/archives/dri-devel/2020-September/280276.html For more info. So, let'...

...t; 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.freedesktop.org/archives/dri-devel/2020-S...

...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: > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html >...

...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: > > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html >...

...ght 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.freedesktop.org/...

...ouveau_dp.c index 7b640e05bd4c..93e3751ad7f1 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -232,12 +232,14 @@ nv50_dp_mode_valid(struct drm_connector *connector, unsigned *out_clock) { const unsigned min_clock = 25000; - unsigned max_clock, ds_clock, clock; - enum drm_mode_status ret; + unsigned max_clock, ds_clock, clock = mode->clock; if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) return MODE_NO_INTERLACE; + if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKIN...

...t; 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.freedesktop.org/archives/dri-devel/2020-S...

..._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_clock, clock; enum drm_mode_status ret; if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace) return MODE_NO_INTERLACE; max_clock = outp->dp.link_nr * outp->dp.link_bw; - clock = mode->clock * (connector->display_info.bpc * 3) / 10; + ds_clock =...

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

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

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM