All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 13/17] drm/i915: Intrduce better global state handling
Date: Tue, 28 Jan 2020 14:44:04 +0000	[thread overview]
Message-ID: <cb61046b5a0238b6cf2bf4bd078d521ef8efde0d.camel@intel.com> (raw)
In-Reply-To: <20200120174728.21095-14-ville.syrjala@linux.intel.com>

On Mon, 2020-01-20 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Our current global state handling is pretty ad-hoc. Let's try to
> make it better by imitating the standard drm core private object
> approach.
> 
> The reason why we don't want to directly use the private objects
> is locking; Each private object has its own lock so if we
> introduce any global private objects we get serialized by that
> single lock across all pipes. The global state apporoach instead
> uses a read/write lock type of approach where each individual
> crtc lock counts as a read lock, and grabbing all the crtc locks
> allows one write access.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Looks like, I would prefer to get your global changes landed first
as you have almost all patches reviewed by now. Once those land, 
I will fetch those changes and use new global state handling in 
my SAGV patches.

> ---
>  drivers/gpu/drm/i915/Makefile                 |   1 +
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   7 +-
>  drivers/gpu/drm/i915/display/intel_atomic.h   |   4 +-
>  drivers/gpu/drm/i915/display/intel_audio.c    |   2 +-
>  drivers/gpu/drm/i915/display/intel_cdclk.c    |   8 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  15 +-
>  .../drm/i915/display/intel_display_types.h    |   4 +
>  .../gpu/drm/i915/display/intel_global_state.c | 223
> ++++++++++++++++++
>  .../gpu/drm/i915/display/intel_global_state.h |  87 +++++++
>  drivers/gpu/drm/i915/i915_drv.h               |   3 +
>  10 files changed, 342 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_global_state.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_global_state.h
> 
> 


> +
> +int intel_atomic_lock_global_state(struct intel_global_state
> *obj_state)
> +{
> +	struct intel_atomic_state *state = obj_state->state;
> +	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	struct intel_crtc *crtc;
> +
> +	for_each_intel_crtc(&dev_priv->drm, crtc) {
> +		int ret;
> +
> +		ret = drm_modeset_lock(&crtc->base.mutex,
> +				       state->base.acquire_ctx);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	obj_state->changed = true;
> +
> +	return 0;
> +}
> +
> +int intel_atomic_serialize_global_state(struct intel_global_state
> *obj_state)
> +{
> +	struct intel_atomic_state *state = obj_state->state;
> +	struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +	struct intel_crtc *crtc;
> +
> +	for_each_intel_crtc(&dev_priv->drm, crtc) {
> +		struct intel_crtc_state *crtc_state;
> +
> +		crtc_state = intel_atomic_get_crtc_state(&state->base,
> crtc);
> +		if (IS_ERR(crtc_state))
> +			return PTR_ERR(crtc_state);
> +	}
> +
> +	obj_state->changed = true;
> +
> +	return 0;
> +}

Just out of curiousity, aren't we supposed to lock global state,
by just grabbing crtcs always? One for read, all for write. I see now
you have two alternate ways of doing this, i.e either call
intel_atomic_lock_global_state or intel_atomic_serialize_global_state.
To me it seems better to have somewhat unified approach for global
state locking, however may be I'm missing something here.

Anyways,

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

> diff --git a/drivers/gpu/drm/i915/display/intel_global_state.h
> b/drivers/gpu/drm/i915/display/intel_global_state.h
> new file mode 100644
> index 000000000000..e6163a469029
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_global_state.h
> @@ -0,0 +1,87 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +#ifndef __INTEL_GLOBAL_STATE_H__
> +#define __INTEL_GLOBAL_STATE_H__
> +
> +#include <linux/list.h>
> +
> +struct drm_i915_private;
> +struct intel_atomic_state;
> +struct intel_global_obj;
> +struct intel_global_state;
> +
> +struct intel_global_state_funcs {
> +	struct intel_global_state *(*atomic_duplicate_state)(struct
> intel_global_obj *obj);
> +	void (*atomic_destroy_state)(struct intel_global_obj *obj,
> +				     struct intel_global_state *state);
> +};
> +
> +struct intel_global_obj {
> +	struct list_head head;
> +	struct intel_global_state *state;
> +	const struct intel_global_state_funcs *funcs;
> +};
> +
> +#define intel_for_each_global_obj(obj, dev_priv) \
> +	list_for_each_entry(obj, &(dev_priv)->global_obj_list, head)
> +
> +#define for_each_new_global_obj_in_state(__state, obj,
> new_obj_state, __i) \
> +	for ((__i) = 0; \
> +	     (__i) < (__state)->num_global_objs && \
> +		     ((obj) = (__state)->global_objs[__i].ptr, \
> +		      (new_obj_state) = (__state)-
> >global_objs[__i].new_state, 1); \
> +	     (__i)++) \
> +		for_each_if(obj)
> +
> +#define for_each_old_global_obj_in_state(__state, obj,
> new_obj_state, __i) \
> +	for ((__i) = 0; \
> +	     (__i) < (__state)->num_global_objs && \
> +		     ((obj) = (__state)->global_objs[__i].ptr, \
> +		      (new_obj_state) = (__state)-
> >global_objs[__i].old_state, 1); \
> +	     (__i)++) \
> +		for_each_if(obj)
> +
> +#define for_each_oldnew_global_obj_in_state(__state, obj,
> old_obj_state, new_obj_state, __i) \
> +	for ((__i) = 0; \
> +	     (__i) < (__state)->num_global_objs && \
> +		     ((obj) = (__state)->global_objs[__i].ptr, \
> +		      (old_obj_state) = (__state)-
> >global_objs[__i].old_state, \
> +		      (new_obj_state) = (__state)-
> >global_objs[__i].new_state, 1); \
> +	     (__i)++) \
> +		for_each_if(obj)
> +
> +struct intel_global_state {
> +	struct intel_atomic_state *state;
> +	bool changed;
> +};
> +
> +struct __intel_global_objs_state {
> +	struct intel_global_obj *ptr;
> +	struct intel_global_state *state, *old_state, *new_state;
> +};
> +
> +void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> +				  struct intel_global_obj *obj,
> +				  struct intel_global_state *state,
> +				  const struct intel_global_state_funcs
> *funcs);
> +void intel_atomic_global_obj_cleanup(struct drm_i915_private
> *dev_priv);
> +
> +struct intel_global_state *
> +intel_atomic_get_global_obj_state(struct intel_atomic_state *state,
> +				  struct intel_global_obj *obj);
> +struct intel_global_state *
> +intel_atomic_get_old_global_obj_state(struct intel_atomic_state
> *state,
> +				      struct intel_global_obj *obj);
> +struct intel_global_state *
> +intel_atomic_get_new_global_obj_state(struct intel_atomic_state
> *state,
> +				      struct intel_global_obj *obj);
> +
> +void intel_atomic_swap_global_state(struct intel_atomic_state
> *state);
> +void intel_atomic_clear_global_state(struct intel_atomic_state
> *state);
> +int intel_atomic_lock_global_state(struct intel_global_state
> *obj_state);
> +int intel_atomic_serialize_global_state(struct intel_global_state
> *obj_state);
> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 1787bfdd057f..b558e68b4dbd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -71,6 +71,7 @@
>  #include "display/intel_dpll_mgr.h"
>  #include "display/intel_dsb.h"
>  #include "display/intel_frontbuffer.h"
> +#include "display/intel_global_state.h"
>  #include "display/intel_gmbus.h"
>  #include "display/intel_opregion.h"
>  
> @@ -1100,6 +1101,8 @@ struct drm_i915_private {
>  	 */
>  	struct mutex dpll_lock;
>  
> +	struct list_head global_obj_list;
> +
>  	/*
>  	 * For reading active_pipes, cdclk_state holding any crtc
>  	 * lock is sufficient, for writing must hold all of them.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-28 14:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 17:47 [Intel-gfx] [PATCH 00/17] drm/i915: Global state rework Ville Syrjala
2020-01-20 17:47 ` [Intel-gfx] [PATCH 01/17] drm/i915: Polish WM_LINETIME register stuff Ville Syrjala
2020-01-20 17:47 ` [Intel-gfx] [PATCH 02/17] drm/i915: Move linetime wms into the crtc state Ville Syrjala
2020-01-29 14:05   ` Lisovskiy, Stanislav
2020-01-31 15:07   ` Ville Syrjälä
2020-01-20 17:47 ` [Intel-gfx] [PATCH 03/17] drm/i915: Nuke skl wm.dirty_pipes bitmask Ville Syrjala
2020-01-20 17:47 ` [Intel-gfx] [PATCH 04/17] drm/i915: Move more cdclk state handling into the cdclk code Ville Syrjala
2020-01-22 18:39   ` Souza, Jose
2020-01-20 17:47 ` [Intel-gfx] [PATCH 05/17] drm/i915: Collect more cdclk state under the same roof Ville Syrjala
2020-01-22 18:43   ` Souza, Jose
2020-01-20 17:47 ` [Intel-gfx] [PATCH 06/17] drm/i915: s/need_cd2x_updare/can_cd2x_update/ Ville Syrjala
2020-01-24 12:24   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 07/17] drm/i915: s/cdclk_state/cdclk_config/ Ville Syrjala
2020-01-22 18:51   ` Souza, Jose
2020-01-20 17:47 ` [Intel-gfx] [PATCH 08/17] drm/i915: Simplify intel_set_cdclk_{pre, post}_plane_update() calling convention Ville Syrjala
2020-01-22 18:51   ` Souza, Jose
2020-01-20 17:47 ` [Intel-gfx] [PATCH 09/17] drm/i915: Extract intel_cdclk_state Ville Syrjala
2020-01-22 18:51   ` Souza, Jose
2020-01-20 17:47 ` [Intel-gfx] [PATCH 10/17] drm/i915: swap() the entire cdclk state Ville Syrjala
2020-01-24 15:06   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 11/17] drm/i915: s/init_cdclk/init_cdclk_hw/ Ville Syrjala
2020-01-24 15:08   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 12/17] drm/i915: Move intel_atomic_state_free() into intel_atomic.c Ville Syrjala
2020-01-24 15:19   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 13/17] drm/i915: Intrduce better global state handling Ville Syrjala
2020-01-28 14:44   ` Lisovskiy, Stanislav [this message]
2020-01-28 15:29     ` Ville Syrjälä
2020-01-20 17:47 ` [Intel-gfx] [PATCH 13/17] drm/i915: Introduce " Ville Syrjala
2020-01-22 19:00   ` Souza, Jose
2020-01-22 19:11     ` Ville Syrjälä
2020-01-27 15:02   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 14/17] drm/i915: Convert bandwidth state to global state Ville Syrjala
2020-01-27 15:21   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 15/17] drm/i915: Introduce intel_calc_active_pipes() Ville Syrjala
2020-01-27 15:25   ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 16/17] drm/i915: Convert cdclk to global state Ville Syrjala
2020-01-21 14:03   ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2020-01-27 17:03     ` Imre Deak
2020-01-27 17:15       ` Ville Syrjälä
2020-01-27 17:54         ` Imre Deak
2020-01-20 17:47 ` [Intel-gfx] [PATCH 17/17] drm/i915: Store active_pipes bitmask in cdclk state Ville Syrjala
2020-01-27 17:11   ` Imre Deak
2020-01-20 18:43 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Global state rework Patchwork
2020-01-21  2:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-01-21 13:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-21 17:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Global state rework (rev2) Patchwork
2020-01-21 18:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-01-23  0:02 ` [Intel-gfx] ✗ 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=cb61046b5a0238b6cf2bf4bd078d521ef8efde0d.camel@intel.com \
    --to=stanislav.lisovskiy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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 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.