From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752341AbdEDNJT (ORCPT ); Thu, 4 May 2017 09:09:19 -0400 Received: from mga05.intel.com ([192.55.52.43]:51729 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752493AbdEDNJL (ORCPT ); Thu, 4 May 2017 09:09:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,287,1491289200"; d="scan'208";a="82451407" Date: Thu, 4 May 2017 16:08:56 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Daniel Vetter Cc: Jose Abreu , dri-devel , Linux Kernel Mailing List , Carlos Palminha , Alexey Brodkin , Dave Airlie Subject: Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback Message-ID: <20170504130856.GU12629@intel.com> References: <3e1dba0cd5fc053e56f1c9c94d0cb8789ecca4ae.1493203049.git.joabreu@synopsys.com> <20170502084807.k7ioo7a5j33xtnpj@phenom.ffwll.local> <80752cfe-4bc7-b7c6-c29b-e634c356a509@synopsys.com> <9edb415e-4d0b-5a2a-a735-0dbb98d77984@synopsys.com> <20170503150031.rpd5xs2bb67mpsnc@phenom.ffwll.local> <20170503152129.GO12629@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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ä > 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