Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 rebased 06/11] drm/i915/display: Share intel_connector_needs_modeset()
Date: Mon, 16 Dec 2019 13:55:36 +0200	[thread overview]
Message-ID: <20191216115536.GL1208@intel.com> (raw)
In-Reply-To: <20191214001455.quhvzgedzsl5oenq@ldmartin-desk1>

On Fri, Dec 13, 2019 at 04:14:55PM -0800, Lucas De Marchi wrote:
> On Thu, Dec 12, 2019 at 05:52:49PM +0200, Ville Syrjälä wrote:
> >On Wed, Dec 11, 2019 at 10:45:21AM -0800, José Roberto de Souza wrote:
> >> intel_connector_needs_modeset() will be used outside of
> >> intel_display.c in a future patch so it would only be necessary to
> >> remove the state and add the prototype to the header file.
> >>
> >> But while at it, I simplified the arguments and changed to intel
> >> types and moved it to a better place intel_atomic.c.
> >>
> >> That allowed us to convert the whole
> >> intel_encoders_update_prepare/complete to intel type too.
> >>
> >> No behavior changes intended here.
> >>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_atomic.c  | 32 ++++++++++++
> >>  drivers/gpu/drm/i915/display/intel_atomic.h  |  3 ++
> >>  drivers/gpu/drm/i915/display/intel_display.c | 53 ++++++--------------
> >>  3 files changed, 51 insertions(+), 37 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> index fd0026fc3618..6e93a39a6fec 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> >> @@ -174,6 +174,38 @@ intel_digital_connector_duplicate_state(struct drm_connector *connector)
> >>  	return &state->base;
> >>  }
> >>
> >> +/**
> >> + * intel_digital_connector_needs_modeset - check if connector needs a modeset
> >> + */
> >> +bool
> >> +intel_digital_connector_needs_modeset(struct intel_atomic_state *state,
> >
> >Why "digital"? Oh because intel_atomic_get_old_connector_state() return
> >a ditgital_connector_state. A bit surprising.
> >
> >I suggest using just drm_connector_state here to keep this function
> >totally generic.
> >
> >> +				      struct intel_connector *connector)
> >> +{
> >> +	struct intel_digital_connector_state *old_connector_state, *new_connector_state;
> >> +	struct intel_crtc *old_crtc, *new_crtc;
> >> +	struct intel_crtc_state *new_crtc_state;
> >> +
> >> +	old_connector_state = intel_atomic_get_old_connector_state(state,
> >> +								   connector);
> >
> >Could be done when declaring the variable. Dunno which is prettier
> >though.
> >
> >> +	if (old_connector_state->base.crtc)
> >> +		old_crtc = to_intel_crtc(old_connector_state->base.crtc);
> >> +	else
> >> +		old_crtc = NULL;
> >
> >Simple
> >old_crtc = to_intel_crtc(old_connector_state->base.crtc);
> >will do. Can be done when declaring the variable as well.
> >
> >> +
> >> +	new_connector_state = intel_atomic_get_new_connector_state(state,
> >> +								   connector);
> >> +	if (new_connector_state->base.crtc) {
> >> +		new_crtc = to_intel_crtc(new_connector_state->base.crtc);
> >
> >ditto.
> >
> >> +		new_crtc_state = intel_atomic_get_new_crtc_state(state, new_crtc);
> >
> >Then this just becomes
> >if (new_crtc)
> >	new_crtc_state = ...;
> >
> >Or maybe
> >new_crtc_state = new_crtc ? get : NULL;
> >but that could be a bit ugly.
> >
> >
> >> +	} else {
> >> +		new_crtc_state = NULL;
> >> +		new_crtc = NULL;
> >> +	}
> >> +
> >> +	return new_crtc != old_crtc ||
> >> +	       (new_crtc && drm_atomic_crtc_needs_modeset(&new_crtc_state->uapi));
> >
> >Hmm. In fact this function could be one of those special cases where we
> >might even want to use all drm_ types internally since we don't actually
> >need anything else.
> 
> so... do you mean to bring intel_connector_needs_modeset() as is?

Maybe... Yeah, looks more useful as is.

> >> -static bool
> >> -intel_connector_needs_modeset(struct intel_atomic_state *state,
> >> -			      const struct drm_connector_state *old_conn_state,
> >> -			      const struct drm_connector_state *new_conn_state)
> >> -{
> >> -	struct intel_crtc *old_crtc = old_conn_state->crtc ?
> >> -				      to_intel_crtc(old_conn_state->crtc) : NULL;
> >> -	struct intel_crtc *new_crtc = new_conn_state->crtc ?
> >> -				      to_intel_crtc(new_conn_state->crtc) : NULL;

You could toss out those ternary operators while at it. They're not needed.

> >> -
> >> -	return new_crtc != old_crtc ||
> >> -	       (new_crtc &&
> >> -		needs_modeset(intel_atomic_get_new_crtc_state(state, new_crtc)));
> >> -}
> >> -

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-12-16 11:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 18:45 [Intel-gfx] [PATCH v2 rebased 01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 02/11] drm/i915: s/intel_crtc/crtc/ in intel_crtc_init() José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 03/11] drm/i915: Introduce intel_crtc_{alloc, free}() José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 04/11] drm/i915: Introduce intel_crtc_state_reset() José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 05/11] drm/i915: Introduce intel_plane_state_reset() José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 06/11] drm/i915/display: Share intel_connector_needs_modeset() José Roberto de Souza
2019-12-12 15:52   ` Ville Syrjälä
2019-12-14  0:14     ` Lucas De Marchi
2019-12-16 11:55       ` Ville Syrjälä [this message]
2019-12-16 17:07     ` Souza, Jose
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 07/11] drm/i915/tgl: Select master transcoder for MST stream José Roberto de Souza
2019-12-12 20:44   ` Ville Syrjälä
2019-12-13 20:56     ` Ville Syrjälä
2019-12-16 17:23       ` Souza, Jose
2019-12-16 19:07         ` Souza, Jose
2019-12-16 21:29           ` Ville Syrjälä
2019-12-16 17:19     ` Souza, Jose
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 08/11] drm/i915/display: Always enables MST master pipe first José Roberto de Souza
2019-12-12 21:21   ` Ville Syrjälä
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 09/11] drm/i915/dp: Fix MST disable sequences José Roberto de Souza
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 10/11] drm/i915/display: Check if pipe fastset is allowed by external dependencies José Roberto de Souza
2019-12-12 21:28   ` Ville Syrjälä
2019-12-12 21:41     ` Manasi Navare
2019-12-16 17:35       ` Souza, Jose
2019-12-16 17:33     ` Souza, Jose
2019-12-11 18:45 ` [Intel-gfx] [PATCH v2 rebased 11/11] drm/i915/display: Add comment to a function that probably can be removed José Roberto de Souza
2019-12-12  1:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,rebased,01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co Patchwork
2019-12-17 14:05 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,rebased,01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev2) 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=20191216115536.GL1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@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