From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
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 [thread overview]
Message-ID: <20131122232634.GM10036@intel.com> (raw)
In-Reply-To: <20131122152108.411c588e@jbarnes-desktop>
On Fri, Nov 22, 2013 at 03:21:08PM -0800, Jesse Barnes wrote:
> On Sat, 23 Nov 2013 01:08:17 +0200
> Ville Syrjälä <ville.syrjala@linux.intel.com> 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älä <ville.syrjala@linux.intel.com> 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 = 32;
> > > > > + break;
> > > > > + }
> > > >
> > > > Maybe just intel_format_to_fourcc()+drm_format_plane_cpp() or something.
> > > > Just to avoid duplicating essentially the same code.
> > >
> > > Ah yeah, good idea, fixed.
> > >
> > > > > + val = I915_READ(HTOTAL(pipe));
> > > > > + plane_config->fb_width = (val & 0xffff) + 1;
> > > > > + val = I915_READ(VTOTAL(pipe));
> > > > > + plane_config->fb_height = (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äl
Intel OTC
next prev parent reply other threads:[~2013-11-22 23:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-13 18:20 BIOS fb wrapping Jesse Barnes
2013-11-13 18:20 ` [PATCH 1/5] drm/i915: make pitch_for_width take a tiled arg Jesse Barnes
2013-11-13 21:59 ` Chris Wilson
2013-11-13 22:06 ` Jesse Barnes
2013-11-13 18:20 ` [PATCH 2/5] drm/i915: retrieve current fb config into new plane_config structure at init Jesse Barnes
2013-11-13 22:10 ` Chris Wilson
2013-11-14 15:06 ` Chris Wilson
2013-11-14 16:09 ` Jesse Barnes
2013-11-20 13:10 ` Ville Syrjälä
2013-11-22 21:55 ` Jesse Barnes
2013-11-22 23:08 ` Ville Syrjälä
2013-11-22 23:21 ` Jesse Barnes
2013-11-22 23:26 ` Ville Syrjälä [this message]
2013-11-22 23:29 ` Jesse Barnes
2013-11-13 18:20 ` [PATCH 3/5] drm/i915: split fb allocation and initialization Jesse Barnes
2013-11-13 21:58 ` Chris Wilson
2013-11-13 18:20 ` [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon Jesse Barnes
2013-11-13 22:05 ` Bob Paauwe
2013-11-13 22:08 ` Jesse Barnes
2013-11-13 22:07 ` Chris Wilson
2013-11-13 22:11 ` Jesse Barnes
2013-11-13 18:20 ` [PATCH 5/5] drm/i915: don't memset the fb buffer Jesse Barnes
2013-11-13 21:56 ` Chris Wilson
2013-11-13 22:05 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131122232634.GM10036@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox