On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: > >> Manasi Navare <manasi.d.nav...@intel.com> writes: > >> > >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: > >> >> Manasi Navare <manasi.d.nav...@intel.com> writes: > >> >> > >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: > >> >> >> Martin Peres <martin.pe...@linux.intel.com> writes: > >> >> >> > >> >> >> > On 26/01/17 14:37, 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.pe...@linux.intel.com> > >> >> >> > > >> >> >> > The relevant kernel patches have landed in drm-tip about a month > >> >> >> > ago. > >> >> >> > > >> >> >> > Eric, would you mind providing feedback on or merging this patch? > >> >> >> > >> >> >> The later discussion has sounded like the kernel will (always) prune > >> >> >> the > >> >> >> mode when we re-query, meaning that it doesn't make any sense to try > >> >> >> to > >> >> >> re-set to the old mode. Is this not the case? > >> >> > > >> >> > > >> >> > No the kernel will simply send a hotplug with link status as bad > >> >> > and then after that point its userspace driver's responsibility > >> >> > to check if link status is BAD, retry the same mode and if it fails > >> >> > then re probe. > >> >> > >> >> So the kernel will sometimes allow the same mode to be re-set with the > >> >> same bpp? > >> > > >> > So when userspace driver re-sets the same mode, the kernel will call the > >> > mode valid function where it will see it can allow the sam mode perhaps > >> > at a lower bpp now since the link parameters are lowered. > >> > So the mode which failed at 30 bpp, might still work at 18bpp and is > >> > better going to a lower resolution. > >> > >> The question was whether the kernel will ever allow the same mode at the > >> same bpp, since that's what this patch tries to do. > > > > Yes, this can happen. Doing a full modeset with recomputing clocks and > > everything behind userspace's back might not be something the kernel > > driver can pull of with a reasonable amount of effort, hence why we punt > > to userspace. The interface spec makes this a CAN, not WILL, to allow less > > unreasonable hw to handle these cases directly in the kernel driver. E.g. > > plain link-retraining is handled in i915.ko still. > > So in that case you do need userspace to re-request the same mode at the > same bpp?
Hi Eric, Yes so we do need userspace to re-request the same mode at the same bpp/pixel rate. Kernel will try that at that bpp or lower it. Its fully in kernel's control. If it fails then the atomic_check phase will return a failure and in that case the Gnome/KDE will have to do a full reprobe. Eric, do you have any more concerns about this patch or can this be pushed to Xserver? Its critical for thsi patch to be pushed to Xserver so that the entire Gfx stack can handle link failures and we can see some of the bugs going away. Regards Manasi > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
