From: Daniel Vetter <daniel@ffwll.ch>
To: Simon Ser <contact@emersion.fr>
Cc: Manasi Navare <manasi.d.navare@intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET
Date: Wed, 3 Jun 2020 15:45:12 +0200 [thread overview]
Message-ID: <20200603134512.GP20149@phenom.ffwll.local> (raw)
In-Reply-To: <JVT0GCme37ZPwkrYR-Ly9A-jZKs8QGDGOgPcmyDgPHvYRwtNutsoG53fkrrKB95t-ml7YKa0gEpCchaW7jIgDW-XnBCYh6xjPrsO-3W05mo=@emersion.fr>
On Wed, Jun 03, 2020 at 01:17:14PM +0000, Simon Ser wrote:
> On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
> >
> > > On Wed, Jun 03, 2020 at 10:45:23AM +0000, Simon Ser wrote:
> > >
> > > > In update_output_state, the link-status property was reset to GOOD to
> > > > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> > > > is also performed on an atomic commit without ALLLOW_MODESET. If a
> > >
> > > I didn't think udate_output_state() was getting called for
> > > non-legacy paths. Where is that coming from?
> >
> > Oops, I'm blind and you're right, there's no bug. We already only
> > force-set this for legacy modeset (and fbcon).
>
> Indeed, good catch Ville. set_config is purely a legacy thing.
>
> > That also means that atomic userspace has to handle this, which is maybe
> > not so awesome ... So maybe we need to duct-tape over this for atomic too,
> > and in that case it should be only done when ALLOW_MODESET is set.
> >
> > But maybe all the compositors that care will handle this :-/
>
> Not fond of this because we'll basically end up with some drivers
> checking for link-status (none do that yet) and some user-space
> resetting it to GOOD. It'll break only if user-space doesn't reset and
> a driver which checks link-status is used. Driver-specific behaviour
> isn't great.
See my other reply, drivers don't need to check for GOOD, it's kinda
magic.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-06-03 13:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 10:45 [PATCH] drm/atomic: don't reset link-status to GOOD without ALLOW_MODESET Simon Ser
2020-06-03 11:06 ` Daniel Vetter
2020-06-03 11:13 ` Ville Syrjälä
2020-06-03 11:36 ` Daniel Vetter
2020-06-03 13:17 ` Simon Ser
2020-06-03 13:45 ` Daniel Vetter [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=20200603134512.GP20149@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=contact@emersion.fr \
--cc=dri-devel@lists.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.