On Tue, 31 Jan 2017, Manasi Navare <manasi.d.navare@xxxxxxxxx> wrote: > On Thu, Jan 26, 2017 at 06:21:20PM +0100, Daniel Vetter wrote: >> On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote: >> > Despite all the careful planing of the kernel, a link may become >> > insufficient to handle the currently-set mode. At this point, the >> > kernel should mark this particular configuration as being broken >> > and potentially prune the mode before setting the offending connector's >> > link-status to BAD and send the userspace a hotplug event. This may >> > happen right after a modeset or later on. >> > >> > When available, we should use the link-status information to reset >> > the wanted mode. >> > >> > Signed-off-by: Martin Peres <martin.peres@xxxxxxxxxxxxxxx> >> > --- >> > >> > WARNING: The patches have not been merged in the kernel yet, so this patch is >> > merely an RFC. >> >> That's how it's supposed to happen, before we can merge the kernel side, >> we need acceptance (=reviewed) by the userspace side. Which is why this >> patch here. >> -Daniel >> > > This has been validated with a compliance device inducing a forced link > failure during modeset, after which the kernel sets the link-status to BAD > and sends a hotplug to userspace. The -modesetting driver then resets the > configuration by forcing another mdoeset and retraining the link at lower > link rate/lane count. This has been proven to pass DP compliance. > It has been also verified that this avoids the black screens in case of such > mode failures due to link training failure. Validation is great, but review is what is required and we're after! BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
