[Intel-gfx] [PATCH] drm/i915: Sanitize the PPT fdi lane bifurcate state on ivb

Daniel Vetter daniel.vetter at ffwll.ch
Thu Oct 24 15:05:30 CEST 2013

On Wed, Oct 23, 2013 at 12:58 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> I'm thinking the crtc->base.enabled check is actually pointless.
> AFAICS we should never get here with crtc->base.enabled==false and
> crtc->active==true

Hm yeah. I was kinda shooting for the minimal thing here.

> We anyway re-enable the bifurcation bit when we do the mode_set.
> Actually that in itself could be a maybe a bug. We'd turn off the
> bifurcation bit when both pipes B and C are disabled based on
> prepare_pipes, but we only do the mode_set based on modeset_pipes.
> But currently we are saved by the fact that those two bitmasks are
> the same.

The current logic (after this patch) is to
- always clear the bit when both pipes are off.
- always set if if we either enable pipe B or C and we'd need it to
allow the other pipe to be lit up. If pipe B uses 4 lanes then we
can't light pipe C up anymore, so we don't set the bit.

There is a potential issue though with all pipes disabled with dpms
off now. I think conceptually I need to precompute the desired state
of the bifurcate bit in the compute config stage and then only set it

> Another potential bug I found is that we always set the bifurcation
> bit in mode_set, even if we're not using FDI. So if we have eg.
> pipe B enabled w/ FDI using 4 lanes, and then we enable pipe C w/ EDP,
> we'd still flip the bifurcation bit in pipe C's mode_set and destroy pipe
> B's output. The fix would be to call ivybridge_update_fdi_bc_bifurcation()
> only when has_pch_encoder==true.

has_pch_encoder should only be true if we have fdi_lanes > 0. So we
shouldn't actually enable this stuff (and iirc I've tested the edp on
pipe C with pipe B using 4 lanes). The actual configuration checks all
happen in the pipe configuration computation stage. I'll rework the
patch a bit (but that'll take a while).

Thanks for the review,
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

More information about the Intel-gfx mailing list