On Fri, 2025-09-19 at 11:09 -0400, Alex Deucher wrote:
> On Fri, Sep 19, 2025 at 4:14 AM Timur Kristóf
> <[email protected]> wrote:
> >
> > Mark YUV422 unsupported over DP on DCE to work around a
> > regression caused by the recent YUV422 fallback patch.
> >
> > See https://gitlab.freedesktop.org/drm/amd/-/issues/4585
> >
> > The recent YUV422 fallback breaks DisplayPort on DCE6-10 because
> > it can select a high refresh rate mode with YUV422 and 6 BPC,
> > which is apparently not actually supported by the HW, causing
> > it to boot to a "no signal" screen.
> >
> > Tested with a Samsung Odyssey G7 on the following GPUs:
> >
> > - Cape Verde (DCE 6): affected
> > - Tonga (DCE 10): affected
> > - Polaris (DCE 11.2): not affected
> > - Vega (DCE 12): not affected
> >
> > Polaris and Vega are not affected because the same mode
> > gets rejected by other parts of the code base, possibly the
> > bandwidth calculation which exists for DCE11+ but not older HW.
> >
> > It is not documented whether YUV422 is actually supported over DP
> > on DCE, but considering that this encoding was never used before,
> > and that YUV420 is already marked unsupported, probably not.
> >
> > Signed-off-by: Timur Kristóf <[email protected]>
>
> Fixes: db291ed1732e02 ("drm/amd/display: Add fallback path for
> YCBCR422")
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4585
> Acked-by: Alex Deucher <[email protected]>
>
> Would be good to get feedback from the display team on what the
> actual
> capabilities are, but seems reasonable to me.
>
> Alex
Thanks Alex.
I prefer not to add the Closes tag, as this patch doesn't really
resolve the issue, it's just a workaround that I came up with until
someone who knows better can properly fix it.
The proper fix would be:
1. Determine which DCE and DCN versions actually support 422 over DP
and HDMI, and add new fields to the encoder capabilities:
dp_ycbcr422_supported
hdmi_ycbcr420_supported
(I didn't find this info anywhere publicly, but can I can help write
that patch if someone from AMD confirms which DCE/DCN versions support
422 and which don't.)
2. If it so happens that DCE actually supports 422 over DP, we should
determine why this mode doesn't work. (I suspect that it was rejected
on Polaris and Vega by the bandwidth calculation.)
3. If the current link encoder doesn't support 422 and/or 420, the code
should not even attempt to use them.
Thanks & best regards,
Timur
>
> > ---
> > drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> > b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> > index 0c50fe266c8a..686f6be68c91 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c
> > @@ -798,7 +798,8 @@ bool dce110_link_encoder_validate_dp_output(
> > const struct dce110_link_encoder *enc110,
> > const struct dc_crtc_timing *crtc_timing)
> > {
> > - if (crtc_timing->pixel_encoding == PIXEL_ENCODING_YCBCR420)
> > + if (crtc_timing->pixel_encoding == PIXEL_ENCODING_YCBCR420
> > ||
> > + crtc_timing->pixel_encoding ==
> > PIXEL_ENCODING_YCBCR422)
> > return false;
> >
> > return true;
> > --
> > 2.51.0
> >
