From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stefan Joosten <stefan@atcomputing.nl>
Cc: David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
Date: Thu, 1 Oct 2020 18:23:46 +0300 [thread overview]
Message-ID: <20201001152346.GR6112@intel.com> (raw)
In-Reply-To: <60a804aa6357eb17daa1729f4bce25e762344e9f.camel@atcomputing.nl>
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote:
> The fix of flagging state->modeset whenever distrust_bios_wm is set
> causes a regression when initializing display(s) attached to a Lenovo
> USB-C docking station. The display remains blank until the dock is
> reattached. Revert to bring the behavior of the functional v5.6 stable.
>
> This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442
> Signed-off-by: Stefan Joosten <stefan@atcomputing.nl>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index b18c5ac2934d..ece1c28278f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - /*
> - * 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;
> -
Argh. If only I had managed to land the full dbuf rework and nuke this
mess before it came back to bite us...
This is definitely going to break something else, so not great.
Can you file an upstream bug at
https://gitlab.freedesktop.org/drm/intel/issues/new
and attach dmesgs from booting both good and bad kernels with
drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len=
if necessary to capture the full log.
> intel_fbc_choose_crtc(dev_priv, state);
> ret = calc_watermark_data(state);
> if (ret)
> --
> 2.25.4
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stefan Joosten <stefan@atcomputing.nl>
Cc: David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
Date: Thu, 1 Oct 2020 18:23:46 +0300 [thread overview]
Message-ID: <20201001152346.GR6112@intel.com> (raw)
In-Reply-To: <60a804aa6357eb17daa1729f4bce25e762344e9f.camel@atcomputing.nl>
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote:
> The fix of flagging state->modeset whenever distrust_bios_wm is set
> causes a regression when initializing display(s) attached to a Lenovo
> USB-C docking station. The display remains blank until the dock is
> reattached. Revert to bring the behavior of the functional v5.6 stable.
>
> This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442
> Signed-off-by: Stefan Joosten <stefan@atcomputing.nl>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index b18c5ac2934d..ece1c28278f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - /*
> - * 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;
> -
Argh. If only I had managed to land the full dbuf rework and nuke this
mess before it came back to bite us...
This is definitely going to break something else, so not great.
Can you file an upstream bug at
https://gitlab.freedesktop.org/drm/intel/issues/new
and attach dmesgs from booting both good and bad kernels with
drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len=
if necessary to capture the full log.
> intel_fbc_choose_crtc(dev_priv, state);
> ret = calc_watermark_data(state);
> if (ret)
> --
> 2.25.4
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stefan Joosten <stefan@atcomputing.nl>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true"
Date: Thu, 1 Oct 2020 18:23:46 +0300 [thread overview]
Message-ID: <20201001152346.GR6112@intel.com> (raw)
In-Reply-To: <60a804aa6357eb17daa1729f4bce25e762344e9f.camel@atcomputing.nl>
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote:
> The fix of flagging state->modeset whenever distrust_bios_wm is set
> causes a regression when initializing display(s) attached to a Lenovo
> USB-C docking station. The display remains blank until the dock is
> reattached. Revert to bring the behavior of the functional v5.6 stable.
>
> This reverts commit 0f8839f5f323da04a800e6ced1136e4b1e1689a9.
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1879442
> Signed-off-by: Stefan Joosten <stefan@atcomputing.nl>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index b18c5ac2934d..ece1c28278f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14942,20 +14942,6 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - /*
> - * 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;
> -
Argh. If only I had managed to land the full dbuf rework and nuke this
mess before it came back to bite us...
This is definitely going to break something else, so not great.
Can you file an upstream bug at
https://gitlab.freedesktop.org/drm/intel/issues/new
and attach dmesgs from booting both good and bad kernels with
drm.debug=0x1e passed to the kernel cmdline? Bump log_buf_len=
if necessary to capture the full log.
> intel_fbc_choose_crtc(dev_priv, state);
> ret = calc_watermark_data(state);
> if (ret)
> --
> 2.25.4
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2020-10-01 15:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 13:47 [Intel-gfx] [PATCH] Revert "drm/i915: Force state->modeset=true when distrust_bios_wm==true" Stefan Joosten
2020-09-30 13:47 ` Stefan Joosten
2020-09-30 13:47 ` Stefan Joosten
2020-09-30 15:00 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2020-10-01 15:23 ` Ville Syrjälä [this message]
2020-10-01 15:23 ` [Intel-gfx] [PATCH] " Ville Syrjälä
2020-10-01 15:23 ` Ville Syrjälä
2020-10-15 14:37 ` Stefan Joosten
2020-10-15 14:37 ` Stefan Joosten
2020-10-15 14:37 ` Stefan Joosten
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=20201001152346.GR6112@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefan@atcomputing.nl \
/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.