From: Daniel Vetter <daniel@ffwll.ch>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 3/3] kms_universal_plane: Universal plane testing
Date: Fri, 11 Apr 2014 13:57:33 +0200 [thread overview]
Message-ID: <20140411115733.GG9262@phenom.ffwll.local> (raw)
In-Reply-To: <20140411092239.GC9262@phenom.ffwll.local>
On Fri, Apr 11, 2014 at 11:22:39AM +0200, Daniel Vetter wrote:
> On Thu, Apr 10, 2014 at 05:26:25PM -0700, Matt Roper wrote:
> > Add a simple test to exercise universal plane support.
> >
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
>
> Looks like a good functional test, but I think we need to add a bit more
> api nastiness still. So no functional tests with CRCs, but just tests to
> make sure the kernel doesn't fall over.
>
> - primary plane set_plane calls vs. legacy setcrtc primary plane updates.
> We'll very likely have mixed userspace (e.g. boot splash vs. display
> manager). E.g. disable primary plane (but keep everything working), then
> setCrtc a new plane framebuffer.
>
> - primary plane vs. other ioctls. Might be easier to extend existing tests
> for this. E.g. doing a pageflip ioctl if the primary plane is off
> (might need to decide what we really want to do and if we decide that it
> should enable the primary plane then we need a CRC based test to make
> sure that the transition is perfect).
>
> Or primary plane changes vs. dpms and suspend/resume. For those
> functional checks based on CRC would be good to make sure we properly
> restore everything.
>
> - Maybe exercise some of the checks in the primary plane helper to make
> sure they work. In the future we'll probably lift those limitations (not
> on current hw afaik though), but then we can adjust those tests to skip
> on these platforms.
>
> - Anything else that was pointed out in review or was tricky while
> developing this stuff.
More ideas! My main concern is interactions with existing features when
the primary plane is disabled and no other plane/cursor enabled, i.e. when
we scan out a solid black.
- solid black vs. dpms for all connector/pipe pairings. The modeset
sequence is different for different connectors and my gut says not
enabling the primary plane might cause trouble.
- solid black vs. vblank events. When transition through a "no planes"
situation we need to make sure that vblank events keep on working. A
testcase (maybe in combination of some of the dpms and susped/resume
case above too) would be good.
I'll leave it to you to somewhat sensibly group all these ideas into real
testcases ;-) For further inspiration maybe look at the corner cases
existing kms_* tests exercise a bit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-04-11 11:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 0:24 [PATCH] drm/i915: Intel-specific primary plane handling (v2) Matt Roper
2014-04-11 0:26 ` [PATCH i-g-t 0/3] Universal plane testing Matt Roper
2014-04-11 0:26 ` [PATCH i-g-t 1/3] kms: Add universal plane support Matt Roper
2014-04-11 0:26 ` [PATCH i-g-t 2/3] kms_plane: Update for universal plane changes Matt Roper
2014-04-11 0:26 ` [PATCH i-g-t 3/3] kms_universal_plane: Universal plane testing Matt Roper
2014-04-11 9:22 ` Daniel Vetter
2014-04-11 11:57 ` Daniel Vetter [this message]
2014-04-11 9:34 ` [PATCH] drm/i915: Intel-specific primary plane handling (v2) Daniel Vetter
2014-04-11 14:17 ` Matt Roper
2014-04-11 14:23 ` Daniel Vetter
2014-04-11 17:41 ` Matt Roper
2014-04-11 18:27 ` Daniel Vetter
2014-04-11 20:44 ` [PATCH] drm/i915: Intel-specific primary plane handling (v3) Matt Roper
2014-04-11 21:13 ` [PATCH] drm/i915: Intel-specific primary plane handling (v4) Matt Roper
2014-04-22 12:47 ` Ville Syrjälä
2014-04-22 15:18 ` Matt Roper
2014-04-22 17:14 ` Daniel Vetter
2014-04-22 17:32 ` Matt Roper
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=20140411115733.GG9262@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@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.