From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Petri Latvala <petri.latvala@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 3/4] lib/kms: Commit primary plane props with COMMIT_LEGACY
Date: Tue, 20 Apr 2021 11:04:03 +0300 [thread overview]
Message-ID: <YH6K8yy6ZUb448NG@intel.com> (raw)
In-Reply-To: <YH6GB4Lw4wtHwDuM@platvala-desk.ger.corp.intel.com>
On Tue, Apr 20, 2021 at 10:43:03AM +0300, Petri Latvala wrote:
> On Fri, Apr 16, 2021 at 08:48:40PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Currently COMMIT_LEGACY for the primary plane only issues the
> > setcrtc ioctl, leaving all other plane properties unchanged
> > even if they were flagged as needing an update. Let's issue
> > the appropriate setprop ioctls in addition to the setcrtc to
> > make sure the plane state really reflects what was requested.
> >
> > Without this the prop values can leak between tests. Eg. on
> > skl/derivatives running one of the failing kms_plane_alpha_blend
> > subtests first, and following it up with kms_cursor_crc (which
> > only uses legacy commits) causes crc mismatches since the
> > primary plane alpha is still left at some stale value despite
> > igt_plane_reset() trying to reset it back to 1.0.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The reasoning is sound and this seems to do what the commit message
> explains, but why does kms_flip_tiling fail consistently with it?
Dunno yet. Annoyingly it passes with flying color on my local glk.
--
Ville Syrjälä
Intel
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2021-04-20 8:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 17:48 [igt-dev] [PATCH i-g-t 0/4] Fix command line options and whatnot Ville Syrjala
2021-04-16 17:48 ` [igt-dev] [PATCH i-g-t 1/4] lib: Document that we have --trace-on-oops Ville Syrjala
2021-04-19 9:32 ` Petri Latvala
2021-04-16 17:48 ` [igt-dev] [PATCH i-g-t 2/4] lib: Fix option parsing Ville Syrjala
2021-04-19 9:33 ` Petri Latvala
2021-04-16 17:48 ` [igt-dev] [PATCH i-g-t 3/4] lib/kms: Commit primary plane props with COMMIT_LEGACY Ville Syrjala
2021-04-20 7:43 ` Petri Latvala
2021-04-20 8:04 ` Ville Syrjälä [this message]
2021-04-16 17:48 ` [igt-dev] [PATCH i-g-t 4/4] tests/kms_plane: Ignore the crc frame count with --skip-crc-compare Ville Syrjala
2021-04-20 7:41 ` Petri Latvala
2021-04-16 18:50 ` [igt-dev] ✓ Fi.CI.BAT: success for Fix command line options and whatnot Patchwork
2021-04-16 20:17 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2021-04-17 20:07 ` [igt-dev] ✓ Fi.CI.BAT: success for Fix command line options and whatnot (rev2) Patchwork
2021-04-17 21:08 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
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=YH6K8yy6ZUb448NG@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=petri.latvala@intel.com \
/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.