[Intel-gfx] [PATCH] drm/atomic-helper: Check encoder/crtc constraints

[Daniel Vetter]

On Thu, Nov 19, 2015 at 3:24 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Thu, Nov 19, 2015 at 03:02:09PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 19, 2015 at 12:12:28PM +0200, Ville Syrjälä wrote:
>> > On Wed, Nov 18, 2015 at 06:46:48PM +0100, Daniel Vetter wrote:
>> > > This was totally lost when I originally created the atomic helpers.
>> > >
>> > > We probably should also check possible_clones in the helpers, but
>> > > since the legacy ones didn't do that this is for a separate patch.
>> > >
>> > > Reported-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> > > Cc: Daniel Stone <daniels at collabora.com>
>> > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>> >
>> > Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> > Tested-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>> >
>> > But the rest of update_connector_routing() still looks somewhat bonkers
>> > to me. For one, it assumes that both the old and new crtc for the
>> > connector are part of the atomic state, but drm_atomic_set_crtc_for_connector()
>> > only adds the new crtc, not the old one.
>>
>> Nothing bonkers about it since drm_atomic_get_connector_state ensures that
>> the corresponding crtc state is part of the update. Same logic applies for
>> planes.
>
> Ah, that's where it was. OK, so it's just seems bonkers in other ways ;)
>
> Let's say we have as a starting point:
> crtc0 -> enc0 -> conn0
> crtc1 -> enc1 -> conn1
>
> Then we do an atomic_ioctl()
> -> set conn0 -> NULL
> -> set conn1 -> crtc0
> -> set conn2 -> crtc1
>
> And if enc1 is the best_encoder for both conn1 and conn2,
> it looks to me like we would silently end up with just:
> crtc1 -> enc1 -> conn2
>
> Even though the user asked for:
> crtc0 -> conn1
> crtc1 -> conn2

Yeah this is what will happen, since perfect backwards compat to old
Vjuserspace. We could fix this (probably by outright disabling encoder
stealing), but I'm not too concerned really: Practically it's
impossible to ask for this config (since you can't plug in both HDMI
and DP). Same holds for other drivers, where encoder routing is at
most used to select between dvi and crt encoders for DVI-I/D.

> Also the code seems to assume that a single encoder can't drive multiple
> connectors at once. Is that by design or an accident?

That's by design - the cloning mask it as the encoder level, so hw
cloning happens between crtc/encders.

> So I'm thinking maybe we should first check for routing conflicts in the
> new state and fail if any were found. After that we could go through the
> old state to steal stuff, and we should disallow stealing for the atomic
> ioctl totally and only allow if from setcrtc.

Otoh I guess we could do that too, just for consistency. Simples
approach would be a bool in connector_state which we leave at false in
duplicate_state. Then on the first set_crtc_for_connector we set it to
true and refuse to steal from such connectors.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch