From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 2/5] drm/i915: retrieve current fb config into new plane_config structure at init Date: Sat, 23 Nov 2013 01:26:34 +0200 Message-ID: <20131122232634.GM10036@intel.com> References: <1384366848-845-1-git-send-email-jbarnes@virtuousgeek.org> <1384366848-845-3-git-send-email-jbarnes@virtuousgeek.org> <20131120131039.GY7819@intel.com> <20131122135535.2f5733d6@jbarnes-desktop> <20131122230817.GL10036@intel.com> <20131122152108.411c588e@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id C72C6FB4BF for ; Fri, 22 Nov 2013 15:26:39 -0800 (PST) Content-Disposition: inline In-Reply-To: <20131122152108.411c588e@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Nov 22, 2013 at 03:21:08PM -0800, Jesse Barnes wrote: > On Sat, 23 Nov 2013 01:08:17 +0200 > Ville Syrj=E4l=E4 wrote: > = > > On Fri, Nov 22, 2013 at 01:55:35PM -0800, Jesse Barnes wrote: > > > On Wed, 20 Nov 2013 15:10:39 +0200 > > > Ville Syrj=E4l=E4 wrote: > > > > > + case DISPPLANE_8BPP: > > > > > + return DRM_FORMAT_C8; > > > > > + case DISPPLANE_BGRX555: > > > > > + return DRM_FORMAT_ARGB1555; > > > > ^ > > > > X > > > = > > > Oops fixed, thanks. These formats are a lot of typing. > > > = > > > > > + case DISPPLANE_RGBA888: > > > > > + case DISPPLANE_RGBX101010: > > > > > + case DISPPLANE_RGBA101010: > > > > > + case DISPPLANE_BGRX101010: > > > > > + plane_config->bpp =3D 32; > > > > > + break; > > > > > + } > > > > = > > > > Maybe just intel_format_to_fourcc()+drm_format_plane_cpp() or somet= hing. > > > > Just to avoid duplicating essentially the same code. > > > = > > > Ah yeah, good idea, fixed. > > > = > > > > > + val =3D I915_READ(HTOTAL(pipe)); > > > > > + plane_config->fb_width =3D (val & 0xffff) + 1; > > > > > + val =3D I915_READ(VTOTAL(pipe)); > > > > > + plane_config->fb_height =3D (val & 0xffff) + 1; > > > > = > > > > Why make the fb the size of htotal/vtotal? pipe src size should be = all > > > > we need. > > > = > > > Ok fixed. Are there no cases where they'll be different? Maybe > > > centered modes would have a pipesrc that differs from the > > > htotal/vtotal? But even in that case we just want the pipesrc. > > = > > htotal/vtotal should have nothing to do with the fb dimensions. > > pipesrc (or plane w/h if we had such registers for primary planes) > > are the only things we can really tell. The information whether > > the fb was orignally larger than that can't be recovered. > = > We couldn't get that from the scaling regs? If you're up or > downscaling, don't you have to specify a factor somewhere? Either in > the pfit regs or the sprite scaling regs? Scaling doesn't matter. Pipesrc defines the size of the viewport into the fb. Scaling regs would just tell us whether that gets up or downscaled by some amount. -- = Ville Syrj=E4l = Intel OTC