From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/atomic: Refuse to steal encoders from connectors not part of the state.
Date: Thu, 18 Feb 2016 14:59:52 +0200 [thread overview]
Message-ID: <20160218125952.GN23290@intel.com> (raw)
In-Reply-To: <20160218124311.GX32705@phenom.ffwll.local>
On Thu, Feb 18, 2016 at 01:43:11PM +0100, Daniel Vetter wrote:
> On Thu, Feb 18, 2016 at 12:18:53PM +0100, Maarten Lankhorst wrote:
> > Op 18-02-16 om 12:07 schreef Daniel Vetter:
> > > On Thu, Feb 18, 2016 at 09:54:43AM +0100, Maarten Lankhorst wrote:
> > >> Because encoder <-> connector mapping is fixed when not moving to
> > >> another crtc we can just reject connectors trying to steal an encoder
> > >> from a connector not part of the state. This won't break MST on i915
> > >> because in that case connectors will be part of the state if you switch
> > >> them between crtc's. If they're not they stay on the same crtc, and
> > >> encoder stealing would have failed anyway.
> > > We must do this for backwards compat. setCrtc on a connector that needs an
> > > encoder already used on some other crtc is supposed to disable that
> > > encoder (and the entire pipe if it's all unused) if we need it.
> > > -Daniel
> > >
> > Could this be done from the setcrtc helper? Seems with atomic that wouldn't be desired behavior.
>
> If you want to avoid stealing with atomic, supply _all_ the
> connectors/crtcs when doing an atomic modeset. After all the point of
> atomic is to do global updates. I don't think it makes sense to have a
> special case just for setcrtc, since it makes compat/transition
> unecesserily complicated.
I disagree. Having properties change magically is just a bad idea IMO.
As far as checking for conflicts, IIRC I did that with a few bitmasks
in my original atomic code, and it was pretty trivial. The current
stealing code we have is way too complicated for what it does IMO.
> And we do this kind of stealing in other places
> too with public api objects, e.g. if you move a plane.
Mm. What exactly do we steal with planes?
--
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-02-18 12:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-18 8:54 [PATCH 0/3] drm/atomic: Fix encoder stealing Maarten Lankhorst
2016-02-18 8:54 ` [PATCH 1/3] drm/atomic: Always call steal_encoder Maarten Lankhorst
2016-02-18 8:54 ` [PATCH 2/3] drm/atomic: Refuse to steal encoders with index < conn_idx Maarten Lankhorst
2016-02-18 11:09 ` Daniel Vetter
2016-02-18 11:22 ` Maarten Lankhorst
2016-02-18 8:54 ` [PATCH 3/3] drm/atomic: Refuse to steal encoders from connectors not part of the state Maarten Lankhorst
2016-02-18 11:07 ` Daniel Vetter
2016-02-18 11:18 ` Maarten Lankhorst
2016-02-18 12:43 ` Daniel Vetter
2016-02-18 12:59 ` Ville Syrjälä [this message]
2016-02-24 8:51 ` Maarten Lankhorst
2016-02-18 11:35 ` Maarten Lankhorst
2016-02-18 11:11 ` [Intel-gfx] [PATCH 0/3] drm/atomic: Fix encoder stealing Daniel Vetter
2016-02-19 14:39 ` ✓ Fi.CI.BAT: success for " Patchwork
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=20160218125952.GN23290@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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 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.