From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 6/6] drm/i915: New drm crtc property for varying the Crtc size Date: Thu, 14 Aug 2014 21:51:27 +0300 Message-ID: <20140814185127.GL4193@intel.com> References: <1408008267-11443-7-git-send-email-akash.goel@intel.com> <20140814144201.GS10500@phenom.ffwll.local> <20140814150658.GF4193@intel.com> <20140814152626.GV10500@phenom.ffwll.local> <20140814154533.GH4193@intel.com> <20140814164531.GI4193@intel.com> <20140814175816.GJ4193@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id C0ACC89E32 for ; Thu, 14 Aug 2014 11:56:25 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: "Kumar, Shobhit" , "akash.goel" , intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Thu, Aug 14, 2014 at 08:33:23PM +0200, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 7:58 PM, Ville Syrj=E4l=E4 > wrote: > > Sure but the user can supply any mode, doesn't have to be on any list. > > And the only sane rule for the frobbing would be that you can (slightly) > > reduce hdisp/vdisp but never expand them so that there will never be any > > extra garbage exposed (and the FB might not be big enough anyway). But > > even reducing hdisp/vdisp by one pixel can be enough to anger the > > hardware if a plane then extends one pixel into the blanking. > > > > This isn't much of a problem for i915 though. The hardware is generally > > good enough to not need it. Double wide and (s)dvo/lvds gang mode are > > the only exception that comes to mind. Even there we just need to make > > pipe src width even, but still that's something we have to account > > when clipping planes. > > > > On older hardware there were generally more restrictions eg. some > > legacy baggage from VGA days which required horizontal timings to > > be multiples of 8. I also "fondly" remember much more magic timing > > restrictions in certain pieces hardware which were something close > > to "if (foo*bar % this =3D=3D that) frob else don't". IMO these kinds of > > restrictions are too magic to make rejecting the mode an option, > > so frobbing is the lesser of two evils. > = > Imo the mode list we provide should be reasonable for everyone, and if > you start to add your own modes then I expect the user to do that > adjusting for us. Nowadays there should be very few cases where we > don't provide decent mode lists and where it's not a super-special > embedded thing where you need to configure everything yourself anyway. > So I don't think we should ever adjust the input region for a crtc. That's fine for decent hardware. But if/when I write a driver for old junk I'm probably going to frob no matter what anyone says :) -- = Ville Syrj=E4l=E4 Intel OTC