From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org,
Karthik B S <karthik.b.s@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Extend the async flip VT-d w/a to skl/bxt
Date: Mon, 4 Oct 2021 22:09:38 +0300 [thread overview]
Message-ID: <YVtRciGIj5WHoM5k@intel.com> (raw)
In-Reply-To: <20211004175000.GA366973@mdroper-desk1.amr.corp.intel.com>
On Mon, Oct 04, 2021 at 10:50:00AM -0700, Matt Roper wrote:
> On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > Looks like skl/bxt/derivatives also need the plane stride
> > > > stretch w/a when using async flips and VT-d is enabled, or
> > > > else we get corruption on screen. To my surprise this was
> > > > even documented in bspec, but only as a note on the
> > > > CHICHKEN_PIPESL register description rather than on the
> > > > w/a list.
> > > >
> > > > So very much the same thing as on HSW/BDW, except the bits
> > > > moved yet again.
> > >
> > > Bspec 7522 doesn't say anything about this requirement being tied to
> > > VT-d on these platforms. Should we drop the intel_vtd_active()
> > > condition to be safe?
> >
> > I think it's just an oversight in bspec. I read through the hsd and
> > IIRC it did specify that it's VT-d only. Also real life confirms
> > it. No problems whatsoever when VT-d is disabled.
>
> I notice there are additional bits that we should set to apply this
> workaround to planes 2, 3, and 4, but since i915 still artificially
> limits async flips to just the primary plane, only programming bits 1:0
> should be fine for now; we'll just need to remember to extend this
> workaround if we do start allowing async flips on other planes in the
> future.
Aye. gen8_de_pipe_flip_done_mask() is the other place where we
still hardcode this for plane 1 only. I think the rest of the code
I did end up making more or less plane agnostic already.
I was considering at least parametrizing the register defines but
then I got a nagging feeling that I once ran into some issues while
trying to stick non-constant numbers into REG_BIT & co. So I
decided to hardcode plane 1 for the moment.
>
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Thanks. Pushed.
--
Ville Syrjälä
Intel
prev parent reply other threads:[~2021-10-04 19:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 19:09 [Intel-gfx] [PATCH 1/2] drm/i915: Extend the async flip VT-d w/a to skl/bxt Ville Syrjala
2021-09-30 19:09 ` Ville Syrjala
2021-09-30 19:09 ` [Intel-gfx] [PATCH 2/2] drm/i195: Make the async flip VT-d workaround dynamic Ville Syrjala
2021-10-04 17:55 ` Matt Roper
2021-09-30 20:52 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Extend the async flip VT-d w/a to skl/bxt Patchwork
2021-09-30 21:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-01 2:40 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-10-01 21:08 ` [Intel-gfx] [PATCH 1/2] " Matt Roper
2021-10-01 22:01 ` Ville Syrjälä
2021-10-01 22:17 ` Ville Syrjälä
2021-10-04 17:50 ` Matt Roper
2021-10-04 19:09 ` Ville Syrjälä [this message]
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=YVtRciGIj5WHoM5k@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=karthik.b.s@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.