On Fri, Jul 29, 2016 at 11:19:18AM +0200, Daniel Vetter wrote: > On Thu, Jul 28, 2016 at 05:50:40PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > We can't mix MST with SST/HDMI on the same physical port, so we'll need > > to reject such configurations in check_digital_port_conflicts(). Nothing > > else will prevent this as MST has its fake encoders and its own connectors > > so the cloning checks won't catch this. > > > > The same digital port can be used multiple times, but only if all the > > encoders involved are MST encoders, so we only want to check MST vs. > > SST/HDMI, not MST vs. MST. And SST/HDMI vs. SST/HDMI we already check. > > > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > I'd be awesome if we could have some testcases for this. We can e.g. try > to enable HDMI without it being connected (it'll fall back to dvi mode), > so could use that to try enabling both hdmi and dp or dp mst out of sheer > nastiness. I don't even think we need to check that it gets rejected > correctly, just trying to do such a modeset on a broken kernel should > result in plenty of fireworks in dmesg (state checker for sure will be > unhapy) to make it obvious it's broken. Aka would absolutely love if this > patch gained a Testcase: line. Either way: What I've occasionally used for testing is kms_setmode with a patch to ignore all errors from setcrtc so that it doesn't abort midway. IIRC last time I did that on eg. HSW there were plenty of state checker complaints. In its default state kms_setmode has a bit of a problem because it doesn't know about conflicting connectors, nor does it know if we're supposed to have one encoder per connector or pair of connectors (DDI vs. !DDI). And also IIRC encoder/connector stealing will wreac some extra havoc here. Not sure if there's a good way to try and fix it so that by default kms_setmode would really test what's it's pretending to test on all platforms. I guess we could at least promote my hack to a proper command line option, so that we can try to feed as many combinations to the kernel as possible. > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > --- > > drivers/gpu/drm/i915/intel_display.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index c4c1c85366de..a6699c76bef3 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -12305,6 +12305,7 @@ static bool check_digital_port_conflicts(struct drm_atomic_state *state) > > struct drm_device *dev = state->dev; > > struct drm_connector *connector; > > unsigned int used_ports = 0; > > + unsigned int used_mst_ports = 0; > > > > /* > > * Walk the connector list instead of the encoder > > @@ -12341,11 +12342,20 @@ static bool check_digital_port_conflicts(struct drm_atomic_state *state) > > return false; > > > > used_ports |= port_mask; > > + break; > > + case INTEL_OUTPUT_DP_MST: > > + used_mst_ports |= > > + 1 << enc_to_mst(&encoder->base)->primary->port; > > + break; > > default: > > break; > > } > > } > > > > + /* can't mix MST and SST/HDMI on the same port */ > > + if (used_ports & used_mst_ports) > > + return false; > > + > > return true; > > } > > > > -- > > 2.7.4 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
