From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/edp: wait power off delay at driver remove to optimize probe
Date: Wed, 16 Nov 2022 20:23:31 +0200 [thread overview]
Message-ID: <Y3Uqowmo36DpDjym@intel.com> (raw)
In-Reply-To: <20221116150657.1347504-1-jani.nikula@intel.com>
On Wed, Nov 16, 2022 at 05:06:57PM +0200, Jani Nikula wrote:
> Panel power off delay is the time the panel power needs to remain off
> after being switched off, before it can be switched on again.
>
> For the purpose of respecting panel power off delay at driver probe,
> assuming the panel was last switched off at driver probe is overly
> pessimistic. If the panel was never on, we'd end up waiting for no
> reason.
>
> We don't know what has happened before kernel boot, but we can make some
> assumptions:
>
> - The panel may have been switched off right before kernel boot by some
> pre-os environment.
>
> - After kernel boot, the panel may only be switched off by i915.
>
> - At i915 driver probe, only a previously loaded and removed i915 may
> have switched the panel power off.
>
> With these assumptions, we can initialize the last power off time to
> kernel boot time, if we also ensure i915 driver remove waits for the
> panel power off delay after switching panel power off.
>
> This shaves off the time it takes from kernel boot to i915 probe from
> the first panel enable, if (and only if) the panel was not already
> enabled at boot.
>
> The encoder destroy hook is pretty much the last place where we can
> wait, right after we've ensured the panel power has been switched off,
> and before the whole encode is destroyed.
Yeah, the fact that we have the vdd_off_sync() in there at least
theoretically means the vdd might be on at any point before that.
I was also pondering about doing this for all encoder types.
Though the benefits are slightly less pronounced I guess:
a) we don't need to power the panel for the output probe on those,
so a bit more time will have elapsed anyway before we have to
power the panel on during the first modeset
b) for LVDS we rely 100% on the pps state machine so the initial
boot case is already as optimal as possible. Adding the explicit
wait into the unload path could thus only help the speed of
of the first modeset during module reload
But maybe we'd stil want to do that, for consistency if nothing else?
Either way, this patch is
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417
> Cc: Lee Shawn C <shawn.c.lee@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++++++
> drivers/gpu/drm/i915/display/intel_pps.c | 8 +++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 914161d7d122..67089711d9e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4877,6 +4877,12 @@ void intel_dp_encoder_flush_work(struct drm_encoder *encoder)
>
> intel_pps_vdd_off_sync(intel_dp);
>
> + /*
> + * Ensure power off delay is respected on module remove, so that we can
> + * reduce delays at driver probe. See pps_init_timestamps().
> + */
> + intel_pps_wait_power_cycle(intel_dp);
> +
> intel_dp_aux_fini(intel_dp);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
> index 81ee7f3aadf6..9bbf41a076f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1100,7 +1100,13 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp *intel_dp)
>
> static void pps_init_timestamps(struct intel_dp *intel_dp)
> {
> - intel_dp->pps.panel_power_off_time = ktime_get_boottime();
> + /*
> + * Initialize panel power off time to 0, assuming panel power could have
> + * been toggled between kernel boot and now only by a previously loaded
> + * and removed i915, which has already ensured sufficient power off
> + * delay at module remove.
> + */
> + intel_dp->pps.panel_power_off_time = 0;
> intel_dp->pps.last_power_on = jiffies;
> intel_dp->pps.last_backlight_off = jiffies;
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-11-16 18:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 15:06 [Intel-gfx] [PATCH] drm/i915/edp: wait power off delay at driver remove to optimize probe Jani Nikula
2022-11-16 18:23 ` Ville Syrjälä [this message]
2022-11-17 11:35 ` Jani Nikula
2022-11-17 0:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-11-17 10:19 ` [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=Y3Uqowmo36DpDjym@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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