On Thu, Jun 04, 2020 at 10:08:58PM +0300, Imre Deak wrote: > On Thu, Jun 04, 2020 at 10:01:40PM +0300, Ville Syrjälä wrote: > > [...] > > > > Then we get this hpd, in this case if we dont reset the param to max values, prev triggered modeset continues > > > > with fallback values but since connector probe doesnt happen again through IGT, it tries the same mode > > > > with fallback values and return encoder config failure. > > > > > > If the link training failed then clearly the sink didn't like us anymore > > > anyway. So feels like resetting these here is just shifting some race > > > window around a bit, but it could still fail if the sink still doesn't > > > like us. > > > > > > Would be good if someone was able to figure out why the sink goes bad in > > > the first place. > > > > Oh, and don't we now have Imre's "weird hpd happened in the middle of > > the test, don't trust the results" thing in igt? > > An LG and IIyama monitor this happens on disconnect and reconnect after > waking from an idle state when modesetting them, not sure if it's the > same case. Well in this case, it happens just after link training failure due to some AUX timeouts then looks like the panel detects that the link was not enabled and sends this HPD which puts us into connector status changing from connected to disconnected. But in IGT, we dont get any uevent so we dont reprobe and continue with the next igt_display_commit. So should we in IGT in kms_atomic_transitions, plane-all-modeset-transitions subtest, should we check the connector status everytime before back to back commit calls? Like I think in real use case, after a link failure the userspace would get a uevent and respond to it by reprobing a connector, but we dont do that in IGT so these random link failures cause issues like in here. Manasi > > --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
