From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.
Date: Mon, 8 Aug 2016 11:05:22 +0300 [thread overview]
Message-ID: <20160808080522.GA4329@intel.com> (raw)
In-Reply-To: <8b93b163-1e5f-d9cd-3c31-dc8a3a555174@linux.intel.com>
On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 05-08-16 om 22:28 schreef ville.syrjala@linux.intel.com:
> > From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >
> > This function would call drm_modeset_lock_all, while the suspend/resume
> > functions already have their own locking. Fix this by factoring out
> > __intel_display_resume, and calling the atomic helpers for duplicating
> > atomic state and disabling all crtc's during suspend.
> >
> > Changes since v1:
> > - Deal with -EDEADLK right after lock_all and clean up calls
> > to hw readout.
> > - Always take all modeset locks so updates during gpu reset are blocked.
> > Changes since v2:
> > - Fix deadlock in intel_update_primary_planes.
> > - Move WARN_ON(EDEADLK) to __intel_display_resume.
> > - pctx -> ctx
> > - only call __intel_display_resume on success in intel_display_resume.
> > Changes since v3:
> > - Rebase on top of dev_priv -> dev change.
> > - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> > Changes since v4 [by vsyrjala]:
> > - Deal with skip_intermediate_wm
> > - Update comment w.r.t. mode_config.mutex vs. ->detect()
> > - Rebase due to INTEL_GEN() etc.
>
> Setting skip_intermediate_wm seems to have already been upstreamed and I missed it, but
> this may blow up in .crtc_enable, which programs in the intermediate wm's which is used
> until all planes are enabled.
What blows up and how?
Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
this time anyway, so -ENOCARE at this point really.
>
> I fear this may blow up in interesting ways. And it should probably be using
> dev_priv->wm.distrust_bios_wm instead like on SKL.
Sigh. How many ways do we need to do the same thing?
Anywyas, what we should really do is sanitize the current wms better
at readout time, and then we shouldn't need these flags at all.
--
Ville Syrj�l�
Intel OTC
prev parent reply other threads:[~2016-08-08 8:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1470428910-12125-1-git-send-email-ville.syrjala@linux.intel.com>
2016-08-05 20:28 ` [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5 ville.syrjala
2016-08-08 7:52 ` Maarten Lankhorst
2016-08-08 8:05 ` Ville Syrjälä [this message]
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=20160808080522.GA4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).