On Tue, May 20, 2014 at 10:16:54AM +0200, Daniel Vetter wrote: > On Tue, May 20, 2014 at 08:47:41AM +0100, Chris Wilson wrote: > > Daniel simplified the modesetting code to push the common work performed > > by each of the architecture specific routines higher into the caller. This > > took me a while to be sure that it was safe in the event of a > > modesetting failure - to be sure that the dangling pointer we left in > > the registers would never be accessed. As it turns out, it is safe, as > > even after the most convoluted error path, we always rewrite the address > > registers with the currently pinned object before enabling the planes > > and pipes. This patch just adds an assertion that the preconditions > > Daniel stated are correct, and a comment to justify the dance. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Hm, I think we should tackle the larger issue here and have a bit of a > plane config checker, to make sure reality matches up with what we expect > it to be. But I'm not sure that effort is worth it. > > Wrt the assert I actually prefer we keep those in the low-level callbacks. > At least they often encode platform specifics, which will be more obvious > once we have atomic modesets support and also need to deal with sprites > and cursors here. Here they are testing the preconditions you stated for this code to be safe. I think they are exactly where they need to be as they serve a similar but different purpose to the lowlevel checks. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
