[Intel-gfx] [PATCH 2/3] drm/atomic: Refuse to steal encoders with index < conn_idx.

[Maarten Lankhorst]

Op 18-02-16 om 12:09 schreef Daniel Vetter:
> On Thu, Feb 18, 2016 at 09:54:42AM +0100, Maarten Lankhorst wrote:
>> There was a potential to crash in the following case:
>> [   49.985270] [drm:update_connector_routing] Updating routing for [CONNECTOR:48:DP-3]
>> [   49.985273] [drm:update_connector_routing] [CONNECTOR:48:DP-3] keeps [ENCODER:33:DP MST-33], now on [CRTC:21:crtc-0]
>> [   49.985275] [drm:update_connector_routing] Updating routing for [CONNECTOR:51:DP-4]
>> [   49.985278] [drm:steal_encoder] [ENCODER:33:DP MST-33] in use on [CRTC:21:crtc-0], stealing it
>> [   49.985281] [drm:update_connector_routing] [CONNECTOR:51:DP-4] using [ENCODER:33:DP MST-33] on [CRTC:21:crtc-0]
>>
>> This case is not allowed, similar to the previous case of 2 connectors newly assigned to the same encoder.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> What index something has is pretty arbitrary, i.e. I don't understand at
> all what exactly you're trying to fix here, and what the problem is. Note
> that this patch here seems to break the stealing-prevention logic: We're
> supposed to steal the first time around, but not move an already stolen
> encoder further (to make sure that all connectors in the current set can
> be lit up).
Well update_connector_routing runs over the for_each_connector_in_state, and connector_index linearly increases.

This means that 0...conn_idx have already been assigned, so if you see encoder with those indexes
you can't steal them. With conn_idx+1...n you can still steal it and be assured that the state is sane,
and a new encoder will be assigned by the next call to update_connector_routing.

~Maarten