From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: intel-gfx@freedesktop.org
Subject: Re: Redo a modeset on link training failure
Date: Fri, 21 Oct 2016 12:35:44 +0300 [thread overview]
Message-ID: <20161021093544.GB4329@intel.com> (raw)
In-Reply-To: <20161021023152.GB19529@intel.com>
On Thu, Oct 20, 2016 at 07:31:53PM -0700, Manasi Navare wrote:
> Hi Ville,
>
> I have implemented the code that we discussed where if the link training
> fails, it would validate the modes on the new constraints and call
> an atomic helper like drm_atomic_helper_connector_modeset() to redo
> a modeset for the same mode. The two patches for this implemnetation is
> are:
>
> http://paste.ubuntu.com/23357104/
> http://paste.ubuntu.com/23357105/
>
> With this I can successfully trigger the modeset and retrain the link
> at lower link rate. But I am getting a warning during intel_audio_codec_enable()
> in intel_enable_ddi() during the commit phase on SKL.
> Following is the dmesg log:
>
> http://paste.ubuntu.com/23357075/
>
> After further looking at it, I see that this calls drm_select_eld() function
> that throws a warning if the mode_config mutex and modeset locks are held.
You get the warn when they're *not* held. And checking for the
mode_config.mutex here looks like a bug. We call that during a modeset,
so if we get there through the atomic ioctl as opposed to a legacy
setcrtc we will not be holding the mode_config.mutex.
Walking the connector list with just the connection mutex should be safe
in theory. Although last I looked it was still racy as hell, but as I
said, in theory.
We could probably drop the connector list walk from there entirely since
we should know exactly which connector's eld we want.
> If I remove those WARN_ONs from there, I can get rid of this warning and
> everything works smoothly.
>
> Do you know if those WARN_ONs are required because these locks would be grabbed
> when we are in modeset.
>
> Regards
> Manasi
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-10-21 9:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 2:31 Redo a modeset on link training failure Manasi Navare
2016-10-21 9:35 ` Ville Syrjälä [this message]
2016-10-24 8:51 ` Daniel Vetter
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=20161021093544.GB4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@freedesktop.org \
--cc=manasi.d.navare@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 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.