public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Bainbridge <chris.bainbridge@gmail.com>,
	daniel.vetter@intel.com, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: disable non-sequential pfits on ivb/hsw
Date: Wed, 13 Jan 2016 18:43:37 +0200	[thread overview]
Message-ID: <20160113164337.GK23290@intel.com> (raw)
In-Reply-To: <20160113161415.GY19130@phenom.ffwll.local>

On Wed, Jan 13, 2016 at 05:14:15PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 05:13:31PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 13, 2016 at 02:33:47PM +0000, Chris Bainbridge wrote:
> > > The existing code assumes a sequential mapping of panel fitters to pipes
> > > (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> > > arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
> > > uses pfit 0 and pipe C for eDP1 when the firmware boots in a non-16:10
> > > resolution (the last-used resolution is stored in NVRAM by OS X so the
> > > firmware can immediately restore it at boot). When this happens, the
> > > display will appear letterboxed due to incorrect aspect ratio and
> > > attempting to switch to alternative resolutions will fail. Fix this by
> > > disabling any panel fitters which have been non-sequentially assigned at
> > > boot time.
> > > 
> > > Link: https://bugs.freedesktop.org/show_bug.cgi?id=93523
> > > Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 26 ++++++++++++++++++--------
> > >  1 file changed, 18 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 32cf97346978..9e588139a2dd 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -9170,6 +9170,24 @@ static void ironlake_get_pfit_config(struct intel_crtc *crtc,
> > 
> > get_config should never touch hw state, only read it out. The right place
> > to put fixup code is in sanitize_crtc. What we need in get_config would be
> > a check to make sure pfit is assigned to our pipe (and not take over the
> > state if so).
> 
> maybe even throw a new sanitize_pfit function in for clarity, since the
> problem is that pfit is _not_ associated with the crtc at a hw level.

Ideally we'd make the crtc<->pfit mapping flexible in the driver since
IIRC the first pfit could have special powers. But I guess it could be
a bit too much work for little gain. Although it shouldn't be too
different from the SKL scaler assignment stuff, so maybe not that much
work...

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-13 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 14:33 [PATCH] drm/i915: disable non-sequential pfits on ivb/hsw Chris Bainbridge
2016-01-13 16:13 ` Daniel Vetter
2016-01-13 16:14   ` Daniel Vetter
2016-01-13 16:43     ` Ville Syrjälä [this message]
2016-01-14  8:23 ` Jani Nikula

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=20160113164337.GK23290@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris.bainbridge@gmail.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.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