On Wed, Jun 18, 2014 at 01:10:32PM +0100, Chris Wilson wrote: > On Wed, Jun 18, 2014 at 01:59:14PM +0200, Daniel Vetter wrote: > > X could end up putting the fbcon fb into other domains, e.g. > > for smooth take-overs. Also we want this for accurate frontbuffer > > tracking: The set_config is an implicit flush and will re-enable > > psr and similar features, so we need to bring the bo back into > > the gtt domain. > > Is this possibly an atomic path? It would be nice to have a note on > fb_ops which were. But I remember having lots of in_atomic() handling > for fbdev acceleration (copied from nouveau). They are all callable from atomic, at least in Oopses. fbdev accel is completely bonghits in that regard (imnsho) and I think the only option we have is to block _any_ fbdev operation in atomic contexts from the start and use David Herrmann's special last effort emergency logging support to print the Oops. Even trying to make all this code work from atomic contexts is imo a losing battle and a complete validation nightmare. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
