Re: [Intel-gfx] [PATCH v2] drm/edid: Fix csync detailed mode parsing

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Mar 01, 2023 at 10:49:26AM +0200, Jani Nikula wrote:
> On Tue, 28 Feb 2023, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Remove the bogus csync check and replace it with something that:
> > - triggers for all forms of csync, not just the basic analog variant
> > - actually populates the mode csync flags so that drivers can
> >   decide what to do with the mode
> >
> > Originally the code tried to outright reject csync, but that
> > apparently broke some bogus LCD monitor that claimed to have
> > a detailed mode that uses analog csync, despite also claiming
> > the monitor only support separate sync:
> > https://bugzilla.redhat.com/show_bug.cgi?id=540024
> > Potentially that monitor should just be quirked or something.
> >
> > Anyways, what we are dealing with now is some kind of funny i915
> > JSL machine with eDP where the panel claims to support a sensible
> > 60Hz separate sync mode, and a 50Hz mode with bipolar analog
> > csync. The 50Hz mode does not work so we want to not use it.
> > Easiest way is to just correctly flag it as csync and the driver
> > will reject it.
> >
> > TODO: or should we just reject any form of csync (or at least
> > the analog variants) for digital display interfaces?
> >
> > v2: Grab digital csync polarity from hsync polarity bit (Jani)
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
> > Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
> 
> Yup. Fingers crossed.

Thought it best to give this plenty of time to soak, so pushed
to drm-misc-next. Thanks for the review.

-- 
Ville Syrjälä
Intel