On Tue, May 12, 2020 at 06:04:45PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 05:32:21PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > > > > On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > > > > > > On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > > > > > > > On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > > > > > > > > On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > > > > > > > > > On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > > > > > > > > > > Starting from TGL we need to have a separate wm0
> > > > > > > > > > > values for SAGV and non-SAGV which affects
> > > > > > > > > > > how calculations are done.
> > > > > > > > > > >
> > > > > > > > > > > v2: Remove long lines
> > > > > > > > > > > v3: Removed COLOR_PLANE enum references
> > > > > > > > > > > v4, v5, v6: Fixed rebase conflict
> > > > > > > > > > > v7: - Removed skl_plane_wm_level accessor from skl_allocate_pipe_ddb(Ville)
> > > > > > > > > > > - Removed sagv_uv_wm0(Ville)
> > > > > > > > > > > - can_sagv->use_sagv_wm(Ville)
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@xxxxxxxxx>
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 8 +-
> > > > > > > > > > > .../drm/i915/display/intel_display_types.h | 2 +
> > > > > > > > > > > drivers/gpu/drm/i915/intel_pm.c | 118 +++++++++++++++++-
> > > > > > > > > > > 3 files changed, 121 insertions(+), 7 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > > > > index fd6d63b03489..be5741cb7595 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > > > > > @@ -13961,7 +13961,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
> > > > > > > > > > > /* Watermarks */
> > > > > > > > > > > for (level = 0; level <= max_level; level++) {
> > > > > > > > > > > if (skl_wm_level_equals(&hw_plane_wm->wm[level],
> > > > > > > > > > > - &sw_plane_wm->wm[level]))
> > > > > > > > > > > + &sw_plane_wm->wm[level]) ||
> > > > > > > > > > > + (level == 0 && skl_wm_level_equals(&hw_plane_wm->wm[level],
> > > > > > > > > > > + &sw_plane_wm->sagv_wm0)))
> > > > > > > > > > > continue;
> > > > > > > > > > >
> > > > > > > > > > > drm_err(&dev_priv->drm,
> > > > > > > > > > > @@ -14016,7 +14018,9 @@ static void verify_wm_state(struct intel_crtc *crtc,
> > > > > > > > > > > /* Watermarks */
> > > > > > > > > > > for (level = 0; level <= max_level; level++) {
> > > > > > > > > > > if (skl_wm_level_equals(&hw_plane_wm->wm[level],
> > > > > > > > > > > - &sw_plane_wm->wm[level]))
> > > > > > > > > > > + &sw_plane_wm->wm[level]) ||
> > > > > > > > > > > + (level == 0 && skl_wm_level_equals(&hw_plane_wm->wm[level],
> > > > > > > > > > > + &sw_plane_wm->sagv_wm0)))
> > > > > > > > > > > continue;
> > > > > > > > > > >
> > > > > > > > > > > drm_err(&dev_priv->drm,
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > > > > > > index 9488449e4b94..8cede29c9562 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > > > > > > @@ -688,11 +688,13 @@ struct skl_plane_wm {
> > > > > > > > > > > struct skl_wm_level wm[8];
> > > > > > > > > > > struct skl_wm_level uv_wm[8];
> > > > > > > > > > > struct skl_wm_level trans_wm;
> > > > > > > > > > > + struct skl_wm_level sagv_wm0;
> > > > > > > > > > > bool is_planar;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > struct skl_pipe_wm {
> > > > > > > > > > > struct skl_plane_wm planes[I915_MAX_PLANES];
> > > > > > > > > > > + bool use_sagv_wm;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > enum vlv_wm_level {
> > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > > index db188efee21e..934a686342ad 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > > > > > > @@ -3863,25 +3863,35 @@ bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
> > > > > > > > > > > return bw_state->pipe_sagv_reject == 0;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > +static bool
> > > > > > > > > > > +tgl_crtc_can_enable_sagv(const struct intel_crtc_state *crtc_state);
> > > > > > > > > >
> > > > > > > > > > Just put the function here instead of adding fwd decalrations.
> > > > > > > > > >
> > > > > > > > > > > +
> > > > > > > > > > > static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > > > > {
> > > > > > > > > > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > > > > > > > > > int ret;
> > > > > > > > > > > struct intel_crtc *crtc;
> > > > > > > > > > > - const struct intel_crtc_state *new_crtc_state;
> > > > > > > > > > > + struct intel_crtc_state *new_crtc_state;
> > > > > > > > > > > struct intel_bw_state *new_bw_state = NULL;
> > > > > > > > > > > const struct intel_bw_state *old_bw_state = NULL;
> > > > > > > > > > > int i;
> > > > > > > > > > >
> > > > > > > > > > > for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > > > > > > new_crtc_state, i) {
> > > > > > > > > > > + bool can_sagv;
> > > > > > > > > > > +
> > > > > > > > > > > new_bw_state = intel_atomic_get_bw_state(state);
> > > > > > > > > > > if (IS_ERR(new_bw_state))
> > > > > > > > > > > return PTR_ERR(new_bw_state);
> > > > > > > > > > >
> > > > > > > > > > > old_bw_state = intel_atomic_get_old_bw_state(state);
> > > > > > > > > > >
> > > > > > > > > > > - if (skl_crtc_can_enable_sagv(new_crtc_state))
> > > > > > > > > > > + if (INTEL_GEN(dev_priv) >= 12)
> > > > > > > > > > > + can_sagv = tgl_crtc_can_enable_sagv(new_crtc_state);
> > > > > > > > > > > + else
> > > > > > > > > > > + can_sagv = skl_crtc_can_enable_sagv(new_crtc_state);
> > > > > > > > > > > +
> > > > > > > > > > > + if (can_sagv)
> > > > > > > > > > > new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
> > > > > > > > > > > else
> > > > > > > > > > > new_bw_state->pipe_sagv_reject |= BIT(crtc->pipe);
> > > > > > > > > > > @@ -3899,6 +3909,24 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
> > > > > > > > > > > return ret;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > + for_each_new_intel_crtc_in_state(state, crtc,
> > > > > > > > > > > + new_crtc_state, i) {
> > > > > > > > > > > + struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
> > > > > > > > > > > +
> > > > > > > > > > > + /*
> > > > > > > > > > > + * Due to drm limitation at commit state, when
> > > > > > > > > > > + * changes are written the whole atomic state is
> > > > > > > > > > > + * zeroed away => which prevents from using it,
> > > > > > > > > > > + * so just sticking it into pipe wm state for
> > > > > > > > > > > + * keeping it simple - anyway this is related to wm.
> > > > > > > > > > > + * Proper way in ideal universe would be of course not
> > > > > > > > > > > + * to lose parent atomic state object from child crtc_state,
> > > > > > > > > > > + * and stick to OOP programming principles, which had been
> > > > > > > > > > > + * scientifically proven to work.
> > > > > > > > > > > + */
> > > > > > > > > >
> > > > > > > > > > More ramblings. Just drop this comment too imo.
> > > > > > > > >
> > > > > > > > > As I understand what is happening here is rather weird, so I thought
> > > > > > > > > commenting is good idea.
> > > > > > > >
> > > > > > > > At least I have no idea what the comment is trying to say.
> > > > > > > > I see nothing weird hapening here, we're just computing the
> > > > > > > > state which is totally standard stuff.
> > > > > > >
> > > > > > > Well I can remind, this is because there is no way to get parent state
> > > > > > > from crtc_state, because of weird drm atomic behaviour which leaves us
> > > > > > > with NULL parent state. So that we had to stick this boolean to some
> > > > > > > place.
> > > > > > > In normal code universe this wouldn't even be needed if we could
> > > > > > > just get atomic state from crtc_state when we write wm in skl_write_plane_wm.
> > > > > >
> > > > > > Didn't get that at all from the comment. It talked about zeroing some
> > > > > > whole state which I took as 'memset(state, 0, sizeof(*state))'.
> > > > > > As that is not what's going on I just got confused by the comment.
> > > > > >
> > > > > > Now that I understand what this is about I think the comment
> > > > > > (if we want to have one) should probably say something more like:
> > > > > > "we store use_sagv_wm in the crtc state rather than relying on
> > > > > > the bw state since we have no convenient way to get at the
> > > > > > latter from the plane commit hooks (especially in the legacy
> > > > > > cursor case)".
> > > > > >
> > > > > > >
> > > > > > > However probably OOP principles like parent-child hieararchy is not a thing
> > > > > > > here. That what this comment was trying to say.
> > > > > > >
> > > > > > > In normal OOP you can't destroy parent object _before_ destroying
> > > > > > > child one.
> > > > > >
> > > > > > There's no parent-child relationship between the crtc state and atomic
> > > > > > state (which really shouldn't be called a state to begin with, rather
> > > > > > it should be "transaction" or something along those lines).
> > > > >
> > > > > In practice there is. crtc_state is being aggregated and contained as
> > > > > part of more general atomic state. That is exactly what parent-child
> > > > > object relation is.
> > > > > If you want to decouple those, this needs to be not aggregation but a reference,
> > > > > i.e atomic state would not contain those state objects, but have a pointer
> > > > > instead, but then you would not be using that container_of magic.
> > > >
> > > > Pointers is what it has. And once the atomic commit is done the
> > > > atomic_state (ie. the object used to track the single transaction)
> > > > goes away while the crtc/plane/etc. states remain behind.
> > >
> > > If the rest of states are independent there should be sane way
> > > to get those without the atomic state.
> >
> > How could you possibly get the right one without specifying
> > which transaction you want them for?
>
> Then if we still need those in skl_write_plane_wm or somewhere else during commit,
> transaction should not go away yet.
IMO those backpointers shouldn't perhaps exist at all and instead we
should just plumb the atomic state through everywhere. But you tried
that and it kinda failed thanks to the legacy cursor hacks, so here
we are.
>
> Otherwise there is a logical contraversy: we need those objects, but can't get
> them without transaction. But transaction still goes away,
> because it's kinda "separate".
It's a pre-existing issue with the atomic core/helpers. Changing
that is a lot of work, as we discused before a few times.
>
> Stan
>
> >
> > >
> > > Currently bw_state, cdclk_state and co - all can be retrieved only
> > > using atomic state, which is at some point "gone".
> > > Also it is actually not even gone, we just zero out a pointer
> > > to it in drm_crtc_state.
> > >
> > > I know why this done as we discussed, however I would
> > > emphasize that the proper way would be then
> > > to completely decouple from it, so that all required states can
> > > be retrieved without atomic state. Because currently we are
> > > kind of in some "fuzzy" state in between.
> > >
> > > Stan
> > >
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
