Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux