From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3.
Date: Fri, 21 Sep 2018 22:31:22 +0300 [thread overview]
Message-ID: <20180921193122.GL5565@intel.com> (raw)
In-Reply-To: <20180921183552.GH5565@intel.com>
On Fri, Sep 21, 2018 at 09:35:52PM +0300, Ville Syrjälä wrote:
> On Fri, Sep 21, 2018 at 07:39:40PM +0200, Maarten Lankhorst wrote:
> > To make NV12 working on icl, we need to update 2 planes simultaneously.
> > I've chosen to do this in the CRTC step after plane validation is done,
> > so we know what planes are (in)visible. The linked Y plane will get
> > updated in intel_plane_update_planes_on_crtc(), by the call to
> > update_slave, which gets the master's plane_state as argument.
> >
> > The link requires both planes for atomic_update to work,
> > so make sure skl_ddb_add_affected_planes() adds both states.
> >
> > Changes since v1:
> > - Introduce icl_is_nv12_y_plane(), instead of hardcoding sprite numbers.
> > - Put all the state updating login in intel_plane_atomic_check_with_state().
> > - Clean up changes in intel_plane_atomic_check().
> > Changes since v2:
> > - Fix intel_atomic_get_old_plane_state() to actually return old state.
> > - Move visibility changes to preparation patch.
> > - Only try to find a Y plane on gen11, earlier platforms only require a single plane.
> >
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >
> > fixup Y/UV Linkage
> >
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 106 ++++++++++++++++++----
> > drivers/gpu/drm/i915/intel_display.c | 57 ++++++++++++
> > drivers/gpu/drm/i915/intel_drv.h | 53 +++++++++++
> > drivers/gpu/drm/i915/intel_pm.c | 12 ++-
> > 4 files changed, 210 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index 984bc1f26625..522699085a59 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -121,7 +121,11 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_
> > crtc_state->nv12_planes &= ~BIT(intel_plane->id);
> > intel_state->base.visible = false;
> >
> > - /* If this is a cursor plane, no further checks are needed. */
> > + /* Destroy the link */
> > + intel_state->linked_plane = NULL;
> > + intel_state->slave = false;
> > +
> > + /* If this is a cursor or Y plane, no further checks are needed. */
> > if (!intel_state->base.crtc && !old_plane_state->base.crtc)
> > return 0;
> >
> > @@ -142,27 +146,76 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_
> > state);
> > }
> >
> > -static int intel_plane_atomic_check(struct drm_plane *plane,
> > - struct drm_plane_state *new_plane_state)
> > +static int intel_plane_atomic_check(struct drm_plane *drm_plane,
> > + struct drm_plane_state *new_drm_plane_state)
> > {
> > - struct drm_atomic_state *state = new_plane_state->state;
> > - const struct drm_plane_state *old_plane_state =
> > - drm_atomic_get_old_plane_state(state, plane);
> > - struct drm_crtc *crtc = new_plane_state->crtc ?: old_plane_state->crtc;
> > - const struct drm_crtc_state *old_crtc_state;
> > - struct drm_crtc_state *new_crtc_state;
> > -
> > - new_plane_state->visible = false;
> > + struct intel_atomic_state *state =
> > + to_intel_atomic_state(new_drm_plane_state->state);
> > + struct intel_plane *plane = to_intel_plane(drm_plane);
> > + const struct intel_plane_state *old_plane_state =
> > + intel_atomic_get_old_plane_state(state, plane);
> > + struct intel_plane_state *new_plane_state =
> > + to_intel_plane_state(new_drm_plane_state);
> > + struct intel_crtc *crtc = to_intel_crtc(
> > + new_plane_state->base.crtc ?:
> > + old_plane_state->base.crtc);
> > + const struct intel_crtc_state *old_crtc_state;
> > + struct intel_crtc_state *new_crtc_state;
> > + struct intel_plane *linked = old_plane_state->linked_plane;
> > + int ret;
> > + const struct intel_plane_state *old_linked_state;
> > + struct intel_plane_state *new_linked_state = NULL;
> > +
> > + if (linked) {
> > + /*
> > + * Make sure a previously linked plane (and implicitly, the CRTC)
> > + * is part of the atomic commit.
> > + */
> > + if (!intel_atomic_get_new_plane_state(state, linked)) {
> > + new_linked_state = intel_atomic_get_plane_state(state, linked);
> > + if (IS_ERR(new_linked_state))
> > + return PTR_ERR(new_linked_state);
> > + }
> > +
> > + old_linked_state =
> > + intel_atomic_get_old_plane_state(state, linked);
> > +
> > + /*
> > + * This will happen when we're the Y plane. In which case
> > + * old/new_state->crtc are both NULL. We still need to perform
> > + * updates on the linked plane.
> > + */
> > + if (!crtc)
> > + crtc = to_intel_crtc(old_linked_state->base.crtc);
> > +
> > + WARN_ON(!crtc);
> > + }
> > +
> > + new_plane_state->base.visible = false;
> > if (!crtc)
> > return 0;
> >
> > - old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
> > - new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> > + old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
> > + new_crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> > +
> > + if (new_linked_state &&
> > + drm_plane_index(&linked->base) < drm_plane_index(&plane->base)) {
> > + /*
> > + * This function is called from drm_atomic_helper_check_planes(), which
> > + * will normally check the newly added plane for us, but since we're
> > + * already in that function, it won't check the plane if our index
> > + * is bigger than the linked index because of the
> > + * for_each_oldnew_plane_in_state() call.
> > + */
> > + new_crtc_state->base.planes_changed = true;
> > + ret = intel_plane_atomic_check_with_state(old_crtc_state, new_crtc_state,
> > + old_linked_state, new_linked_state);
> > + if (ret)
> > + return ret;
> > + }
>
> This is all rather confusing. Can't we just do a preprocessing step
> before check_planes() to add the linked planes as needed, and then
> let the normal check_planes() do its thing?
Also one thing that slightly worries me is what happens if someone adds
more planes to the state after this has all been done. I guess
currently those cases would either come from the tail end of
intel_atomic_check() or from intel_crtc_atomic_check(). Currently it
would appear that wm/ddb is the only piece of code that can do this
sort of thing.
Some ideas how to solve it perhaps:
- Move the linked plane pointer to the core so that get_plane_state()
can immediately pick up both planes
- Add some kind of flag into the top level atomic state that after this
point no new planes. But I guess duplicate_state() is the only thing
we have and that doesn't know anything about the the top level state
- Live with it and tell everyone to be careful? Some kind of
intel_add_affected_planes() might be helpful here to at least give
people one thing to call in the late stages. Wouldn't help if the
call comes from some helper/core function though. And as there is
no use for such a function currently no point adding it I suppose.
The wm stuff has its own thing, which you covered already.
Dunno, maybe I'm just a bit too paranoid here.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-09-21 19:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 17:39 [PATCH 0/7] drm/i915/gen11: Enable planar format support on gen11 Maarten Lankhorst
2018-09-21 17:39 ` [PATCH 1/7] drm/i915/gen11: Enable 6 sprites " Maarten Lankhorst
2018-09-21 23:24 ` Matt Roper
2018-09-21 17:39 ` [PATCH 2/7] drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v3 Maarten Lankhorst
2018-09-21 18:35 ` Ville Syrjälä
2018-09-21 19:31 ` Ville Syrjälä [this message]
2018-09-24 12:35 ` Maarten Lankhorst
2018-09-24 13:18 ` Ville Syrjälä
2018-09-25 10:03 ` Maarten Lankhorst
2018-09-25 12:44 ` Ville Syrjälä
2018-09-25 18:01 ` Matt Roper
2018-09-25 18:34 ` Ville Syrjälä
2018-09-25 20:18 ` Matt Roper
2018-09-27 13:10 ` Ville Syrjälä
2018-09-21 23:25 ` Matt Roper
2018-09-21 17:39 ` [PATCH 3/7] drm/i915/gen11: Handle watermarks correctly for separate Y/UV planes Maarten Lankhorst
2018-09-26 22:02 ` Matt Roper
2018-09-21 17:39 ` [PATCH 4/7] drm/i915/gen11: Program the scalers correctly for planar formats Maarten Lankhorst
2018-09-21 18:45 ` Ville Syrjälä
2018-09-24 8:39 ` Maarten Lankhorst
2018-09-24 13:10 ` Ville Syrjälä
2018-09-27 0:16 ` Matt Roper
2018-09-27 13:08 ` Ville Syrjälä
2018-09-21 17:39 ` [PATCH 5/7] drm/i915/gen11: Program the chroma upsampler for HDR planes Maarten Lankhorst
2018-09-21 18:53 ` Ville Syrjälä
2018-09-24 8:38 ` Maarten Lankhorst
2018-09-24 13:09 ` Ville Syrjälä
2018-09-21 17:39 ` [PATCH 6/7] drm/i915/gen11: Program the Y and UV plane for planar mode correctly Maarten Lankhorst
2018-09-21 19:01 ` Ville Syrjälä
2018-09-22 9:37 ` Maarten Lankhorst
2018-09-21 17:39 ` [PATCH 7/7] drm/i915/gen11: Expose planar format support on gen11 Maarten Lankhorst
2018-09-21 18:17 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gen11: Enable " Patchwork
2018-09-21 18:40 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-21 20:29 ` ✓ Fi.CI.IGT: " 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=20180921193122.GL5565@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).