All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/8] drm/i915/pps: Store the power cycle delay without the +1
Date: Thu, 07 Nov 2024 11:18:02 +0200	[thread overview]
Message-ID: <87jzdfflmd.fsf@intel.com> (raw)
In-Reply-To: <20241106215859.25446-2-ville.syrjala@linux.intel.com>

On Wed, 06 Nov 2024, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The code initializing the power sequencing delays is a bit
> hard to follow. One confusing thing is that we keep doing the
> +/-1 adjustment for the hardware register value in several places.
> Simplify this a bit by doing the adjustment only when reading or
> writing the actual register.
>
> This also matches how the LVDS code does things.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 28 ++++++++++--------------
>  1 file changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
> index 093fe37a3983..83d65105f32b 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1390,7 +1390,7 @@ static void
>  intel_pps_readout_hw_state(struct intel_dp *intel_dp, struct edp_power_seq *seq)
>  {
>  	struct intel_display *display = to_intel_display(intel_dp);
> -	u32 pp_on, pp_off, pp_ctl;
> +	u32 pp_on, pp_off, pp_ctl, power_cycle_delay;
>  	struct pps_registers regs;
>  
>  	intel_pps_get_registers(intel_dp, &regs);
> @@ -1415,10 +1415,13 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, struct edp_power_seq *seq)
>  
>  		pp_div = intel_de_read(display, regs.pp_div);
>  
> -		seq->t11_t12 = REG_FIELD_GET(PANEL_POWER_CYCLE_DELAY_MASK, pp_div) * 1000;
> +		power_cycle_delay = REG_FIELD_GET(PANEL_POWER_CYCLE_DELAY_MASK, pp_div);
>  	} else {
> -		seq->t11_t12 = REG_FIELD_GET(BXT_POWER_CYCLE_DELAY_MASK, pp_ctl) * 1000;
> +		power_cycle_delay = REG_FIELD_GET(BXT_POWER_CYCLE_DELAY_MASK, pp_ctl);
>  	}
> +
> +	/* hardware wants <delay>+1 in 100ms units */
> +	seq->t11_t12 = power_cycle_delay ? (power_cycle_delay - 1) * 1000 : 0;
>  }
>  
>  static void
> @@ -1494,12 +1497,6 @@ static void pps_init_delays_vbt(struct intel_dp *intel_dp,
>  			    vbt->t11_t12);
>  	}
>  
> -	/* T11_T12 delay is special and actually in units of 100ms, but zero
> -	 * based in the hw (so we need to add 100 ms). But the sw vbt
> -	 * table multiplies it with 1000 to make it in units of 100usec,
> -	 * too. */
> -	vbt->t11_t12 += 100 * 10;
> -
>  	intel_pps_dump_state(intel_dp, "vbt", vbt);
>  }
>  
> @@ -1516,11 +1513,7 @@ static void pps_init_delays_spec(struct intel_dp *intel_dp,
>  	spec->t8 = 50 * 10; /* no limit for t8, use t7 instead */
>  	spec->t9 = 50 * 10; /* no limit for t9, make it symmetric with t8 */
>  	spec->t10 = 500 * 10;
> -	/* This one is special and actually in units of 100ms, but zero
> -	 * based in the hw (so we need to add 100 ms). But the sw vbt
> -	 * table multiplies it with 1000 to make it in units of 100usec,
> -	 * too. */
> -	spec->t11_t12 = (510 + 100) * 10;
> +	spec->t11_t12 = 510 * 10;
>  
>  	intel_pps_dump_state(intel_dp, "spec", spec);
>  }
> @@ -1665,11 +1658,14 @@ static void pps_init_registers(struct intel_dp *intel_dp, bool force_disable_vdd
>  	 */
>  	if (i915_mmio_reg_valid(regs.pp_div))
>  		intel_de_write(display, regs.pp_div,
> -			       REG_FIELD_PREP(PP_REFERENCE_DIVIDER_MASK, (100 * div) / 2 - 1) | REG_FIELD_PREP(PANEL_POWER_CYCLE_DELAY_MASK, DIV_ROUND_UP(seq->t11_t12, 1000)));
> +			       REG_FIELD_PREP(PP_REFERENCE_DIVIDER_MASK,
> +					      (100 * div) / 2 - 1) |
> +			       REG_FIELD_PREP(PANEL_POWER_CYCLE_DELAY_MASK,
> +					      DIV_ROUND_UP(seq->t11_t12, 1000) + 1));
>  	else
>  		intel_de_rmw(display, regs.pp_ctrl, BXT_POWER_CYCLE_DELAY_MASK,
>  			     REG_FIELD_PREP(BXT_POWER_CYCLE_DELAY_MASK,
> -					    DIV_ROUND_UP(seq->t11_t12, 1000)));
> +					    DIV_ROUND_UP(seq->t11_t12, 1000) + 1));
>  
>  	drm_dbg_kms(display->drm,
>  		    "panel power sequencer register settings: PP_ON %#x, PP_OFF %#x, PP_DIV %#x\n",

-- 
Jani Nikula, Intel

  reply	other threads:[~2024-11-07  9:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 21:58 [PATCH 0/8] drm/i915/pps: Some PPS cleanups Ville Syrjala
2024-11-06 21:58 ` [PATCH 1/8] drm/i915/pps: Store the power cycle delay without the +1 Ville Syrjala
2024-11-07  9:18   ` Jani Nikula [this message]
2024-11-06 21:58 ` [PATCH 2/8] drm/i915/pps: Decouple pps delays from VBT struct definition Ville Syrjala
2024-11-07  9:18   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 3/8] drm/i915/pps: Rename intel_pps_delay members Ville Syrjala
2024-11-07  9:19   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 4/8] drm/i915/lvds: Use struct intel_pps_delays for LVDS power sequencing Ville Syrjala
2024-11-07  9:19   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 5/8] drm/i915/pps: Spell out the eDP spec power sequencing delays a bit more clearly Ville Syrjala
2024-11-07  9:19   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 6/8] drm/i915/pps: Extract msecs_to_pps_units() Ville Syrjala
2024-11-07  9:20   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 7/8] drm/i915/pps: Extract pps_units_to_msecs() Ville Syrjala
2024-11-07  9:20   ` Jani Nikula
2024-11-06 21:58 ` [PATCH 8/8] drm/i915/pps: Eliminate pointless get_delay() macro Ville Syrjala
2024-11-07  9:20   ` Jani Nikula
2024-11-06 22:44 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pps: Some PPS cleanups Patchwork
2024-11-06 22:44 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-11-06 23:04 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-11-07  9:22 ` [PATCH 0/8] " Jani Nikula
2024-11-07 16:15 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pps: Some PPS cleanups (rev2) Patchwork
2024-11-07 16:16 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-11-07 16:25 ` ✓ Fi.CI.BAT: success " Patchwork
2024-11-07 19:07 ` ✗ 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=87jzdfflmd.fsf@intel.com \
    --to=jani.nikula@linux.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.