Op 20-03-17 om 11:22 schreef Chris Wilson: > On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote: >> Op 20-03-17 om 09:59 schreef Daniel Vetter: >>> But my idea was kinda that we'd do the same for probe -> modeset data >>> flows like here for the other way round: Just a bunch of READ_ONCE and >>> maybe lookup the edid with rcu too. That way it's clear to anybody that >>> probe and modeset are entirely not synchronized. >> Though I think it's beneficial to lock them. if it is. I'm not sure there >> are many usecases for parallel modeset vs probe. And if someone does care, >> they can use nonblocking modesets, maybe. >> >> Legacy userspace probably can't do blocking modeset and probe at the same >> time, so I don't think it will regress. > It can happen - just consider two clients, such as system-logind walking > sysfs. Delaying most modesets would not be an issue, except where the > modeset is being uses to e.g. changes strides before in the middle of a > pageflip sequence. With atomic pageflip, this is no longer required on i915. :) > I would welcome kms_flip flip/set/vblank-vs-probe, and definitely should > add it to legacy-cursor and legacy-plane as well. Could be useful, the normal paths should never take connection_mutex anyway, so either way it should pass. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
