Op 15-05-17 om 15:52 schreef Daniel Vetter: > On Thu, May 11, 2017 at 11:41:22AM +0200, Maarten Lankhorst wrote: >> Op 11-05-17 om 11:23 schreef Daniel Vetter: >>> On Thu, May 11, 2017 at 10:28:43AM +0200, Maarten Lankhorst wrote: >>>> We shouldn't inspect crtc->state, instead grab the crtc state. >>>> At this point the hw state verifier should be able to run even if >>>> crtc->state has been updated (which cannot currently happen). >>>> >>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> >>> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >>> >>> pll state checking still looks at ->state directly, we might want to port >>> that to the new private obj helpers perhaps, with the same new/old >>> iterators? >> That might be an excellent idea to do in the future. :) >> >> If I look at it though it's race safe in the current design, >> but not necessarily against multiple nonblocking modesets, >> which should probably be addressed at some point. > I looked at this more from the pov of unifying state handling across all > blocks. If everything works roughly the same, it's much easier to > understand. And I do kinda like DK's private state stuff, that should help > in aligning the various internal bits we have (like shared dpll, wms, and > all that). > -Daniel Agreed, it should be something for unification. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
