Intel-GFX Archive on 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] drm/i915: Force state->modeset=true when distrust_bios_wm==true
Date: Thu, 13 Feb 2020 14:53:26 +0200	[thread overview]
Message-ID: <87lfp6y7g9.fsf@intel.com> (raw)
In-Reply-To: <20200212150102.7600-1-ville.syrjala@linux.intel.com>

On Wed, 12 Feb 2020, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Currently when we load the driver we set distrust_bios_wm=true, which
> will cause active_pipe_changes to get flagged even when we're not
> toggling any pipes on/off. The reason being that we want to fully
> redistribute the dbuf among the active pipes and ignore whatever
> state the firmware left behind.
>
> Unfortunately when the code flags active_pipe_changes it doesn't
> set state->modeset to true, which means the hardware dbuf state
> won't actually get updated. Hence the hardware and software
> states go out of sync, which can result in planes trying to use a
> disabled dbuf slice. Suprisingly that only seems to corrupt the
> display rather than making the whole display engine keel over.
>
> Let's fix this for now by flagging state->modeset whenever
> distrust_bios_wm is set.
>
> Eventually we'll likely want to rip out all of this mess and
> introduce proper statye tracking for dbuf. But that requires
> more work. Toss in a FIXME to that effect.

I have a hard time following all the implications of this change. Would
this under some circumstances lead to a case where we use the state read
at probe, and do a full modeset on that state?

DSC, lacking full state readout, fails badly with this change [1]. We'll
do DSC enable using a mostly zeroed out DSC config in state. Leading to
division by zero.

BR,
Jani.


[1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16544/fi-tgl-dsi/boot0.txt

>
> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> Fixes: ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 61ba1f2256a0..9e4f99ae81fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15027,6 +15027,20 @@ static int intel_atomic_check(struct drm_device *dev,
>  	if (new_cdclk_state && new_cdclk_state->force_min_cdclk_changed)
>  		any_ms = true;
>  
> +	/*
> +	 * distrust_bios_wm will force a full dbuf recomputation
> +	 * but the hardware state will only get updated accordingly
> +	 * if state->modeset==true. Hence distrust_bios_wm==true &&
> +	 * state->modeset==false is an invalid combination which
> +	 * would cause the hardware and software dbuf state to get
> +	 * out of sync. We must prevent that.
> +	 *
> +	 * FIXME clean up this mess and introduce better
> +	 * state tracking for dbuf.
> +	 */
> +	if (dev_priv->wm.distrust_bios_wm)
> +		any_ms = true;
> +
>  	if (any_ms) {
>  		ret = intel_modeset_checks(state);
>  		if (ret)

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-02-13 12:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 15:01 [Intel-gfx] [PATCH] drm/i915: Force state->modeset=true when distrust_bios_wm==true Ville Syrjala
2020-02-12 15:20 ` Lisovskiy, Stanislav
2020-02-13  3:42 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-02-13 12:53 ` Jani Nikula [this message]
2020-02-16 11:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87lfp6y7g9.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox