intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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 08/24] drm/i915: Prepare to split crtc state in uapi and hw state
Date: Thu, 10 Oct 2019 17:47:00 +0300	[thread overview]
Message-ID: <20191010144700.GG1208@intel.com> (raw)
In-Reply-To: <2f46b9c3-f354-1ebf-98dc-e9e401dd7420@linux.intel.com>

On Thu, Oct 10, 2019 at 04:21:00PM +0200, Maarten Lankhorst wrote:
> Op 08-10-2019 om 19:06 schreef Ville Syrjälä:
> > On Fri, Oct 04, 2019 at 01:34:58PM +0200, Maarten Lankhorst wrote:
> >> We want to split drm_crtc_state into the user visible state
> >> and actual hardware state. To prepare for this, we need some
> >> ground rules what should be in each state:
> >>
> >> In uapi we use:
> >> - crtc, *_changed flags, event, commit, state, mode_blob,
> >>   (plane/connector/encoder)_mask.
> >>
> >> In hw state we use what's displayed in hardware:
> >> - enable, active, (adjusted) mode, color property blobs.
> >>
> >> clear_intel_crtc_state and hw readout need to be updated for these rules,
> >> which will allow us to enable 2 joined pipes.
> > I still have hard time with reading this patch. I still think it
> > would be easier to read if we didn't do both the "uapi" and "hw" changes
> > at the same time.
> >
> > step 1.
> > 	struct drm_crtc_state uapi;
> > 	struct {
> > 		// hw state
> > 	} base;
> >
> > step 2. 
> > 	s/base/hw/
> >
> > I think that would make it more obvious which parts of the code are
> > looking at which state.
> 
> It wouldn't I think, but here's
> a dumb change with spatch on this patch.
> 
> //+       struct {
> //+               bool active, enable;
> //+               struct drm_property_blob *degamma_lut, *gamma_lut, *ctm;
> //+               struct drm_display_mode mode, adjusted_mode;
> //+       } hw;
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.active
> +T->hw.active

This doesn't really help me. There is no .uapi in upstream
code. I would like to see just the .base->.uapi changes
alone first so I can review which parts start to look at
the uapi state to make sure we aren't changing too much.
Then I'd like to to see the .base->.hw changes so that I
convince myself we didn't miss anything in the .base->.uapi
conversion.

And all the remaining drm_crtc_state usage is going to
make us miss something for sure, so getting rid of all that
first would probably help.

> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.enable
> +T->hw.enable
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.degamma_lut
> +T->hw.degamma_lut
> 
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.gamma_lut
> +T->hw.gamma_lut
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.ctm
> +T->hw.ctm
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.mode
> +T->hw.mode
> 
> @@
> struct intel_crtc_state *T;
> @@
> -T->uapi.adjusted_mode
> +T->hw.adjusted_mode
> 
> I replaced all the instances where we use the uapi members instead of the hw members explicitly in this patch, and came up with the following diff below.
> 
> Only the intel_color readout is potentially incorrect, the 2 explicit uapi uses in intel_display.c are needed.
> Didn't fix it because of hw readout, it possibly needs slightly more thought.
> 
> Does this satisfy the readability requirements? :)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index ab10c33266bf..cbf4c6e6e661 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11217,7 +11217,7 @@ int intel_get_load_detect_pipe(struct drm_connector *connector,
>  		goto fail;
>  	}
>  
> -	crtc_state->uapi.active = crtc_state->uapi.enable = true;
> +	crtc_state->hw.active = crtc_state->hw.enable = true;
>  
>  	if (!mode)
>  		mode = &load_detect_mode;
> @@ -13578,7 +13578,7 @@ static int intel_atomic_check(struct drm_device *dev,
>  		if (!needs_modeset(new_crtc_state))
>  			continue;
>  
> -		if (!new_crtc_state->uapi.enable) {
> +		if (!new_crtc_state->hw.enable) {
>  			any_ms = true;
>  			continue;
>  		}
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c
> index 5586891572f8..52712bb9ed15 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1623,7 +1623,7 @@ static void i9xx_read_luts(struct intel_crtc_state *crtc_state)
>  	if (!crtc_state->gamma_enable)
>  		return;
>  
> -	crtc_state->uapi.gamma_lut = i9xx_read_lut_8(crtc_state);
> +	crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
>  }
>  
>  static struct drm_property_blob *
> @@ -1673,9 +1673,9 @@ static void i965_read_luts(struct intel_crtc_state *crtc_state)
>  		return;
>  
>  	if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> -		crtc_state->uapi.gamma_lut = i9xx_read_lut_8(crtc_state);
> +		crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
>  	else
> -		crtc_state->uapi.gamma_lut = i965_read_lut_10p6(crtc_state);
> +		crtc_state->hw.gamma_lut = i965_read_lut_10p6(crtc_state);
>  }
>  
>  static struct drm_property_blob *
> @@ -1715,7 +1715,7 @@ chv_read_cgm_lut(const struct intel_crtc_state *crtc_state)
>  static void chv_read_luts(struct intel_crtc_state *crtc_state)
>  {
>  	if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
> -		crtc_state->uapi.gamma_lut = chv_read_cgm_lut(crtc_state);
> +		crtc_state->hw.gamma_lut = chv_read_cgm_lut(crtc_state);
>  	else
>  		i965_read_luts(crtc_state);
>  }
> @@ -1762,9 +1762,9 @@ static void ilk_read_luts(struct intel_crtc_state *crtc_state)
>  		return;
>  
>  	if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> -		crtc_state->uapi.gamma_lut = i9xx_read_lut_8(crtc_state);
> +		crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
>  	else
> -		crtc_state->uapi.gamma_lut = ilk_read_lut_10(crtc_state);
> +		crtc_state->hw.gamma_lut = ilk_read_lut_10(crtc_state);
>  }
>  
>  static struct drm_property_blob *
> @@ -1811,9 +1811,9 @@ static void glk_read_luts(struct intel_crtc_state *crtc_state)
>  		return;
>  
>  	if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
> -		crtc_state->uapi.gamma_lut = i9xx_read_lut_8(crtc_state);
> +		crtc_state->hw.gamma_lut = i9xx_read_lut_8(crtc_state);
>  	else
> -		crtc_state->uapi.gamma_lut = glk_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0));
> +		crtc_state->hw.gamma_lut = glk_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0));
>  }
>  
>  void intel_color_init(struct intel_crtc *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-10-10 14:47 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 11:34 [PATCH 00/24] Enable bigjoiner support, second approach Maarten Lankhorst
2019-10-04 11:34 ` [PATCH 01/24] HAX to make DSC work on the icelake test system Maarten Lankhorst
2019-10-04 11:34 ` [PATCH 02/24] drm/i915: Fix for_each_intel_plane_mask definition Maarten Lankhorst
2019-10-04 13:14   ` Ville Syrjälä
2019-10-07 19:37   ` Matt Roper
2019-10-04 11:34 ` [PATCH 03/24] drm/i915: Introduce and use intel_atomic_crtc_state_for_each_plane_state Maarten Lankhorst
2019-10-04 13:18   ` Ville Syrjälä
2019-10-07 19:37   ` Matt Roper
2019-10-04 11:34 ` [PATCH 04/24] drm/i915: Remove cursor use of properties for coordinates Maarten Lankhorst
2019-10-04 13:22   ` Ville Syrjälä
2019-10-07 19:37   ` Matt Roper
2019-10-10 12:10     ` Maarten Lankhorst
2019-10-10 14:04     ` Maarten Lankhorst
2019-10-04 11:34 ` [PATCH 05/24] drm/i915: Use intel_plane_state in prepare and cleanup plane_fb Maarten Lankhorst
2019-10-04 13:23   ` Ville Syrjälä
2019-10-07 19:37   ` Matt Roper
2019-10-04 11:34 ` [PATCH 06/24] drm/i915: Remove begin/finish_crtc_commit, v4 Maarten Lankhorst
2019-10-07 19:43   ` Matt Roper
2019-10-04 11:34 ` [PATCH 07/24] drm/i915: Introduce intel_atomic_get_plane_state_after_check() Maarten Lankhorst
2019-10-08 17:03   ` Ville Syrjälä
2019-10-10 11:56     ` Maarten Lankhorst
2019-10-10 12:39       ` Ville Syrjälä
2019-10-10 13:01         ` Maarten Lankhorst
2019-10-04 11:34 ` [PATCH 08/24] drm/i915: Prepare to split crtc state in uapi and hw state Maarten Lankhorst
2019-10-08 17:06   ` Ville Syrjälä
2019-10-10 14:21     ` Maarten Lankhorst
2019-10-10 14:47       ` Ville Syrjälä [this message]
2019-10-14  8:20         ` Maarten Lankhorst
2019-10-04 11:34 ` [PATCH 09/24] drm/i915: Handle a few more cases for crtc hw/uapi split Maarten Lankhorst
2019-10-04 13:31   ` Ville Syrjälä
2019-10-04 15:51     ` Maarten Lankhorst
2019-10-04 15:56       ` Ville Syrjälä
2019-10-04 11:35 ` [PATCH 10/24] drm/i915: Complete crtc hw/uapi split, v2 Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 11/24] drm/i915: Preparation for plane split Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 12/24] drm/i915: Split plane hw and uapi state Maarten Lankhorst
2019-10-08 17:42   ` Ville Syrjälä
2019-10-09 12:13     ` Maarten Lankhorst
2019-10-09 12:23       ` Ville Syrjälä
2019-10-09 12:31         ` Maarten Lankhorst
2019-10-09 12:41           ` Ville Syrjälä
2019-10-09 12:58             ` Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 13/24] drm/i915: Stop using drm_atomic_helper_check_planes() Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 14/24] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v2 Maarten Lankhorst
2019-10-08 17:50   ` Ville Syrjälä
2019-10-04 11:35 ` [PATCH 15/24] drm/i915: Try to make bigjoiner work in atomic check, v2 Maarten Lankhorst
2019-10-08 19:40   ` Ville Syrjälä
2019-10-10 12:42     ` Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 16/24] drm/i915: Enable big joiner support in enable and disable sequences Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 17/24] drm/i915: Make hardware readout work on i915 Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 18/24] drm/i915: Remove special case slave handling during hw programming Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 19/24] drm/i915: Link planes in a bigjoiner configuration, v2 Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 20/24] drm/i915: Add bigjoiner aware plane clipping checks Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 21/24] drm/i915: Ensure color blobs are copied to slave before planes are checked Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 22/24] drm/i915: Add intel_update_bigjoiner handling Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 23/24] drm/i915: Add debugfs dumping for bigjoiner, v2 Maarten Lankhorst
2019-10-04 11:35 ` [PATCH 24/24] semi-hax: drm/i915: Always verify ddb allocation Maarten Lankhorst
2019-10-04 14:23   ` [PATCH] " Maarten Lankhorst
2019-10-04 13:10 ` ✗ Fi.CI.BUILD: failure for Enable bigjoiner support, second approach Patchwork
2019-10-04 18:03 ` ✗ Fi.CI.BUILD: failure for Enable bigjoiner support, second approach. (rev2) Patchwork
2019-10-10 16:25 ` ✗ Fi.CI.BUILD: failure for Enable bigjoiner support, second approach. (rev3) 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=20191010144700.GG1208@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).