Daniel Vetter <daniel@xxxxxxxx> writes: > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: >> Manasi Navare <manasi.d.navare@xxxxxxxxx> writes: >> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: >> >> Manasi Navare <manasi.d.navare@xxxxxxxxx> writes: >> >> >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: >> >> >> Martin Peres <martin.peres@xxxxxxxxxxxxxxx> 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.peres@xxxxxxxxxxxxxxx> >> >> >> > >> >> >> > 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?
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
