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: [Intel-gfx] [PATCH v3 10/18] drm/i915/pps: Reinit PPS delays after VBT has been fully parsed
Date: Tue, 03 May 2022 14:46:35 +0300	[thread overview]
Message-ID: <878rrirg84.fsf@intel.com> (raw)
In-Reply-To: <20220426193222.3422-11-ville.syrjala@linux.intel.com>

On Tue, 26 Apr 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> During the eDP probe we may not yet know the panel_type used
> to index the VBT panel tables. So the initial eDP probe will have
> to be done without that, and thus we won't yet have the PPS delays
> from the VBT. Once the VBT has been fully parse we should reinit
> the PPS delays to make sure it's fully accounted for.
>
> TODO: I wonder if we should do the eDP probe with some super safe
> PPS delayes (eg. max of all VBT PPS delays) just to make sure we
> don't violate the timings. Though typically the VBIOS/GOP do leave
> VDD enabled after boot in which case we don't actually have to care
> about the delays at all.

The trouble here is that the first init writes the registers, and the
second init reads them back as "bios set values", and never goes lower
than them. The late init can only increase the values based on VBT data.

So I'm holding off on the r-b on both the PPS changes for now because I
think this will need some kind of a redesign. Maybe we'll need to keep
track of the origins of the values at each step, and choose the right
ones at late init and skip the register writes if there are no
changes. I don't know.

BR,
Jani.

>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_pps.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
> index 0ae2be5c5318..15cbdc465a86 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1396,6 +1396,11 @@ void intel_pps_init_late(struct intel_dp *intel_dp)
>  	intel_wakeref_t wakeref;
>  
>  	with_intel_pps_lock(intel_dp, wakeref) {
> +		/* Reinit delays after per-panel info has been parsed from VBT */
> +		memset(&intel_dp->pps.pps_delays, 0, sizeof(intel_dp->pps.pps_delays));
> +		pps_init_delays(intel_dp);
> +		pps_init_registers(intel_dp, false);
> +
>  		if (edp_have_panel_vdd(intel_dp))
>  			edp_panel_vdd_schedule_off(intel_dp);
>  	}

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-05-03 11:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 19:32 [Intel-gfx] [PATCH v3 00/18] drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 01/18] drm/i915/bios: Reorder panel DTD parsing Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 02/18] drm/i915/bios: Generate LFP data table pointers if the VBT lacks them Ville Syrjala
2022-05-03 10:55   ` Jani Nikula
2022-05-03 17:29     ` Ville Syrjälä
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 03/18] drm/i915/bios: Get access to the tail end of the LFP data block Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 04/18] drm/i915/bios: Document the mess around the LFP data tables Ville Syrjala
2022-05-03 10:56   ` Jani Nikula
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 05/18] drm/i915/bios: Assume panel_type==0 if the VBT has bogus data Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 06/18] drm/i915/bios: Split parse_driver_features() into two parts Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 07/18] drm/i915/bios: Split VBT parsing to global vs. panel specific parts Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 08/18] drm/i915/bios: Don't parse some panel specific data multiple times Ville Syrjala
2022-05-03 11:08   ` Jani Nikula
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 09/18] drm/i915/pps: Split PPS init+sanitize in two Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 10/18] drm/i915/pps: Reinit PPS delays after VBT has been fully parsed Ville Syrjala
2022-05-03 11:46   ` Jani Nikula [this message]
2022-05-03 17:05     ` Ville Syrjälä
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 11/18] drm/i915/bios: Do panel specific VBT parsing later Ville Syrjala
2022-05-03 11:07   ` Jani Nikula
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 12/18] drm/i915/bios: Extract get_panel_type() Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 13/18] drm/i915/bios: Refactor panel_type code Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 14/18] drm/i915/bios: Determine panel type via PNPID match Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 15/18] drm/i915/bios: Parse the seamless DRRS min refresh rate Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 16/18] drm/i915: Respect VBT " Ville Syrjala
2022-04-26 19:32 ` [PATCH v3 17/18] drm/edid: Extract drm_edid_decode_mfg_id() Ville Syrjala
2022-04-26 19:32   ` [Intel-gfx] " Ville Syrjala
2022-04-26 19:32 ` [Intel-gfx] [PATCH v3 18/18] drm/i915/bios: Dump PNPID and panel name Ville Syrjala
2022-04-26 20:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev7) Patchwork
2022-04-26 20:32 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-26 20:56 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-04-27 13:25 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8) Patchwork
2022-04-27 13:25 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-27 13:55 ` [Intel-gfx] ✗ Fi.CI.BAT: 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=878rrirg84.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.