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; - intel_fbc_choose_crtc(dev_priv, state); ret = calc_watermark_data(state); if (ret)
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
Dear Ville Syrjälä,
Thank you for responding so quickly. I was occupied with work and life for the past two weeks, sorry about the wait, but have now managed to find some time to continue pursuing this issue again.
On Thu, 2020-10-01 at 18:23 +0300, Ville Syrjälä wrote:
Argh. If only I had managed to land the full dbuf rework and nuke this mess before it came back to bite us...
Yeah... I know the feeling.
This is definitely going to break something else, so not great.
I did expect that. The automated tests failing was a pretty good indicator. You put that code in to take care of something. All I did was just tear it down because it happens to work better for me... blunt but functional for my purposes.
Seems to need some finesse or a condition to not cause my problem? Yet still function for the reason you put it in there for.
I am more than willing to play guinea pig and test patches on my end to improve it with you.
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.
I have done so today. It's at: https://gitlab.freedesktop.org/drm/intel/-/issues/2579
dri-devel@lists.freedesktop.org
-
Stefan Joosten -
Ville Syrjälä