From: Maarten Lankhorst <maarten.lankhorst@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 12:35:18 +0100 [thread overview]
Message-ID: <56C5AC76.5040603@linux.intel.com> (raw)
In-Reply-To: <20160218110708.GU32705@phenom.ffwll.local>
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.
Well that won't do what you expect it to do in certain cases..
crtc1 has MST_DP1
setcrtc(crtc1, { MST_DP1, MST_DP2 });
MST_DP1 gets disabled.
or
setcrtc fails with -EINVAL
Seems to me that if you steal an encoder, failing with an error would be better.
But for backward compat we could add some code to allow encoder stealing in the legacy setcrtc helper?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-02-18 11:35 UTC|newest]
Thread overview: 13+ 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ä
2016-02-24 8:51 ` Maarten Lankhorst
2016-02-18 11:35 ` Maarten Lankhorst [this message]
2016-02-18 11:11 ` [Intel-gfx] [PATCH 0/3] drm/atomic: Fix encoder stealing 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=56C5AC76.5040603@linux.intel.com \
--to=maarten.lankhorst@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 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).