Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Carlos Palminha <CARLOS.PALMINHA@synopsys.com>,
	Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	Dave Airlie <airlied@linux.ie>
Subject: Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
Date: Thu, 4 May 2017 16:08:56 +0300	[thread overview]
Message-ID: <20170504130856.GU12629@intel.com> (raw)
In-Reply-To: <CAKMK7uFy3MMGusPtS=Jd1W9+_h8Do2+dnN5S3m9SjUF_=0E-=w@mail.gmail.com>

On Thu, May 04, 2017 at 02:49:31PM +0200, Daniel Vetter wrote:
> On Wed, May 3, 2017 at 5:21 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > We don't actually want the codepaths to match exactly. In i915
> > we allow the user to exceed some of the display/dongle limits
> > because those things often tell us that something shouldn't work
> > when in fact it does. And some users are quick to complain if
> > something stops working for them.
> 
> The goal here is to share the source-side checking
> (crtc/encoder/bridges), and that should match perfectly between probe
> and commit. Sink-side constraints are different, and for those we
> should indeed not check everything. Maybe a good reason to only call
> connector->mode_valid in the probe paths?

I thought you wanted to call it from both. But I guess if we
have a .mode_valid() hook on the encoder as well to handle
the source port limits then it could work out.

Ddi encoders might cause a problem though since we have to know
whether we're going to do DP or HDMI before we check the limits,
so it would need to be done after we've figured out output_types
or else we'll need to duplicate some logic to determine which
case we're dealing with.

-- 
Ville Syrjälä
Intel OTC