All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix cursor updates on some platforms
Date: Fri, 14 Jul 2017 19:34:15 +0300	[thread overview]
Message-ID: <20170714163415.GM12629@intel.com> (raw)
In-Reply-To: <150004944385.13756.16004344387543482092@mail.alporthouse.com>

On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote:
> Quoting ville.syrjala@linux.intel.com (2017-07-14 16:52:27)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Turns out that just writing CURPOS isn't sufficient to move the cursor
> > on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
> > On those platforms we need to arm even the CURPOS update with a
> > CURBASE write.
> > 
> > Even worse, a write to any of the cursor register apart from CURBASE
> > will cancel an already pending cursor update. So if we have armed a
> > CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
> > would cancel that armed update. Thus we're left with a cursor that
> > doesn't appear to move, or even change shape.
> > 
> > Fix the problem by always performing the CURBASE write after a
> > CURPOS write. Bspec is somewhat unclear which platforms actually
> > require this CURBASE write and which don't. So to keep it simple
> > and to make sure we really fix the problem across all supported
> > devices, let's just perform the CURBASE write unconditionally.
> 
> Hmm, it seems that kms_cursor_crc should catch this? I guess we are
> missing a move N times quickly test?

Yeah. I guess what we have is basically this:
1. enable cursor at some location
2. wait for vblank and grab the crc
3. disable cursor and render the cursor image to the primary plane fb
4. wait for vblank and grab the crc

I guess what we could do is make step 1 enable the cursor at an
incorrect location, and then perform a few extra cursor movements,
ending in the correct location, before we grab the crc.

> We have CRC support on pnv right?

We should have it across the board.

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

  reply	other threads:[~2017-07-14 16:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14 15:52 [PATCH] drm/i915: Fix cursor updates on some platforms ville.syrjala
2017-07-14 16:09 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-07-14 16:24 ` [PATCH] " Chris Wilson
2017-07-14 16:34   ` Ville Syrjälä [this message]
2017-07-14 20:39     ` Ville Syrjälä
2017-07-17 10:42 ` Paul Menzel
2017-07-18 10:08   ` Daniel Vetter

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=20170714163415.GM12629@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=pmenzel@molgen.mpg.de \
    /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.